Khronos Announces OpenGL ES 3.0, OpenGL 4.3, ASTC Texture Compression, & CLU
by Ryan Smith on August 6, 2012 9:00 AM ESTOpenCL Gets A CLU
Finally, on top of their OpenGL announcements Khronos is also making several smaller announcements related to some of their other initiatives. As most of these announcements fall outside of our traditional coverage areas we won’t go into great detail here, but there’s one item that falls under the domain of OpenCL: CLU.
For their SIGGRAPH OpenCL side project Khronos is announcing CLU, the Computing Language Utility (ed: Flynn Lives). Since the release of the first OpenCL specification in 2008, Khronos has been looking to expand upon OpenCL both with regards to features (resulting in additional iterations of the standard) and in improving the development tools for OpenCL. CLU falls under this latter effort.
In a nutshell, CLU is essentially a combination of a lightweight API and a template library intended to greatly simplify OpenCL development prototyping. As OpenCL was designed to be a relatively low level language (based on ANSI C), it takes quite a bit of effort to write a program from scratch due to all the facets of OpenCL that must be dealt with. CLU in turn provides a lightweight API that sits on top of a number of templates, the whole of which is designed to abstract away some of that complexity, allowing developers to get started more easily.
Ultimately developers of complex and high-performnace programs will still want to dive into the deepest layers of OpenCL. But for teaching and early prototyping Khronos believes this will significantly improve the OpenCL experience beyond the current paradigm of getting thrown into the deep end of the pool. For teaching beginners in particular, Khronos is hoping to get the process of writing their first OpenCL program down to under an hour as opposed to the much longer period of time it currently takes most beginners.
Finally, like many of their efforts, Khronos is looking to leverage the wider open source community to further improve CLU. Like the OpenGL Utility Toolkit (GLUT), the usefulness of CLU is based on how much functionality is implemented into the utility, and unlike GLUT it’s open source (under an Intel license), making it easy to fork and extend the utility.
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