The Khronos Group has released two new versions of its 3D graphics APIs. The mobile-oriented OpenGL ES specification has been given a major upgrade to version 3.0, and the desktop OpenGL specification has received a minor update to bring it to version 4.3.

After some years of stagnation and an abandoned attempt to radically change the way OpenGL worked—during which time Microsoft's Direct3D API progressed in leaps and bounds—the Khronos Group has been developing new iterations of the OpenGL standard at a regular clip. While Direct3D has still been first to standardize certain new features, the OpenGL designers are quickly picking them up and integrating them.

OpenGL ES has risen to prominence primarily on the back of the iPhone and Android. Both iOS and Android use OpenGL ES as their 3D API, and the enormous growth in smartphone gaming has made OpenGL ES a critical API for many developers.

OpenGL ES 2.0 was first introduced in 2007, with hardware hitting the market in 2009-10. It was roughly based on the then-current OpenGL 2.x, stripping out OpenGL features that were needed only for backwards compatibility, and using a simpler set of data types and texture formats.

The new OpenGL ES 3.0 adds various features from OpenGL 3.x and 4.x. Shaders, the small pieces of code used to program GPUs, have been made more capable, with full support for 32-bit integer and floating point data. OpenGL ES 3.0 GPUs will support more complex textures—for example, textures with arbitrary sizes (instead of requiring the dimensions of each edge to be a power of two), and textures with floating point values.

The Khronos Group has added new compressed texture formats to OpenGL ES 3.0. Using algorithms devised by Ericsson, and available royalty free for anyone to implement, ETC2 and EAC provide a standard way to compress textures for OpenGL ES developers.

This fills an important gap in OpenGL ES. Texture compression is particularly important on mobile devices, as it reduces the amount of memory and bandwidth required to store textures. Direct3D hardware tends to use a compression algorithm called S3TC, but this is proprietary, and to use S3TC you must pay royalties to HTC.

OpenGL forbids the use of non-free algorithms, so it cannot use S3TC. Instead, each GPU vendor has tended to implement its own proprietary compression algorithms. This makes things difficult for developers, as they cannot rely on any particular set of features and have to distribute multiple versions of their textures, one for each algorithm.

The Khronos Group is working on a new compression algorithm, ASTC, that isn't a mandatory part of OpenGL ES 3.0, but might become compulsory in the future.

OpenGL ES 3.0 also has some new drawing capabilities, such as the ability to perform instanced rendering: one object (made up of a set of lines or triangles) can be drawn multiple times with a single command.

Even with the new features, OpenGL ES 3.0 is still somewhat behind Direct3D 10 and OpenGL 3.2 (and newer) in capabilities. In particular, OpenGL ES 3.0 doesn't include support for geometry shaders. These shaders can generate new lines and triangles, and can be used for tasks such as tessellation: taking an existing shape, and adding new lines to it to smooth out curves and make it look better.

Mobile hardware supporting OpenGL ES 3.0 should become available in 2013.

OpenGL 4.3 is a much smaller update. Many of the changes are to bring parity with OpenGL ES 3.0 to ensure that it remains a true superset of OpenGL ES.

The big new feature in GL 4.3 is support for compute shaders. Compute shaders allow graphics-oriented software to integrate GPU-based computation into their rendering engines. In the early days of GPU-based computation, developers had to pretend that their data was either pixel data, processed using pixel shaders, or line and triangle data, processed using vertex shaders and geometry shaders. These shaders were executed in a very particular order; essentially, data goes from the vertex shaders into the geometry shaders, and then (after the GPU does some processing) into the pixel shaders.

While this works, it is awkward for developers. They have to wrangle their programs to make them look as if they were operating on graphics data, and the involvement with the graphics pipeline means that it's awkward to use the GPU simultaneously to work on graphics and perform general purpose computation.

Compute shaders address this very issue. Compute shaders operate on general buffers of data, and operate separately from the graphics pipeline—while they can inject data into the graphics pipeline, they don't have to. This makes it much easier to use the GPU both for non-graphical tasks, such as physics or AI processing, and for advanced graphical processing such as raytracing.

In addition to these two new API versions, the Khronos Group has started development of a software library to make development of programs using its OpenCL computation API easier. Similar libraries already exist for OpenGL and Direct3D (called GLUT and DXUT, respectively). The OpenCL library will be called CLU.

OpenGL is 20 years old this year. Silicon Graphics published OpenGL 1.0 in January 1992. The Silicon Graphics RealityEngine, released in 1992, was spread across three to six circuit boards. The Geometry Engine board housed eight Intel i860XP CPUs at 50MHz each. Rasterization and texture storage were performed by one, two, or four Raster Memory boards, and display output was handled by a Display Generator board.

This powerhouse could process 1 million triangles per second and render 240 million pixels per second. Its total number-crunching power was about 0.64 billion floating operations per second.

Twenty years later, an NVIDIA GeForce GTX 680 can handle 1,800 million triangles per second, 14,400 million pixels per second, and has processing power totaling 3,090 billion floating point operations per second—between 60 and 4,830 times faster than the pioneering RealityEngine.