I’m on a bit of a downer when it comes to the OpenGL extension mess (touched upon in my thread about the Radeon).
Whats the point of having an extension string if its incorrect or has major omissions?
My old Matrox G200’s extension string didn’t report paletted texture support - yet if you grabbed the glColorTableEXT function from the driver it worked fine. WHY?
This Radeon I’ve got is supposed to support texture compression. It’s not in the extension string. But again, if you grab the function it works fine.
So Matrox and ATI (both Canadian, if that has anything to do with it) whats the point of having these strings at all if they aren’t consistant with the features currently exposed in your drivers?
only way i can see around it is to have a configuration type item where you do a small demo, testing each of the wanted extensions, and asking the user, “did this work?”
lol
i really don’t see any good way other that to write the driver companies vulgar and obscene e-mails encouraging them to stop playing around and make quality products that do what the say they’re suppossed to…
My approach on this is that if you grab an extension function pointer for an extension that the driver does not claim to support, it “probably” isn’t safe (in theory) to call the function.
There is only one official way of determining whether an extension is supported, and that is to look at the extension string.
In theory, if it’s not in the extension string, wglGetProcAddress should return NULL. I think we implement this correctly in our driver, but there may be a few cases where it isn’t entirely correct and you may be able to pull out a function pointer for a function that isn’t supported. If so, that’s a bug. An analogous situation is that if you give us an enumerant for an extension that we support on one configuration but not on another, we should be rejecting it with an INVALID_ENUM error on the configuration that does not support it. There are probably cases where we don’t do that properly, but again, if you find one, it’s a bug and I will fix it.
Relying on wglGetProcAddress to determine extension availability is a quick and certain path to a compatibility nightmare.
Likewise, relying on whether an enumerant appears to generate an INVALID_ENUM error is a bad way to determine extension availability.
Now, your question only concerned function pointers, but enumerants come up pretty quickly when you start talking about extensions. For example, with texture compression, one way you can use the extension is to pass, e.g., COMPRESSED_RGB_ARB to TexImage2D and have the driver perform compression. In this case, it seems you’re in trouble. If you trust the extension string, you’d never know that you could pass COMPRESSED_RGB_ARB as the internal format. But if you distrust it and check for extension availability by trying to pass it and seeing if you get an error, well, that’s no good either.
As for how to solve your particular problem, I don’t know…
It might also that they forgot to put it in the strings, because their Ati.h header has all the tokens and fonctions typedef for textures compression!
Ati really got to clean up that stuff. I wonder why they don’t try to copy Nvidia unified architecture, which is pretty clever, instead of maintaining 3 dozens drivers?.
Right now it is feeling really weird : They didn’t release any new drivers in a month, not even a new beta version, and it is suppose to be their flag ship product and they got a bunch of issues…hmmm I am starting to think that the 200$ more that I could have paid might had been worth it… (what an ugly sentence, for the english!)
[This message has been edited by Gorg (edited 10-23-2000).]
I’m initialising the pointers to NULL, calling wglGetFunction then checking if its still NULL. I’ve not had any problems so far. I guess I’ll just have to watch out and email ATI dev rel again. I bet they’re sick of me now - maybe thats why they haven’t replied to any of my emails
I think the safest way is not using an extension that is not in the extensions string. Or else you should write a 3d card detector and you must decide what to use and what not - and this could be dangerous too. The only thing you can do (I think) is to tell the dev support that they missed something and wait for a newer driver.
