The OpenGL Roadmap - The hows and whys

Posted by Nick Haemel on March 16, 2009

I have seen many concerns, questions, comments, etc on the progress of OpenGL over the last few years. Some are positive, some not. But what really seems to be lacking is a clarity on the how and why.

OpenGL 3First, OpenGL is a public and open specification that is available for all to read and program for. It is written by a consortium of companies and individuals within the Khronos Group who have an interest in 3D graphics. Generally speaking, considerable time and effort is volunteered by these groups to help promote open 3D graphics specification. Modern OpenGL specifications are not the creation of one company or individual. OpenGL is intended to work on a considerable selection of platforms, making code very portable between operating systems. OpenGL is intended to work on many levels of hardware, allowing the same application to run on various graphics chips. I'd argue OpenGL related specs (OpenGL ES/SC/etc) are some of the most portable APIs for 3D graphics.

So how exactly does an OpenGL specification get written? The ARB looks at hardware capabilities and corresponding OpenGL extensions to determine candidates for inclusion in a future version. Input on feature candidates is gathered from industry players and individuals. Features are then prioritized by general usefulness and future compatibility, and then added to the core language. Simplified, a new feature goes from Idea --> Vendor/ARB Extension --> Core OpenGL Specification, assuming hardware is capable.

Why use this process? One reason is that extensions provide an efficient proof-of-concept. The idea has been tried. Its weaknesses and strengths are known and can be addressed as the extension is promoted to core. Another reason is that free-form design by committee is cumbersome and error prone at best. The side-effect of this process is that the core specification may lag behind some hardware and vendor extensions. But the final core specification is more stable and predictable.

A really common question I have seen is "I see feature XYZ in the DX spec, why isn't it in OpenGL?" There are several reasons. First and most importantly, OpenGL is a unique, separate, and independent specification. It does not, and should not follow any other API. Second, OpenGL makes decisions that are in the best interest of the industry, not of one company.

How can you help?
Given that new OpenGL features are likely to come from extensions, contact IHVs and Khronos members with constructive feedback of what you need and what types of features you think will be helpful. Use vendor specification extensions, let us know which ones are most helpful and would make good candidates for core features. OpenGL is our 3D graphics API. We can work together to make it the best API for the future of graphics.

Khronos ARB frequent contributors (AMD, Apple, ARM, Blizzard, IBM, Intel, Imagination Technologies, Nokia, NVIDIA, Transgaming, many others)

Tags: 3D, General


instead of just adding new extensions to core it might be a good idea to cleanup the cumbersome api. because this is what lacks in opengl: actual evolution.
I'm curious as to how the deprecation model will play into future API revisions, and if we should expect further deprecation in 3.1.
It's rather odd to say that OpenGL shouldn't follow any other API, yet you also say that OpenGL's decisions are in the best interests of the industry, not one company. I say this is odd because I don't know of the industry you refer to that wants their graphics API to *not* expose useful, powerful, and important hardware rendering features to the user. You also seem to be addressing the wrong problem. The OpenGL roadmap, extensions to core, has never really been the problem with OpenGL. OpenGL has had 3 fundamental problems: 1: The time difference between hardware features appearing and those features being *exposed* across all hardware vendors through OpenGL. In some cases, hardware has languished unused in OpenGL for *3 years* before getting an appropriate extension. This continues to this day; there are several "DX10" and above features that have existed for years and are not exposed by OpenGL in platform-independent extensions. 2: The quality of those extensions. That is not a reference to the quality of the IHV implementations; I am speaking of the extensions themselves. 3: Unreliability of implementations. As much as you like to tout OpenGL's portability, reality doesn't bear this out. It is very often the case that OpenGL code tested on an nVidia implementation will fail on an ATi one, and vice-versa. That doesn't even come close to Intel's virtually unusuable OpenGL implementations for their hardware. A conformance test suite would go a long way in helping the IHVs at least be assured of reasonable conformity among them. ATi also has the stated position of only implementing ARB-class extensions, so vendor-specific extensions that they might be able to implement go unimplemented.
Page 1 of 1 pages

Add your comment

Note: All comments are moderated for spambots so there will be a posting delay.
Your email address will not be published.

Anti Spam: Please enter the word you see in the image below: