Archived

This topic is now archived and is closed to further replies.

Extensions

This topic is 5799 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, As I implemented Multitexturing in my App, a question came to my ind: IS out there a pdf where all extensions are described even with there functions?? And do the extensions depend on my hardware or the software implemetation?? thanks!

Share this post


Link to post
Share on other sites
quote:
Original post by glnefugio
And do the extensions depend on my hardware or the software implemetation??



I''m not sure if this is of any use to you, and if this is what you mean with your question, but extensions are always HARDWARE extensions I believe, so it really depends on the hardware (graphics card) of the user if an extension is supported. There is a lesson on NeHe''s where you learn how to find out if certain extensions are supported on the user''s graphics card.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
All non-experimental extensions are listed in the official extension registry at http://oss.sgi.com/projects/ogl-sample/registry/

Nvidia also has a pdf that is just a collection of all registry entries for the ARB, most EXT and NV extensions. Don''t look for ATI extensions on their paper though

The best place to go is the SGI registry.

- AH

Share this post


Link to post
Share on other sites
FYI

Extensions aren''t necesarily hardware accelerated. They are simply implemented by the driver. The most obvious being the wgl extensions. A better example are vertex program extensions which are supported on all GeForce cards. Yet they are only in hardware on a GeForce 3.

mcraighead of nvidia said ...

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

Share this post


Link to post
Share on other sites