Khronos Announces OpenGL ES 3.0, OpenGL 4.3, ASTC Texture Compression, & CLU
by Ryan Smith on August 6, 2012 9:00 AM ESTAs we approach August the technical conference season for graphics is finally reaching its apex. NVIDIA and AMD held their events in May and June respectively, and this week the two of them along with the other major players in the GPU space are coming together for the graphics industry’s marquee event: SIGGRAPH 2012.
Outside of individual vendor events, SIGGRAPH is typically the major venue for new technology and standards announcements. And though it isn’t really a gaming conference – the show is about professional usage in both senses of the word – a number of those announcements do end up being gaming related. Overall we’ll see a number of announcements this week, and kicking things off will be the Khronos Group.
The Khronos Group is the industry consortium responsible for OpenGL, OpenCL, WebGL, and other open graphics/multimedia standards and APIs. Khronos membership in turn is a who’s who of technology, and includes virtually every major GPU vendor, both desktop and mobile. Like other industry consortiums the group’s president is elected from a member company, with NVIDIA’s Neil Trevett currently holding the Khronos presidency.
OpenGL ES 3.0 Specification Released
Khronos’s first SIGGRAPH 2012 announcement – and certainly the biggest – is that OpenGL ES 3.0 has finally been ratified and the specification released. As the primary graphics API for most mobile/embedded devices, including both iOS and Android, Khronos’s work on OpenGL ES is in turn the primary conduit for mobile graphics technology development. Khronos and its members have been working on OpenGL ES 3.0 (codename: Halti) for some time now, and while the nitty-gritty details of the specification have been finally been hammered out, the first OpenGL 3.0 ES hardware has long since taped-out and is near release.
OpenGL ES 3.0 follows on the heels of OpenGL ES 2.0, Khronos’s last OpenGL ES API released over 5 years ago. Like past iterations of OpenGL ES, 3.0 is intended to continue the convergence of mobile and desktop graphics technologies and APIs where it makes sense to do so. As such, where OpenGL ES 2.0 was an effort to bring a suitable subset of OpenGL 2.x functionality to mobile devices, OpenGL ES 3.0 will inject a selection of OpenGL 3.x and 4.x functionality into the OpenGL ES API.
Unlike the transition from OpenGL ES 1.x to 2.0 (which saw hardware move from fixed function to programmable hardware), OpenGL ES 3.0 is going to be fully backwards compatible with OpenGL ES 2.0, which will make this a much more straightforward iteration for developers, and with any luck we will see a much faster turnaround time on new software taking advantage of the additional functionality. Alongside an easier iteration of the API for developers, hardware manufacturers are far more in sync with Khronos this time around. So unlike OpenGL ES 2.0, which saw the first mass-market hardware nearly 2 years later, OpenGL ES 3.0 hardware will be ready by 2013. Desktop support for OpenGL ES 3.0 is also much farther along, and while we’ll get to the desktop side of things in-depth when we talk about OpenGL 4.3, it’s worth noting at this point that OpenGL 4.3 will offer full OpenGL ES 3.0 compatibility, allowing developers to start targeting both platforms at the same time.
On that note, OpenGL ES 3.0 will mark an interesting point for the graphics industry. Thanks to its use both in gaming and in professional applications, desktop OpenGL has to serve both groups, a position that sometimes leaves it caught in the middle and generating some controversy in the process. The lack of complete modernization for OpenGL 3.0 ruffled some game developers’ feathers, and while the situation has improved immensely since then, the issue never completely goes away.
OpenGL ES on the other hand is primarily geared towards consumer devices and has little legacy functionality to speak of, which makes it easier to implement but also allows OpenGL ES to be relatively more cutting edge. All things considered, for game developers OpenGL ES 3.0 is going to very nearly be the OpenGL 3.0 they didn’t get in 2008, although geometry shaders will be notably absent. Consequently, while OpenGL 4.x (or even 3.3) is still more advanced than OpenGL ES 3.0, it’s not out of the question that we’ll see a bigger share of OpenGL desktop game development use OpenGL ES as opposed to desktop OpenGL.
Facebook
Twitter
RSS
46 Comments
View All Comments
djgandy - Tuesday, August 7, 2012 - link
I agree, I did say 'like apple' though, but yes, no one is really interested in desktop GL anymore.At least apple went 3.2 core though and explicitly state in their documentation that deprecated features are removed
https://developer.apple.com/library/mac/#documenta...
Tessellation (Burning energy) aside I don't think there are many headline features that desperately need adding from 4.0 onwards. Apple did only support 2.1 until they released 3.2 support!
Jumangi - Monday, August 6, 2012 - link
Yea DX isn't the stagnated one. OpenGL is a spec has been behind DirectX for years now. The stagnation is from allot of developers who don't use the latest stuff since they stay with the lowest denominator we still have with the PS3 and 360. The features are there if developers want to use them.sheh - Monday, August 6, 2012 - link
And WinXP.ltcommanderdata - Monday, August 6, 2012 - link
It's mentioned in the article that nVidia desktop GPUs don't support ETC in hardware. Do we know whether ETC support in hardware is universal across OpenGL ES 2.0 GPUs from various vendors like PowerVR, ARM, Qualcomm, and nVidia? In the transition, games will no doubt include both OpenGL ES 2.0 and 3.0 render paths to support more devices, and it'd be preferable if both paths could share texture assets.Since ASTC is optional right now which GPU makers have announced they support it in hardware?
It'll be interesting to see what Apple does with ETC on iOS. The existing PVRTC is more efficient on PowerVR GPUs than ETC. I can't see Apple happy to support a less efficient texture format whose benefit to developers but not Apple is to ease portability of games to Android. I suppose Apple will enable ETC support for compatibility, but won't be investing effort in optimizing it's performance. IMG just released a new PVRTC2 texture format for Series5XT and Series6 GPU that improves upon PVRTC, so I expect Apple will be pushing that format soon on iOS.
Ryan Smith - Monday, August 6, 2012 - link
Most current OpenGL ES 2.0 GPUs do not support ETC. I do not have a good list, but I know that PowerVR, Tegra, and Adreno do not support it. So until OpenGL ES 3.0 is the baseline, developers will still have to deal with disjoint texture compression formats. But at least there's finally a way out.As for ASTC, none of the GPU vendors have announced that they'll be supporting it in hardware. This is part of the reason why ASTC is currently being floated as an extension, in order to gather feedback. Now that the standard is out, GPU vendors can look at integrating hardware support. Since this is a joint ARM/NV proposal, I'd expect both of them to integrate support a the earliest opportunity.
pebrb - Monday, August 6, 2012 - link
You are confusing ETC and ETC2 in the entire article.All current OpenGL ES 2.0 GPUs _do_ support ETC (not ETC2) as it is the standard in ES 2.0
The only vendor that doesn't support it is Apple (even though the PowerVS SGX has support for it)
The reason for developers support different texture formats is because ETC is very low quality and lack of alpha channel support.
In OpenGL ES 3.0 they made ETC2 the standard, we'll see how it'll work out.
But I'm waiting for ASTC it has very good features. And from what I heard it will be supported by Microsoft as well, which means that everyone needs to implement it anyway.
name99 - Monday, August 6, 2012 - link
"I can't see Apple happy to support a less efficient texture format whose benefit to developers but not Apple is to ease portability of games to Android."Is any of this conspiracy theory in the slightest grounded in reality?
Apple has generally been happy to support standards, even when that's not directly relevant to its goals. The web world (HTML5 and h264) are obvious examples, but an example more relevant to what we're discussing here is Apple's aggressive support for C++11 (both language and library) in the latest version of XCode. And this is not just passive checkbox support, it is genuine hard work to make C++11 interoperate well with Objective C, and to perform well.
ltcommanderdata - Monday, August 6, 2012 - link
My doubt isn't about Apple supporting standards in general, it's about them supporting a weaker technology as a standard. Apple promotes H.264 over WebM, because it has superior image quality (yes there is some debate) and superior hardware support. With the existing PVRTC texture format on iOS offering better performance and image quality than ETC on the GPUs Apple uses I can't see them singing ETC's praises as a standard. They'll no doubt add iOS support for ETC as it's required for OpenGL ES 3.0, but I don't doubt they'll be strongly encouraging iOS developers to keep using PVRTC and soon PVRTC2.Alexvrb - Monday, August 6, 2012 - link
PVRTC2 will likely wipe the floor with ETC2. Heck it'll probably be better than ASTC too.iwodo - Tuesday, August 7, 2012 - link
Would love to see PVRTC2 Vs ASTC