Tech Support Blog

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Tuesday, 9 September 2008

OpenGL 3.0

Posted on 14:21 by Unknown
A few people have asked me about OpenGL 3.0 - and if you read some of the news coverage of the OpenGL community, you'd think the sky was falling.  In particular, a bunch of OpenGL developers posted their unhappiness that the spec had prioritized compatibility over new features.  Here's my take on 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.
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in hardware, performance, political | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Developer Hardware
    So...just how awesome is my main development machine? Not that awesome. Periodically users ask me what my setup is. Usually the user wants...
  • That's one biiiiig polygon
    Something I'm seeing now that WED is in beta: airport layouts with the entire taxiway structure made from one really complex polygon. I...
  • Caught With My Pants Down
    My friends say I have become a technological curmudgeon...whenever a new gadget or device or operating system comes out, I just grumble abo...
  • Who Am I?
    This week we've seen an increase in questions from new users, potential customers (both in the consumer and professional spaces) and thi...
  • Mirrored Normal Maps
    Normal maps in X-Plane 940 have a funny property: if you flip the normal map horizontally or vertically, the bumps change direction. Things...
  • What is a panel region?
    X-Plane 9 introduces a new OBJ feature: panel regions. The basic idea is this: In X-Plane 8 you could use the 2-d panel as a texture in you...
  • The Future of WED
    WED 1.0 has gone RC . The on ly change from beta 5 is that I have the latest manual changes from Tom (including Cormac's illustrations ...
  • The 3-d Panel Is Not Always Necessary
    There is no need to use the 3-d panel if you only want 3-d cockpit. That might be the most counter-intuitive statement in the entire univers...
  • OS X 10.6.3 Performance
    OS X 10.6.3 is out. Besides adding a bunch of OpenGL extensions*, it looks like vertex performance is improved on nVidia hardware. My quic...
  • Bad Alloc Crashes in 920 - Bad Timing
    I just received a series of reports today that certain converted scenery will cause X-Plane to crash with a "bad alloc" error. Ba...

Categories

  • absurdly cute
  • Air Traffic Control
  • aircraft
  • Android
  • animation
  • announce
  • cockpits
  • documentation
  • drivers
  • file formats
  • global scenery
  • Goofy Screenshots
  • hacks
  • hardware
  • hobbies
  • inside x-plane
  • installer
  • ipad
  • iphone
  • legal
  • localization
  • modeling
  • off topic
  • palm pre
  • panels
  • performance
  • plugins
  • political
  • scenery system
  • tools
  • X-Plane 10
  • XSquawkBox

Blog Archive

  • ►  2011 (12)
    • ►  February (1)
    • ►  January (11)
  • ►  2010 (111)
    • ►  December (4)
    • ►  November (4)
    • ►  October (10)
    • ►  September (9)
    • ►  August (12)
    • ►  July (8)
    • ►  June (4)
    • ►  May (13)
    • ►  April (13)
    • ►  March (11)
    • ►  February (12)
    • ►  January (11)
  • ►  2009 (130)
    • ►  December (16)
    • ►  November (11)
    • ►  October (6)
    • ►  September (16)
    • ►  August (12)
    • ►  July (11)
    • ►  June (9)
    • ►  May (5)
    • ►  April (10)
    • ►  March (9)
    • ►  February (9)
    • ►  January (16)
  • ▼  2008 (147)
    • ►  December (18)
    • ►  November (10)
    • ►  October (7)
    • ▼  September (11)
      • The Future of Triangles Part 5: The Technology of ...
      • The Future of Triangles Part 4: Pie in the Sky
      • The Future of Triangles Part 3: X-Plane 9
      • The Future of Triangles Part 2: X-Plane 8
      • Bad Alloc, New Patch, New Installers
      • The Future of Triangles Part 1: Terminology
      • Patches, Patches, Patches
      • I Can't Talk Now, I'm Flying a Plane!
      • Hardware Buckets
      • OpenGL 3.0
      • MeshTool vs. Draped Polygons
    • ►  August (15)
    • ►  July (9)
    • ►  June (14)
    • ►  May (9)
    • ►  April (14)
    • ►  March (13)
    • ►  February (6)
    • ►  January (21)
  • ►  2007 (100)
    • ►  December (17)
    • ►  November (13)
    • ►  October (13)
    • ►  September (9)
    • ►  August (17)
    • ►  July (7)
    • ►  June (4)
    • ►  May (6)
    • ►  April (9)
    • ►  March (2)
    • ►  February (3)
Powered by Blogger.

About Me

Unknown
View my complete profile