quote:Original post by glnefugio
And do the extensions depend on my hardware or the software implemetation??

quote:
If you think about it, you''ll find that it is nearly impossible to define the term "hardware" in a way that applies to certain OpenGL implementations. (Start thinking about embedded CPUs to implement features and the like.)

Since "hardware" and "software" have no meaning for certain implementations, what you really want to say is, is some feature "fast" or "slow"? (Note that "hardware" is not necessarily "fast" and "software" is not necessarily "slow". This is another problem with saying whether something is done in hardware or software. You don''t care how it''s implemented, only how fast!)

Of course, now you can''t just use one bit to describe performance; performance is a whole spectrum. How fast, how slow? And often the driver doesn''t even know how fast something will go, because it depends on a litany of factors out of its control, so it couldn''t even return a very accurate number.

Given these considerations, a performance test is the way to go, and distinctions like "hardware"/"software" and "fast"/"slow" should stay out of the API.


The standard we''ve adopted is to not expose the extensions for features that will only run in SW, if the OpenGL version number indicates that we support the emulation. In the case of, say, ARB_imaging, there''s only one way to expose it (the extension string), so we expose it across the board. But for EXT_texture3D, we choose not to expose the extension unless the HW can do 3D textures, since a GL version of 1.2 or higher already indicates support.

This only works for a few features in the API, and other vendors may not follow this standard, so it may not be a good idea for you to rely on this in your app.

- Matt