Spurred by inderstry needs and requsts, Khronos fills a tall order, Delivering a new OpenGL point release just months after the previous one.
SIGGRAPH is a major milepost and gathering point for the far-flung members of the Khronos organization. As such, the group always has an important announcement or two to make during this event. This year, the members of the OpenGL ARB working group announced OpenGL 3.2, the group’s latest evolution of the OpenGL API, last updated just nine months ago at GDC 2009 and a continuation of the OpenGL 3 platform launched at SIGGRAPH a year ago in Los Angeles.
Just the fact that the point releases are coming thick and fast is significant for OpenGL. Khronos president Neil Trevett notes that they’re thinking of the larger OpenGL releases as platforms, with point releases following rapidly to meet the demands of software developers and to match and drive advances in hardware. What he’d like people to understand about the OpenGL 3.0 release last year and the subsequent 3.1 and 3.2 sub-releases is that the API is now evolving to a schedule, and the group is moving quickly to add the features needed by hardware manufacturers and requested by the developer community.
Barthold Lichtenbelt is the group chair for the OpenGL Architecture Review Board (ARB). While Lichtenbelt is not revealing whether there will be another point release (OpenGL 3.X) before the group is ready with OpenGL 4, he doesn’t expect the group to have to wait a full year until SIGGRAPH 2010 to release the next spec—a fairly astounding assertion coming out of OpenGL.
Regular updates according to a deadline were not always a modus operandi of the OpenGL ARB. Not because it couldn’t do things more quickly, but because OpenGL was once a monolithic standard designed for all graphics applications. The group eventually developed the idea of feature deprecation—being able to spin off consistent, compliant subsets of the parent standard—to enable API streamlining and profiles to serve the diverging demands of the increasingly broad constituency in the software development world. And, eventually, Khronos united with OpenGL ARB, enabling the coordination of OpenGL and OpenGL ES for new devices and applications.
The Khronos Group and the OpenGL ARB joined forces in 2006 to streamline the development process of various OpenGL family members, including Khronos’ OpenGL ES for mobile devices. As the groups came together, the OpenGL group benefitted from the dynamics of the Khronos Groups, which have had to move fast to keep up with the mobile device industries. The reunion of OpenGL with its spin-off, OpenGL ES, and the broader interests of the Khronos Group as a whole, enables OpenGL to become a key and central part of a broader open API ecosystem.
A New Relationship
Khronos has developed a tight relationship between OpenGL and OpenCL (Open Computing Language). OpenCL was proposed by Apple and developed at the Khronos Group. It is a framework for writing programs that execute across heterogeneous platforms, including CPUs, GPUs, and other processors. OpenCL includes a C-based language for writing functions and applications that operate on OpenCL devices; it also includes APIs to take advantage of, and control, the hardware platform.
With OpenGL 3.2, OpenCL and OpenGL continue to be complementary; they can sit side by side and share resources efficiently, including memory buffers. For example, suggests Trevett, OpenCL could be used to generate geometry and feed it to OpenGL to create images that can be fed back into the pipeline for further use by OpenCL.
OpenCL is yet another example of the way programmability is changing the way applications are developed and the way visual processing capabilities can be extended. If a software developer needs compute functionality beyond OpenGL, it can program that itself in OpenCL. It’s an expansion of the freedom bestowed on content creators by way of programmable hardware shaders, introduced with DirectX 9 and OpenGL 2.0. Programmable shaders mean you can define a scene with lights, colors, geometry, and camera angles, and accelerate its creation in the computer with hardware. It was the dawn of customizable computer graphics and the end of uniform, canned effects. Now, OpenCL extends that capability to a broader range of applications and enables heterogeneous computing to boot.
The development of OpenGL and OpenCL will continue together, says Trevett and OpenGL chair Lichtenbelt. They will remain complementary, and it is likely that some of the capability of OpenGL will be absorbed by OpenCL over time as the APIs are evolved to serve broader and broader applications of visual computing for visualization and simulation that need tighter and tighter integration of graphics and computing.
For Apple and other companies working outside the Microsoft sphere of influence, OpenGL represents a way to develop applications for GPU acceleration without waiting to see how Microsoft will do it in DirectX. Trevett notes that one of the stated goals of OpenCL is to become a significant input to drive GPU design. Apple is one company that doesn’t want to have to wait on Microsoft to know what to do next, and it’s certainly not the only one.
Working in Tandem
In other business, the OpenGL group has set up an alliance with the OpenGL ES group to share information about their respective APIs and road maps so the APIs are in sync—setting up the possibility for increasing synergy between OpenGL and OpenGL ES content and tools.
Speaking of being in sync, the OpenGL working group has put considerable work into OpenGL 3.2 for improving the ability of developers to work with both OpenGL and DirectX; the reality is that many developers do have to write to both APIs, especially if they’re developing programs that will run on both Macs and Windows-based machines. Lichtenbelt says that often the two APIs differed in trivial and unnecessary ways. For instance, one API might start drawing pixels from the upper right of the screen and the other from the upper left. These things are easy enough for programmers to work around, but if they don’t have to, why should they? And, OpenGL 3.2 enables OpenGL to adapt to DX conventions so that DX content can be more easily ported to OpenGL platforms.
The Future
As geeky as all this is, it’s really exciting because of all the cool, new capabilities and programs that it enables. The beauty of the Khronos Group is that it doesn’t stop with graphics; the group was formed to enable the development of multimedia APIs for all platforms, including phones, mobile devices, set-top boxes, and whatever else comes down the pike. At SIGGRAPH, the Khronos Group also revealed some of its plans for the future, including another run at 3D APIs for the Web—taking a fresh and different angle to plug-in based approaches of the past. Khronos’ new road map includes WebGL. WebGL will marry a variety of technologies to advance 3D and animation on the Internet by defining OpenGL ES bindings to JavaScript and leveraging HTML 5.
HTML 5 is the next revision of HTML, the core language of the World Wide Web. It has been designed to enable a broad variety of capabilities in browsers without the need for multimedia plug-ins for 3D and video, such as Flash, Silverlight, and JavaFX. As you might expect, this is creating interesting discussions as various companies fight hard to protect their turf, and even harder to protect their royalties for things such as video codecs.
Enter Khronos. Royalty-wise, 3D on the Web is an easier problem than video—thanks to the long-standing, open, royalty-free movement built around 3D technology. The powerful partners within the Khronos organization have been joined by the major browser vendors and are taking on WebGL as a way to leverage HTML 5 for 3D and animation on the Internet without requiring plug-ins. There’s a fine synergy going on here. The World Wide Web Consortium (W3C) lists Ian Hickson from Google and David Hyatt from Apple as editors of the HTML 5 specification. Both men’s companies are members of Khronos, and both companies want to see the Web become a framework for plug-in free, interoperable RIAs. This is truly a case of building it so everyone can come in and play—and could enable rich 3D Web content and user interfaces—unleashing the gates of developers’ imaginations to create all sorts of cool stuff that really hasn’t been possible until the walls come down.
Think about the involvement of Apple in all this, if you haven’t already. Apple has made no secret of its dissatisfaction with Flash, and it’s at least arguable that what it doesn’t like is that the offering belongs to Adobe. An open standard is preferable, and an open standard that Apple helps define is better yet. It will also ensure that the standard gets really good codecs and that they’re updated. Come to think of it, the presence of Google doesn’t hurt, either. Both companies need ways for multimedia to run on mobile devices within browsers.
Even if HTML 5 and WebGL succeed, there will be healthy competition with proprietary technologies, such as Flash, Silverlight,