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

  • Pixel Shaders and Moore's Law
    In my post on 64-bit computing and X-Plane, there's a point that's implicit: there is a cost (in development time) to adopting any ...
  • Hierarchy and WED
    I just finished fixing some bugs in WED regarding the hierarchy view. (To get a sense of what a hierarchy view is like, try AC3D...) In WED...
  • Is Bigger Always Better?
    We've been preaching "one big texture, not lots of little textures" for a while now, and generally speaking, packing a lot of ...
  • Systems Modeling and Physics Modeling
    In past blog posts I have tried to contrast two very different different approaches to simulation, which I would loosely call: "Predic...
  • How Framerate Dies - Glitching
    Back in the good old days (that would be X-Plane 6), X-Plane's framerate would suffer in two ways as you cranked up the rendering option...
  • The X-Desktop and iPhone Are Not Zero-Sum Games
    On the menu this morning: first a whiny rant, then a nerdy one. Someone pointed me at this post. Before I go into my geeky diatribe about l...
  • Clean Airport Layouts
    I have blogged about correct airport layouts before, but let me bring the point up again, because it is so important: You must create struc...
  • So How Big of a Mesh Can You Build?
    I get asked about the maximum mesh density in X-Plane a lot. First, I must note that X-Plane's mesh is adaptive - the triangles are not ...
  • 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...
  • Why Do Custom Lights Use the Object Texture?
    I am trying to be disciplined and put documentation on the X-Plane wiki , and limit the blog to announcements, rants, and explanations of wh...

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