Some Thoughts on OpenGL 3.0

Its been a while since the OpenGL 3.0 standard was announced at SIGGRAPH (prior to which it was known to be in development under the codename "Longs Peak") and I haven't posted my thoughts yet. Well, since the launch is slated for September, and that happens to be coming soon, I figured I'd give a few brief observations and opinions on what I can gather from the available information (which mostly consists of the conference presentation material they compiled for SIGGRAPH this year).

The first thing I have to note is the large amount of vestigial crap being removed from the API this time around, which is one of the primary decisions that qualify this as the first major revision of OpenGL functionality. The first thing I noticed was the complete removal of the procedural, one vertex at a time method of drawing geometry. All I have to say is: GOOD! The old glBegin()/glEnd() tags with vertex (or color) vectors in between was obviously useful when OpenGL was a high level fish in a pond of low-level competitors (Glide being the predominant example), and was sort of semi-cute around the time of the 1.3 and 1.4 standard. But they're nothing but an extraneous and cumbersome appendage when you have consumer/enthusiast level graphics hardware that execute 400 gigaflops per second (i.e., the GeForce 8800 GTS) and applications that demand a poop-load of geometry be modeled and/or rendered simultaneously. These things should have been sliced off the core API long ago, when vertex arrays and display lists were decidedly superior methods.

Of course we shouldn't get too comfortable with the latter methods either, since the new implementation appears to be getting rid of them in favor of the shader-based methods native to GLSL. In fact, that appears to be a common theme. Just about every method in the fixed-functionality of the pre-GLSL standard that overlaps with the programmable shader model has been scrapped in favor of the latter. This is a good step to take for any API, since just about everything in high-end graphics apps has been done through shaders for a number of years now. Its interesting to note that in the recently released GPU Gems 3, every article assumes a shader based approach almost as naturally as a compiler level implementation.

Of course, with the emphasis now being on exploiting programmable GPU's instead of binding everything to a fixed rendering pipeline, that pretty much means that the state-based model of OpenGL is dead in the water. In it's stead, an object-based model has been erected. Back in the day, one of the big advantages of OpenGL over Direct3D was that you had plenty of queries that you could call so that the state of the machine wasn't obscured. Now of days that isn't so much of an advantage as the state-machine model is obsolete. Its better for OpenGL to adapt to the current shader-oriented trends, since it can then compete more aggressively with Direct3D by offering a cross-platform, non-hardware specific standard that offers the features that make Direct3D so attractive to developers right now.

And of course there is the atomistic way that objects are implemented, which is obviously going to make multi-threaded rendering code much easier to deal with. You can share between rendering contexts on a per-object basis, where the objects are immutable once you define them. This eliminates those annoying scenarios where an object is deleted in one context while being used by another, or being scaled/sheared/whatever while being in use by another, etc. This produces a sort of "strong typing" effect for the graphics API, since you know for sure what an object is. That is advantageous even if you lose much of the "flexibility" of the current object creation model.

Its an exciting time to be in graphics, with all the major shifts going on. You have two intensely competitive APIs (Direct3D 10 and OpenGL 3.0) that could end up providing us with the same level of innovation that the NVidia/ATI wars bestowed upon us for years. Only time will tell, in the mean time I can screw around with all this new technology, presumably starting in September. :)