OpenGL 3.0

First, major revisions to the OpenGL specification simply don’t matter that much.  OpenGL grows by extensions – that is, incremental a la carte additions to what OpenGL can do.  Eventually the more important ones become part of a new spec.  But the extensions almost always come before the spec.  So what really matters for OpenGL is: are extensions coming out quickly enough to support new hardware to its fullest capacity?  Are the extensions cross-vendor so that applications don’t have to code to specific cards?  Is the real implementation of high quality?

So how are we doing with extensions?  My answer would be: “okay”.  When the GeForce 8800 first came out, the OpenGL extensions that provide DirectX 10-like functionality were NVidia-specific.  Since then, it has become clear that all of this functionality will make it into cross-platform extensions, the core spec, or some of each.  But for early adopters there was a difficult point where there was no guarantee that ATI and NVidia’s DirectX 10 features would be accessible through the same extensions.

(This was not as much of an issue for DX9-like features, e.g. the first generation of truly programmable cards.  NVidia had a bunch of proprietary additional extensions designed to make the GeForce FX series less slow, but the basic cross-platform shader interface was available everywhere.)

Of more concern to me is the quality of OpenGL implementations – and for what it’s worth, I have not found cases where a missing API is standing between me and the hardware.  A number of developers have posted concern that OpenGL drivers are made too complex (and thus too unreliable or slow or expensive to maintain) because the OpenGL spec has too many old features.  I have to leave that to the driver writers themselves to decide!  But when we profile X-Plane, we either see a driver that’s very fast, or a driver that’s being slow on a modern code path, in a way that is simply buggy.

Finally, I may be biased by the particular application I work on, but new APIs that replace the old ones don’t do me a lot of good unless they get me better performance.  X-Plane runs on a wide range of hardware; we can’t drop cards that don’t support the latest and greatest APIs.  So let’s imagine that OpenGL 3.0 contained some of the features whose absence generated such fury.  Now if I want to take advantage of these features, I need to code that part of the rendering engine twice: once with the new implementation and once with the old implementation.  If that doesn’t get me better speed, I don’t want the extra code and complexity and wider matrix of cases to debug and test.

In particular, the dilemma for anyone designing a renderer on top of modern OpenGL cards is: how to create an implementation that is efficient on hardware whose capabilities is so different.  I’ll comment on that more in my next post.  But for the purposes of OpenGL 3.0: I’m not in a position to drop support for old implementations of the GL, so it doesn’t bother me at all that the spec doesn’t drop support either.

The real test for OpenGL is not when a major revision is published; it is when the next generation of hardware comes out.