Declaring extension usage

The thread at http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/003056.html discusses a conflict between NV_texture_env_combine4 and ARB_texture_env_crossbar. This conflict exists because both extensions define different behaviours for actions that use previously defined constants. If both were implemented, it would have been impossible for the driver to tell which extension the program is trying to use, and therefore which implementation semantics to use. However, if the driver could be made aware of which extension is being used, then it could implement support for both, and choose appropriately. (This is especially true since the conflict is about handling a condition that shouldn’t normally happen.)

While such conflicts shouldn’t happen, they obviously do. As a developer, I prefer to use extensions that work on as many cards as possible. Therefore I propose the addition of an ability to avoid such conflicts by adding an extension querying mechanism that will allow the program to declare that an extension will be used, and for the driver to report that a conflict exists. Here’s how the extension might be defined:

New function:
glUseExtension(char* extension_name)

Usage:
Instead of querying the extension string, the program uses glUseExtension for each extension. The function returns one of three results:

  • Okay - the extension is available, and can be used
  • Doesn’t exist - the extension isn’t supported
  • Conflict - the extension conflicts with an extension of a previous glUseExtension call

In order to avoid conflicts, it may be necessary to make some extensions available only through this mechanism, and not in the extension string. For example, ARB_texture_env_crossbar could be made available only via glUseExtension on NVIDIA hardware. [It would be possible for a program to call glUseExtension(“ARB_texture_env_crossbar”), and still use NV_texture_env_combine4, and get crossbar behavior for it, but this is predictable and well defined behaviour.]

The function will also return whether the extension is implemented in hardware or software. Just kidding

Ugh. How about just not creating extensions that conflict in the first place?

  • Matt

I’ll try not to create them, next time

But really, from my POV, I’d just like a consistent way to write OpenGL programs. I can accept having to use vendor specific extensions for new and special functionality, but I’d really like to be able to see common functionality incorporated into core OpenGL or common extensions.

There’s a conflict. It happened. If you can’t change that, then go around it, that’s what I say. Better this than nothing at all.

Not sure but if the driver knew from start what extensions are going to be used it might perhaps be able to run more optimally. Probably not that significantly though.

Another use for requesting extensions would be to allow versioning. That is, a version parameter could be added, and the application would be able to ask for a specific minimal version of the extension.