OpenGL 2.0 - Out To Save Programmable Graphics

An Answer Appears To Be At Hand, And The News Is Encouraging, Continued

The most immediate step to creating an advanced OpenGL standard will be to combine backward compatibility with OpenGL 1.3, while maintaining parity with DirectX by incorporating required features such as vertex and pixel processing,and memory management.

In phase one, OpenGL will maintain complete backward compatibility with Open GL 1.3. In order to accomplish this, OpenGL 2.0 will consist of the existing functionality of OpenGL 1.3, combined with new functionality in a completely compatible way. This is illustrated in Figure 2. The advantage of this process is that it will also start streamlining the tangle of extensions that have grown up around the ARB's stagnated progress. Also, the implementation of hardware programmability provides a much better path for integrating existing extensions.

The next step will be to synthesize a "Pure OpenGL 2.0" that provides a more streamlined API for developers. This will be accomplished by documenting certain OpenGL features as "legacy" features, and by educating developers to use the more flexible programmable features, rather than the fixed functionality features. This is shown in Figure 3.

3DLabs is already well on the way to defining the spec, and they've delivered OpenGL 2.0 white papers www.3dlabs.com/support/developer/ogl2/index.htm . The company says they have a straightforward plan to change the very nature of OpenGL, which 3DLabs says is currently inflexible. Rather, they say, they'll use programmability to take a fast path to the features most urgently needed. And, they say, they'll identify those features by looking at the extensions and putting a priority on the areas where the most changes have been requested.

The plan calls for keeping fixed functionality where flexibility is not required and where hardware implementation is the cheaper, more efficient approach. For example, such functions as frustum clipping, backface culling, viewport mapping, etc., can remain as fixed functions; also, frame buffer operations involving read/ modify/ write operations are well suited to hardware implementation. The goal is to extend programmability to all OS platforms and all hardware platforms.