OpenGL SIGGRAPH 2014 Update: OpenGL 4.5, OpenGL ES 3.1, & More

Taking place this week is SIGGRAPH 2014, the graphics industry’s yearly professional event. As the biggest graphics event of the year this show has become the Khronos Group’s favorite venue for delivering news about the state and development of OpenGL, and this year’s show is no exception. This week will see Khronos delivering news about all of their major OpenGL initiatives: OpenGL, OpenGL ES, and WebGL, taking to the show to announce a new version of their core graphics API while also delivering updates on recent advancements in its offshoots.

OpenGL 4.5 Announced

Kicking things off, we’ll start with the announcement of the next iteration of OpenGL, OpenGL 4.5. As has become customary for Khronos, they are issuing their yearly update for OpenGL 4 at SIGGRAPH, further iterating on the API by integrating some additional features into the OpenGL core standard. By continually updating OpenGL in such a fashion Khronos has been able to respond to developer requests relatively quickly and integrate features into the OpenGL core as policy/standard issues are settled, however on the broader picture it does mean that as OpenGL 4 approaches maturity/completeness, these features do become a bit more niche as the major issues have since been solved.

To that end OpenGL 4.5 will see a small but important set of feature additions to the standard. The bulk of these changes have to deal with API alignment, with Khronos making changes to better align OpenGL with OpenGL ES, WebGL, and Direct3D 11. In the case of OpenGL ES, OpenGL 4.5 brings the two APIs back in alignment by updating the API to match the changes from this year’s release of OpenGL ES 3.1. Khronos intends for OpenGL to remain a superset of OpenGL ES, and by doing so allowing OpenGL devices to run applications targeting OpenGL ES, and for OpenGL ES developers to do their initial development and testing on desktops as opposed to having to stick to OpenGL ES-only devices.

Elsewhere OpenGL 4.5 is also adding some further Direct3D 11 emulation features to improve the ability to port between the two APIs. The APIs continue to have their corner cases where similar features are implemented differently, with the addition of Direct3D emulation features simplifying porting by offering versions of these features that adhere to Direct3D’s implementation requirements and quirks. Finally OpenGL 4.5 is also implementing further robustness requirements, these being primarily targeted at improving WebGL execution by enhancing security and isolation (e.g. preventing a GPU reset affecting any other running applications).

Meanwhile from a development standpoint OpenGL 4.5 will bring with it support for Direct State Access and Flush Control. Direct State Access allows objects to have their state queried and modified without the overhead of first binding those objects; in other words, bindless objects. Flush Control on the other hand sees limited command flushing being handed over to applications, allowing them to delay/avoid flushing in certain cases to improve performance with multi-threaded applications. This primarily involves situations where the context is being switched amongst multiple threads from the same application.

OpenGL 4.5 is being released today as a final specification, and based on prior experience we expect to start seeing desktop GPU implementations of it later this year.

WebGL Support Nears Ubiquity

Meanwhile on the WebGL front, Khronos is happy to report that WebGL support is nearing ubiquity. The web-friendly/web-safe version of OpenGL has been complete for a while now, but it has taken some time for browser developers to implement support for it in to all of the major browsers. This past year has seen WebGL support on the desktop finally become ubiquitous with the launch of Internet Explorer 11, and now the mobile world is nearing the same with the impending releases of Apple’s iOS 8 and Microsoft’s Windows Phone 8.1.

Commonly a laggard when it comes to OpenGL support, Apple has supported WebGL for the past couple of versions of desktop Safari, however they are among the last of major browser developers to not support WebGL on their mobile browser. This is finally changing on Safari for iOS 8, which will see WebGL support enabled on what’s historically a very conservative platform for Apple.

Meanwhile Microsoft’s cascading browser development plan for Windows Phone means that Internet Explorer 11 is only now being ported over to Windows Phone through the release of Windows Phone 8.1. With the upgrade to IE 11’s core, Windows Phone 8.1 will similarly be gaining WebGL compatibility this year as it is released. Altogether, ignoring the increasingly dated Android stock web browser (which itself is rarely used these days in favor of Chrome), this means that WebGL support should be nearly pervasive on desktops and mobile devices alike going into 2015.

OpenGL ES 3.1: Validation & Android Extension Pack

Finally, for OpenGL ES 3.1 Khronos is announcing that the first GPUs and drivers have finished their conformance testing and are being validated. Khronos keeps a running list over on their website, where we can see that ARM Mali Midgard, Imagination PowerVR Rogue, NVIDIA Tegra K1, and Intel HD Graphics for Atom products have all been validated. At this point there are a handful of products from the various families that haven’t finished validation, but ultimately all the major mobile GPU architectures expected to support OpenGL ES 3.1 are present in one form or another. The only vendor not present at this time is Qualcomm – the Adreno 300 series will not support OpenGL ES 3.1, and the Adreno 400 series is not yet through testing.

With the speed of validation and the limited amount of changes between OpenGL ES 3.0 and 3.1, Khronos tells us that they expect OpenGL ES 3.1 adoption will be very quick compared to the longer adoption periods required for major chnages like OpenGL ES 2.0 and ES 3.0. With that said however, in the high-end mobile device market Qualcomm has been by far the biggest winner of the ES 3.x generation thus far, so as a percentage of devices shipped we expect that there will still be a number of ES 3.0 devices in use that cannot be upgraded to ES 3.1. Ultimately as OpenGL ES 3.1 is designed to be fully backwards compatible with Open GL ES 3.0, developers will be able to tap into ES 3.1 features while still supporting these ES 3.0 devices.

Of course even ES 3.1 only goes so far, which is why Khronos is also telling developers that they’re rather pleased with the development of the Android Extension Pack, even if it’s not a Khronos standard. The AEP is implemented as a set of OpenGL ES 3.1 extensions, so it will be further building off of what OpenGL ES 3.1 will be accomplishing. Through the AEP Google will be enabling tessellation, geometry shaders, compute shaders, and ASTC texture compression on the forthcoming Android L, all major features that most of the latest generation mobile GPUs can support but are not yet part of the OpenGL ES standard. With these latest mobile GPUs approaching feature parity with their desktop counterparts, the AEP in turn brings the OpenGL ES API closer to parity with the OpenGL API, and indeed this may be a good hint of what features to expect in a future version of OpenGL ES.