I’m exploring the possibility to change my GL extension binding functions in order to use informations provided by SGI’s “glext.h”.
I noticed, once more, that the SGI extension registry is not exhaustive - so the “glext.h” is not exhaustive either… For example, that GL_EXT_texture_rectangle is not in the registry, along with GL_EXT_texture_edge_clamp…
I did some research, but did not find any explanation of this “non exhaustiveness”… These ARB meeting notes refer to EXT_texture_rectangle and its incorporation to the registry but nothing seems to have happened since…
I’d like to understand the reason for all this… Can we consider that the extensions missing are “unofficial” ? or simply that the registry is not as exhaustive as it should be ?
Does anyone know of an alternate exhaustive registry ?
GL_EXT_texture_rectangle is an Apple invention. It’s on their site. There is GL_NV_texture_rectangle as well.
GL_ARB_texture_rectangle replaces both. All 3 are the same.
This extension is semantically equivalent to EXT_texture_rectangle
and NV_texture_rectangle. The tokens, and name strings now refer
to ARB instead of EXT or NV. Enumerant values are unchanged.
I was not aware that GL_EXT_texture_edge_clamp was an extension. But the SGIS version exists. This went into core and just adds a token.
Other then that, there are some vendor specific extensions that I wanted info on in the past, like KTX_buffer_region. This is another extension that was superceeded.
Thanks for your answar, I’m quite aware that extensions get sometimes superseeded, but as they continue to get exposed by drivers, I imagine that they are still “valid”…
For example, GL_EXT_texture_edge_clamp is “exposed” by “everyone” : ATI, NVidia, 3DLabs, XGI, etc. but is not in SGI’s registry.
GL_SGIS_texture_edge_clamp is not “exposed” by NVidia but is in the registry…
The same functionality is integrated into the core of OpenGL 1.2…
I’m still lost, I fail to understand the logic governing the presence/absence of those few problematic extensions in what seems to be the official registry…
Because loading the extension is not enough to use it, you have to understand how to use it
I think that every extension should be documented in the registry, even if they are already superseeded by other extensions or core functionality. For example I know that ARB_texture_rectangle and EXT_texture_rectangle are identical except GLSL support, but I only know this because it was posted in these forums a few times. It would be nice to have official documentation that says so…
Assuming I don’t know what the differences between the EXT and the ARB version are, how am I supposed to know how to write programs that use rectangular textures on ATI hardware? Of course I could just assume they are the same and use my ARB code even when only the EXT extension is exposed, and in this case it will work, but that’s just pure luck, and searching the forums archives should not really be the only way to obtain such information…
As a side note extensions sometimes get exposed even when they’re in the core just because legacy apps will not make the calls unless they see the string.
There’s a real backwards compatability dilema here. Apps cannot know what will be in future versions of OpenGL and they’re left to query a version of OpenGL not select one. So even when they see a higher version they still look for extensions and legacy calls. Sometimes the calls map 1:1 with core and a wrapper is provided, other times (EXT_polygon_offset) the call or parameters are actually different from what’s later put in core and implementors need to expose legacy functionality or drop it.
AFAIK the extension registry is the best source of information on extensions avilable.
w.r.t. exhaustiveness, I think one of the issues is developers have a lot of freedom to run off & implement extensions.
You can see in the minutes that Jon Leech is asking for the rectangle spec so he can put it up online, sometimes people working on non finalized specs don’t want to do that.
I think when extensions get promoted to ARB they’re pretty much the same with differences noted in the ARB extension. Most changes are just to document consistency within the broader API and don’t affect real world behavior (IMHO).
I’m still lost, I fail to understand the logic governing the presence/absence of those few problematic extensions in what seems to be the official registry…
With the exception of ARB extensions, there is no governance. If someone sends in an extension spec and asks that it be added to the registry (and they have a shipping implementation, typically), it will get listed there. It will also usually end up in the glext.h / glxext.h there.
However, absolutely nothing forces someone to submit an extension that they ship. Just google for SGIS_point_line_texgen, ATI_point_cull_mode, GL_SUNX_geometry_compression, or GLX_NV_swap_group.
The general rule is that if only one company is going to ship something, they expose it as GL_<company abrev.>_extension (e.g., GL_NV_fence). If multiple companies agree to implement the same thing, they expose it as GL_EXT_extension (e.g., GL_EXT_vertex_shader). What happens (stupidly, IMO) is that companies don’t want to ship extensions with their competitors names in them, so they just rename them with EXT. That’s how GL_EXT_texture_rectangle (and numerous others) came about.
This also happened with a lot of older SGI extensions. Most of the EXT extensions numbered lower than about 80 were originally SGI. For example, you can probably find some old SGI boxes that expose GL_SGI_vertex_array and GL_SGIS_point_parameter.
For the most part, if it’s not in the registry, than the odds are good that most “common” hardware does not expose it (with GL_EXT_texture_rectangle being a notable extension). This is where platformspecific extension “registries” come into play.
This mostly confirms what I believed, so I dropped the objective of being based only on SGI’s “glext.h”, I added by hand the missing extensions I needed, and here I go…
