extensions?

Hi,

Is there any real need to check the extension string ( via glGetString(GL_EXTENSIONS) for the presence of a certain extension?

Wont wglGetProcAddress() achieve the same thing - ie: return ‘0’ if there’s no such extension supported at runtime?

sure, but there exist extensions that don’t add new gl functions. one example is ARB_texture_env_dot3 . for such extensions, you obviously can’t use wglGetProcAddress() to determine if the extension is available, and that’s what the extension string is for.

Originally posted by marksibly:
Wont wglGetProcAddress() achieve the same thing - ie: return ‘0’ if there’s no such extension supported at runtime?

Well, I guess the only need to check for the ext manually is that there it is considered ‘good’ programming.
I don’t think there’s another real reason. I someone knows it, please let me know.

posted by obli:
I don’t think there’s another real reason. I someone knows it, please let me know.

it seems someone posted the following before your post, obli.

posted by some guy named “sthomas”:
there exist extensions that don’t add new gl functions. one example is ARB_texture_env_dot3. for such extensions, you obviously can’t use wglGetProcAddress() to determine if the extension is available, and that’s what the extension string is for.

You should always check the string first. It is quite possible that some implementations may erroneously return a pointer to an unsupported extension. This can result in getting function pointers to extensions that are incomplete, unoptimized, buggy or any combination thereof. Check the string first, and then you can be certain the extension is supposed to work.

Originally posted by DFrey:
It is quite possible that some implementations may erroneously return a pointer to an unsupported extension.

Now, this is the reason. Bad drivers. I guess there’s no vendor which provides drivers wich are so bad however.


Please Thomas, I am not a moron. I guess most people will read the ext spec before using it. At least, I do. Now, if you go to the ext spec, there’s always a field called “New procedures and functions”. If this says “none”, there’s nothing to query to wglGetProcAddress.
You second post made me write down the text after the —. You previous post was ignored (well, was read, considered useless and discarded). Sure, it may be useful to someone which is really new to this but I guess most people here is assuming that a new function is being added.

That’s not the point. The point is, drivers are constantly in motion. Your current version may contain an experimental first implementation of an extension that’s not yet ready for production use. Just a playground for the driver programmers.
OTOH the extension string will only contain the ones that are ready.

posted by obli:
You previous post was ignored (well, was read, considered useless and discarded). Sure, it may be useful to someone which is really new to this but I guess most people here is assuming that a new function is being added.

jeez, i was just joking. no reason to get so upset obli. but why is my point useless? why would you assume that a function is being added? i gave an example of an extension in which no function is added, so you need an alternative method to calling wglGetProcAddress() to figure out if the extension is available. as far as i can see, that’s the BEST reason for having the extension string, because it’s the only thing that makes the extension string absolutely mandatory.

anyway, i only made my second post because you said “if anyone knows why the extension string exists, please tell me”, when i had just posted a perfectly valid reason why. but there’s no need to get all bent out of shape man.

-steve

Hello,

So let me get this straight. Some extensions add new functions, while others don’t. For example, an extension which provides faster rendering (or better quality) for existing functions. I guess then you need to check the string to be aware of it.

I also think that just using wglGetProcAddress() is good enough to get available (functional) extensions. After all, if the function is available then it BETTER be bug free (or at least, it better not destroy the computer, ie. hacker bait). Making a buggy extension available is like the big red button which destory’s the world and has a sign that says “please don’t push me”.

Of course, real life probably does not work this way (unfortunately).

well… although that sounds like it’d be reasonable, it doesn’t always work that way, as you suspected. for example, nvidia provided the functions for the new vertex buffer object extension in their drivers before they added it to the extension string. the idea is that if it’s not in the extension string, you shouldn’t be using it for commercial products, but just for testing purposes until they get the implementation perfect, at which point they’ll put the extension in the extension string (as they did with vbo).

i guess the bottom line is that for a commercial app, or one that has to work correctly, you shouldn’t use an extension unless it’s in the extension string. for testing new extension functionality and such, grabbing the extension entry points is fine.

I agree, its just that I don’t like the idea of “consumer-ready” drivers providing insecure code.

Right,
My apologies for that.