Hardware Buckets

Yesterday I went off on a rant about how the OpenGL 3.0 spec doesn't matter a lot because OpenGL grows via a la carte extension.  And I mentioned that this creates a dilemma for anyone designing a rendering engine that has to run on a wide range of hardware, with very different underlying capabilities.

Back in the old days of X-Plane 6, there wasn't a lot of variety in hardware.  Some cards were faster than others, but the only real difference in capability was how many texture units you had. X-Plane's job was simple...

• First we have a runway texture.
• Still got a second texure unit?  Great!  Skid marks!
• Still got a third texture unit?  Great!  Landing light!
• Got another one?  Etc...

Other than texture stacking, there wasn't much to do.

Since then the rendering engine has become a lot more complex, as have OpenGL cards.  To try to keep the combinations down, I tried to use a "bucketing" strategy for X-Plane 9.  The idea of bucketing is to group cards into major buckets based on whole sets of common functionality, so that we only have to test a few configurations (the "low end" bucket and "high end" bucket), rather than having to test every single card for its own unique set of features.

The obvious bucketing choice was pixel shaders - given a card with shaders and a few other features, we can render all of the new effects.  A card without shaders basically gets X-Plane 8.

So what went wrong?  Driver compatibility, that's what.  Ideally we don't want to allow every single underlying rendering engine feature to be turned on or off individually because the combinations are uncontrollable.*  But in practice, being able to turn features on and off is necessary to trouble-shoot drivers that don't always do what we expect them to.

With the GeForce 8800 and Radeon HD cards, there is a potential third bucket for DirectX-10 capable cards, capable of significantly more advanced pixel shading effects.  But time will tell whether we can actually make a bucket, or we have to look at each feature individually.  My suspicion is that even if we organize the shipping features into buckets, we'll have to support a lot of combinations under the hood just to trouble-shoot our own application.

*Example: cross a standard vs. oversized panel with the presence or absence of advanced framebuffer blending, crossed with whether render-to-texture works. That's 8 possible ways just to render the 3-d cockpit panel texture.  Cross that with panel regions and 3-d cockpits and the new panel spotlighting and you have 64 configurations. Ouch!