OpenGL 2.0 - Out To Save Programmable Graphics

OpenGL 2.0: Programmable, Scalable, And Extensible, Continued

Many of the members of the OpenGL ARB work with DirectX as well as OpenGL. They clearly recognizethe desirability of furthing OpenGL because it offers them the ability to deliver their products across hardware platforms.

But there's a glitch in DirectX as well, and that is apparent in the evolution of DirectX 8: on the one hand, we have Nvidia's DirectX 8 with programmable shader version 1.2, and then there's ATI's approach, which Microsoft has designated as DirectX 8.1 with programmable shader version 1.4. The two different approaches enable access to programmable hardware, but each uses different a register architecture. This is not a situation that's inviting to ISVs, either. In theory, DirectX 9 is planned to solve the problem with an approach that is hardware-independent. But, notice the renaming of DirectX 10 as DirectX 9.1, demonstrating that the Microsoft path is not as straightforward as some would hope, either.

Further, with DirectX, Microsoft continues to prioritize the needs of the much higher-volume consumer market over the professional market that OpenGL has served well. Given the more conservative nature of most of the professional graphics application developers, an evolution of OpenGL has great appeal for the professional segment, even on Windows operating systems.

If you threw a rock at Siggraph last year, you might well have hit someone in the industry who would say that Nvidia made a very good run at stealing hardware programmability by convincing Microsoft to adopt its approach into DirectX 8 first. Nvidia was also proactive in educating developers on the use of these new programmable features. ATI opened up the debate with its own approach, and the problem became evident. The ISVs have chimed in now because they're very aware of the danger of being limited to one hardware vendor for something as critical as graphics programmability. Furthermore, why stop at Windows?

The debate has carried over into OpenGL, where up to now the attempts at bringing programmability into the API have happened through the extensions procedure. This has contributed to the bewildering number of extensions, and the same issues of hardware-centricity were emerging and subsequently complicated by IP issues. (Over 230 OpenGL extensions have been defined. Nvidia's extension documentation is 500+ pages, while the OpenGL 1.3 specification itself is only 284 pages.) So, OpenGL faces a number of critical issues.

Although today OpenGL can be implemented on a chip, lately the ARB has been working backwards and discussing which features from existing chips to standardize, hardly a positive dynamic for a forward-looking industry standard. OpenGL does not provide hardware independent access to the new programmable processors, so the current direction is to expose multiple hardware architectures through vendor-specific extensions. However, IP (intellectual property) threats have been holding up broader adoption of these extensions. The question being asked is: are IP issues causing a lack of progress or are they a symptom of a deeper problem?