OpenGL @ SIGGRAPH 2015: OpenGL ES 3.2 & OpenGL Extensions Announced
by Ryan Smith on August 10, 2015 2:50 PM ESTKicking off this week in Los Angeles is SIGGRAPH 2015, the computer graphics industry’s annual professional conference. 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 on both OpenGL and OpenGL ES, along with the formation of the OpenGL SC 2.0 working group.
OpenGL ES 3.2
Starting things off, we have the announcement of OpenGL ES 3.2. The latest version of OpenGL’s embedded variant is receiving a new revision this week, bringing the API up to version 3.2.
With OpenGL ES 3.2, Khronos will officially be rolling the feature set of the Android Extension Pack into the core API. Until now these features have been available as optional extensions – which Google conveniently rolled into the AEP for Android developers – as not all original GPUs capable of supporting OpenGL ES 3.1 could also support the AEP, preventing those features from being rolled into OpenGL ES core.
Via these features, OpenGL ES 3.2 will bring support for tessellation, geometry shaders, compute shaders, and ASTC texture compression in to the core OpenGL ES standard. These are major features already found in desktop GPUs for some number of years now, and these days are found in all of the major mobile GPUs as well. Of particular interest here, this means that ASTC is finally part of the OpenGL ES core standard, and while it will take some time to filter out to new OSes and devices, this finally solves the problem with the lack of a standard texture compression format in the mobile space.
Meanwhile, as Khronos likes to note in their announcement, the inclusion of these features brings mobile GPUs much closer to parity with their desktop counterparts. At this point there are very few major OpenGL 4.x class (DirectX 11) features not accounted for in mobile GPUs in some form, so the gap between mobile and desktop has been further closed. And of course this means developers can push the envelope even harder on certain classes of graphical effects – especially geometry and compute-based physics simulations – though on a smaller scale more fitting of mobile hardware.
As far as OS support goes, Khronos and Google are also announcing today that OpenGL ES 3.2 will be adopted by a future version of Android – presumably 2016’s Android release – at which point OpenGL ES 3.2 will have effectively supplanted the AEP. Meanwhile we haven’t heard anything from the Apple camp about OpenGL ES in some time. iOS never received OpenGL ES 3.1 support, and with Apple gung-ho on Metal there’s no immediate reason to believe this will change with OpenGL ES 3.2.
OpenGL SC 2.0
Along with the release of OpenGL ES 3.2, Khronos is also announcing that they are forming a working group for OpenGL SC 2.0, which will be based on OpenGL ES 3.
OpenGL SC is a little-known subset of OpenGL ES that is focused on what Khronos and its members call “safety critical” systems, such as automotive and avionics systems. OpenGL SC in turn is essentially a trimmed down version of OpenGL ES that removes some of OpenGL’s flexibility in order to allow easier driver validation and ultimately more reliable operation than what is accepted for OpenGL ES.
OpenGL SC was originally created in 2005 and based off of Open GL ES 1.0, the last fixed function version of OpenGL ES. With even time-tested hardware now well outstripping the capabilities of OpenGL SC 1.0, Khronos is forming a new working group to develop OpenGL SC 2.0. 2.0 in turn will be taking OpenGL GL ES 3.x and stripping it down in a similar manner as the original specification in order to produce a pared down version of the API that is more up to date. Khronos is looking to release OpenGL ES 2.0 in 2016.
Desktop OpenGL: No New Version, But New Extensions
Finally, on the desktop OpenGL front, Khronos will not be announcing a new version of OpenGL this year, making this the first SIGGRAPH in several years where Khronos doesn’t update their venerable graphics API. Citing that OpenGL has largely caught up with desktop hardware as of OpenGL 4.5 – and with attention no doubt split by Vulkan – the consortium is instead going to release several new extensions to unlock new features. These extensions represent features that are expected to be useful for developers and worth having under Khronos control, but are not universally supported by all desktop hardware, making their inclusion into an OpenGL core standard a thorny issue.
Of particular interest on these extensions, one of the extensions will add support for multi-threaded shader compilation in OpenGL, with the goal of cutting down on loading times on shader-heavy workloads. Improved 64-bit integer support will also be coming to OpenGL as part of this extension set; 64-bit integers are still fairly rare in graphics workloads, but with many GPUs now supporting them, there are times where the extra precision is useful. And last but not least of course, as has been the case for the last few iterations of OpenGL, there will also be extensions to enable full OpenGL ES 3.2 interoperability, primarily to support developers in creating OpenGL ES applications.
Though it is interesting to note that some of the latest GPU features as exposed by Direct3D feature level 12_1 aren’t included in the extension sets, such as conservative rasterization. Right now a lot of resources are going into developing Vulkan, and while Khronos is committed to continuing to develop OpenGL separate from Vulkan, it may be that more extensive feature additions for OpenGL will have to wait until after Vulkan is done, and/or after all three major desktop vendors support these latest features.
Source: Khronos
5 Comments
View All Comments
stephenbrooks - Monday, August 10, 2015 - link
Now that Vulkan has taken on the role of low-level/high-performance API, perhaps it's time to make OpenGL easier to set up? With GL 3.x they greatly increased the amount of code required to render a single triangle - and not everyone actually wants that much flexibility, at least not all the time. The standard directional lighting shader is fine for a lot of scientific/engineering visualisations, for instance.Another thought is that perhaps GL could become a library written in Vulkan, rather than being a separate interface.
AndrewJacksonZA - Tuesday, August 11, 2015 - link
"Another thought is that perhaps GL could become a library written in Vulkan, rather than being a separate interface."That would be the natural way for things to flow, in my opinion. Unless there are some hardware issues to prevent it, like a significant enough portion of hardware not supporting Vulkan.
Brianmj - Tuesday, August 11, 2015 - link
"Now that Vulkan has taken on the role of low-level/high-performance API, perhaps it's time to make OpenGL easier to set up?"There are plenty of libraries that allow you to choose the level of abstraction you want. If all you want to do is render a triangle without using GL buffers and shaders, SFML or SDL are perfect. If you want to eschew the use of third party libs, there's nothing stopping you from using the compatibility profile and just doing glBegin(GL_TRIANGLES)...glEnd().
stephenbrooks - Tuesday, August 11, 2015 - link
Well, right now I essentially am using the compatibility profile since I've stuck with GL 1.x/2.x for my programs so far.What I'd *like* to see is GL becoming a standard higher-level interface (possibly stacked on top of Vulkan), which gets rid of the clunkiest stuff like glBegin/glEnd pairs, yet provides the user with sensible default settings, like default shaders and default vertex data structures, so a beginner (or anyone really) can get going quickly and customise later.
At the moment GL 3.x and above are sufficiently opaque to discourage a lot of newcomers to graphics programming, which I think is an important consideration for the whole future of the industry.
As for me, I understand what GL 3.x does and I could upgrade my code, but I haven't bothered because it's not worth the time investment. 3.x seemed like an abortive attempt to do what Vulkan has now done successfully, so I have difficulty seeing the point in its approach.
xCyborg - Wednesday, August 12, 2015 - link
I'm confused, I thought Vulcan is the next version of ES for Android. not to mention that it already support OES 3.1 hardware level. How the two are gonna coexist? is Vulcan just intended as ultra fast API for performance apps (without the new features), while ES 3.1 fill the feature gaps like ASTC and whatnot?Any who, according to Android Dashboard OpenGL ES 3.0 is still less than 40% and it was announced exactly three years ago. so by the current pace Google updates Android plus H/S fragmentation by 2018/19 we'll have less than half the devices use ES 3.2 and probably a critical mass still using ES 2.0.
I guess us developers should just continue brainstorming hacks to decouple alpha maps from the rest of RGB texture or just ditch Android altogether, horrible platform to develop on, 50% iDevices support Metal already.