Coinciding with a mobile-heavy CES 2014, back in January Khronos put out a short announcement stating that they were nearing the release of a new version of OpenGL ES. Dubbed OpenGL ES Next, we were given a high level overview of the features and a target date of 2014. As it turns out that target date was early 2014, and with GDC 2014 kicking off this week, Khronos is formally announcing the next version of OpenGL ES: OpenGL ES 3.1.

Compared to OpenGL ES 3.0, which was announced back in 2012, OpenGL ES 3.1 is a somewhat lower key announcement. Like mainline OpenGL, as OpenGL ES has continued its development it has continued to mature, and in the process the rate of advancement and need for overhauls has changed. As such OpenGL ES 3.1 is geared towards building on top of what ES 2.0 and 3.0 have already achieved, with a focus on bringing the most popular features from OpenGL 4.x down to OpenGL ES at a pace and in an order that makes the most sense for the hardware and software developers.

Version numbers aside, with OpenGL ES 3.1 Khronos has finally built out OpenGL ES to a point where it can be considered a subset of OpenGL 4.x. While OpenGL ES 3.0 was almost entirely constructed from OpenGL 3.x features, OpenGL ES 3.1’s near-exclusive borrowing of OpenGL 4.x features means that a several pieces of important functionality found in OpenGL 4.x are now available in OpenGL ES. Though at the end of the day it’s still a subset of OpenGL that’s lacking other important features.

Anyhow, as it turns out the early OpenGL ES Next announcement was surprisingly thorough. Khronos’s January announcement actually contained the full list of major new features for OpenGL ES 3.1, just without any descriptions to go with them. As such there aren’t any previously unannounced features here, but we do finally have a better idea of where Khronos is aiming with these features, and what kind of hardware it will take to drive them.

Compute Shaders

Compute shader functionality is without a doubt the marquee feature of OpenGL ES 3.1. Compute shader functionality was first introduced in mainline OpenGL 4.3, and at a high level is a much more flexible shader style that is further decoupled from the idiosyncrasies of graphics rendering, allowing developers to write programs that either weren’t possible using pixel shaders, or at best aren’t as efficient. Compute shaders in turn can be used for general purpose (non-graphical) programming tasks, however they’re more frequently used in conjunction with graphics tasks to more efficiently implement certain algorithms. In the gaming space ambient occlusion is a frequent example of a task that compute shaders can speed up, while in the mobile space photography is another oft-cited task that can benefit from compute shaders.

The increased flexibility is ultimately only as useful as software developers can make it, but of all of the features being released in OpenGL ES 3.1, this is the one that has the potential for the most profound increase in graphics quality on mobile devices. Furthermore compute shaders are based on GLSL ES, so they can be a fairly easy shader type for developers to adopt.

Separate Shader Objects & Shading Language Improvements

Speaking of shaders, there are also some smaller shader improvements coming in OpenGL ES 3.1. Developers can now more freely mix and match vertex shader and pixel shader programs thanks to separate shader object functionality, breaking up some of the pipelining imposed by earlier versions of OpenGL ES 3.0. Meanwhile 3.1 also introduces new bitfield and arithmetic operations, which should make desktop GPU programmers feel a bit more at home.

Indirect Draw Commands

Even with the tightly coupled nature of SoCs, SoC-class GPUs generally aren’t much better off than desktop GPUs when it comes to CPU bottlenecking. Consequently there’s performance (and quite possibly battery life) to be had by making the GPU more self-sufficient, which brings up indirect draw commands. Indirect commands allow the GPU to issue its own work rather than requiring the CPU to submit work, thereby freeing up the CPU. Khronos gives a specific example of having a GPU draw out the results of a physics simulation, though there are a number of cases where this can be used.

Enhanced Texture Functionality

Finally, OpenGL ES 3.1 will also be introducing new texture functionality into OpenGL ES. Texture multisampling is now in – a technology useful for using anti-aliasing in conjunction with off-screen rendering techniques – as is stencil textures. Texture gather support also makes an appearance, which allows sampling a texture in a 2x2 array of textures and is useful for texture filtering.

Moving on, for today’s release Khronos also laid out their plans for conformance testing for OpenGL ES 3.1. OpenGL ES 3.1 has already been finalized – this isn’t a draft specification – so the specification is done, however the conformance tests are still a work in progress. Conformance testing is largely an OEM concern, but from a consumer perspective it’s notable since it means that OEMs and chip/IP vendors technically can’t label their parts as OpenGL ES 3.1 compliant until they pass the necessary tests. Khronos tells us that conformance tests are expected to be available within 3 months, so we should see conformance validation shortly after that.

Finally on the hardware side, again not unlike mainline OpenGL, OpenGL ES 3.1 is designed to be implemented on existing hardware, with many aspects of the standard just providing a formal API to functionality that the hardware can already achieve. To that end, Khronos tells us that a number of existing SoC GPUs will be OpenGL ES 3.1 capable; so OpenGL ES 3.1 can be rolled out to the public without new hardware in those cases.

Unfortunately we don’t have a list of what GPUs will be ES 3.1 capable – the lack of conformance tests being something of a roadblock. But in Khronos’s full press release both NVIDIA and Imagination Technologies note that they expect to fully support OpenGL ES 3.1 in their Kepler and Rogue architectures respectively. No doubt we’ll hear more about this in the coming weeks and months as the other SoC GPU vendors cement their OpenGL ES 3.1 plans and pass their conformance tests.