Problem understanding extensions strings and OGL features

I am new to OpenGL and have some questions. I have looked at the OpenGL 1.4 PDF and I didn’t find what I was looking for.

I am assuming any “core” features in version 1.4 must be in all drivers claiming to be 1.4. Is that correct?
What confuses me is that (for example) ARB_texture_env_crossbar is listed as promoted to core for 1.4 and has a name string of GL_ARB_texture_env_crossbar assigned to it. Yet my video card claims 1.4 compatibility but does not have it listed in the extensions. I have a ti 4200 and a GF FX 5200.

I did read http://www.opengl.org/developers/code/features/OGLextensions/OGLextensions.html

In short, I just would like a better understanding of how to see what features are in a particular version and what is optional.

If anyone has a good link explaining these basics, please can you post me a link?

Thank You

GL_ARB_texture_env_crossbar was promoted, but a minor change was introduced before it became a core function, so those cards cannot live up to the GL_ARB_texture_env_crossbar spec, but they do live up to the 1.4 spec.

( the change is about how disabled textureunits should be handled, and probably not an issue in your code)

I have a Gf 4200, too, and i think i remember, that it claimed only to support 1.3.
If they today claim to support 1.4, than that´s wrong, the Gf 4 does not support the crossbar extension.

The GfFX should support it, though.

Get the extension loading library: http://www.levp.de/3d/

It does all the extension checking and initializing for you, so you can be sure, that you didn´t do anything wrong.

Cheers,
Jan.

Originally posted by Jan2000:
If they today claim to support 1.4, than that´s wrong, the Gf 4 does not support the crossbar extension.

If the driver provides a software fallback, then there’s nothing wrong. Would make little sense, though.

NV25 does support crossbar functionality. It just can’t expose the extension because it differs from what was specified in NV_register_combiners (wrt to invalid textures that are bound and sampled).

As a rule of thumb, crossbar is supported whenever NV_register_combiners is supported, even if ARB_texture_env_crossbar is not exposed in the extension string.

and as a general statement. No, you dont have to have all promoted extensions for a certain version in the extensionlist in order to fully support that version.

we have many more examples of that. nVidia supports opengl1.4 on very lowend cards, cards that not have the 3dtexture functionality, and are falling back to software rasterizing when youre using that.

And this particulat extension is as i said before, slightly changed when it went into the core… I think it was that sampling from unbound texture units should be white in that specification ( nvidias hw resulted in black) and the final core spec was that the result are undefined. ( allowing both the ati and nvidia way) but dont sample from unbounded units and its allright.

Thanks for the replies I am looking at the crossbar feature and did not know that.

But I think I did not really ask my original question properly. Let me explain: My first OpenGL project was a Quake3 BSP viewer. (No colored tris for me). Up to now, any routine was either in opengl32/glu32 (ie: glOrtho, gluPerspective, glDrawElements) or it was simple to find the extension in the extensions string and fetch the needed address (ie: glActiveTextureARB).

I guess what I really am trying to ask is:
Is the extensions list a driver produces written against an old 1.x spec or is it a list of extensions based on the current version of the driver installed? In other words, if something like crossbar was promoted to a core feature in 1.4 then can I rely on it being in all 1.4 drivers? The name string isn’t in the extensions string for my 5200 (driver version 1.4).

The difference being I was always relying on the extensions string to find out what was supported and never before needed to use the driver’s version number. While checking on the crossbar extension I noticed my 5200 did not have it listed. So I checked and found out it is now in version 1.4. I was always assuming it would be in the extensions list since the sgi doc gave it a name string and says it’s written against the 1.2.1 specs. (ie: My current code would not find any crossbar extension so it would be assuming the card did not have that capability.)

This would be the first time I would be using a newer feature present in the driver but not listed in the extensions string. As Mazy explained, crossbar for my card does not live up to the GL_ARB_texture_env_crossbar spec and thus would not be in the extensions list anyways.

Thanks Jan2000 for the link. I wish I had it before I started. Unfortunately now I don’t know if I want to bother changing what I already have. I may consider it for any future projects though.

Mazy: Looking at the 1.4 docs I realize that the ARB extensions listed in the 1.4 docs may not all be supported in my driver.

In short:
Looking at it now, I believe I must add a version number check to identify features - not simply fully relying on the extensions string. ie: If it is a core feature for 1.4 then all drivers advertising 1.4 would have that core feature. A feature, once promoted to the core, may not have the name string advertised in the extensions list anymore. It could be, to maintain backwards compatibility - but this is not a requirement.

I would just like to confirm this before I make many changes to my code.

Thanks again! I really appreciate the efforts here

Extension are generally still listed in the extension string, even after promotion to core. This is done for backwards compatibility reasons, and while it’s AFAIK not required to do it, it’s the right thing for driver writers to do.

There are exceptions to this rule:
A feature may be supported as of the core revision, but not as an extension because it’s not hardware accelerated, ie too slow. An example would be 3d textures on Geforce 2 class cards. They support GL 1.4, and they do support 3D textures (they have to because of the core version), but that will force software rasterizing, which is horribly slow.
Thus they do not expose the 3d texturing extension in the extension string, to not encourage (older) applications to use it.

The extension string, basically, tells you which features will be fast enough to be used. The core version will tell you which features are available.