Search

ReCode /

OpenGL Madness

Through my career I've been working with proprietary graphics APIs, but Apple platforms use OpenGL and since it is also available on Windows and on other OSes, it seems the right choice for graphics today.

It also feels good to support an open standard like that. I love open standards. For example I find it ridiculous that Windows is not POSIX; even though it does serve their corporate interests, Apple demonstrated that the same corporate interests can be served with a POSIX-compliant OS.

And then OpenGL showed its ugly head.

Extensions

How has OpenGL survived for so many years? By extensions.

Every time a graphics chip manufacturer implements a cool new feature in hardware, OpenGL allows them to provide whatever functions they feel like in the form of extensions. For example, if ATI needed to implement a cool new function, they simply document it and compile it in the video driver shared libraries/DLLs, using a function name like glCoolNewFeatureATI.

If two or more graphics chip manufacturers agree on the same API for a cool new feature, then the OpenGL stardard allows them to use the suffix EXT: glCoolNewFeatureEXT. That way, programs can look for and link to that function without having to know what graphics hardware they're running on.

Then there is the OpenGL Architecture Review Board which looks at various extensions that appear and if they like an EXT function, it gets the ARB blessing and vendors are allowed to use the suffix ARB with the name, so we get glCoolNewFeatureARB.

Finally, most (all?) ARB functions are made part of the next revision of the OpenGL standard, at which point all suffixes are dropped and we're left with glCoolNewFeature added to the rest of the OpenGL functions.

That's how committees work: because nobody is in charge, nobody can take the responsibility for making the correct architectural decision. Because nobody can take that responsibility, it is necessary to have a cumbersome system of checks and balances to minimize the possibility of breaking the standard.

But the result is a mess anyway. Users end up with potentially 4 different versions for many OpenGL functions. Which one should they call?

You might think that a reasonable approach is to look up the suffix-less version first, if that fails look up the ARB version, and if that fails look up the EXT version, and finally if that also fails just announce to the user that their OpenGL driver sucks and exit. But that's easier said than done.

For starters, some of these functions take enums as parameters. The names of the enums also feature the corresponding suffix. For example, a possible value for the first parameter of glBindBufferARB is GL_ARRAY_BUFFER_ARB, but if you're calling glBindBufferEXT you should be using GL_ARRAY_BUFFER_EXT instead, and if you're calling simply glBindBuffer then you'd use GL_ARRAY_BUFFER.

This arrangement makes it difficult for the graphics programmer to abstract the logic for selecting the correct function: it isn't sufficient to simply store a function pointer or something similar. The only viable solution is to create a wrapper layer over OpenGL with its own naming conventions and its own enums, which then get translated depending on which of the 3 or 4 variants of the function should be called on the target platform.

Or, you could just pick one variant and use only that or fail if it isn't available. For example, I thought that it is reasonable for my program to require vertex buffer support in the OpenGL driver, so I started writing code which simply calls glBindBuffer without any suffixes. And it turned out that on my system glBindBuffer is available but is broken. glBindBufferARB is also available, and it works fine.

So, I feel stuck. So much so that blogging about the problem seemed more appealing than trying to figure out what's the correct solution. :)

rotoglup — 21 May 2010, 10:12

Your 'glBindBuffer' requirement is more than reasonable ! It is a core feature since GL 1.5...

Ok, the extension jungle is a pain. But bad GL implementations remain the main problem.

I don't have experience on Mac + GL though... On Windows, OpenGL + Intel graphics is a "no go" zone for us.

Emil — 21 May 2010, 14:17

Reasonable it is. It also crashes on my laptop -- which admittedly is old and has crappy Intel graphics -- yet glBindBufferARB works fine.

Assuming that it's more important for my program to work than to be reasonable, I still don't know what's the best way to deal with this issue.

Add comment: 
Sign as author: 
Add 1 to 405 and enter it here: 

Formatting hint: when posting comments, surround code blocks in [@ and @].