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
whooleo - Monday, August 6, 2012 - link
Concerning the desktop, OpenGL is hardly being used in games due to DirectX being better and because many of the Linux and Mac OS X users aren't gamers. I mean there are games on Mac OS X but not many gamers on Macs. Plus it shows, Apple's graphics drivers aren't where they should be compared to Linux and Windows along with the graphics cards they include with their PCs. Enough about Mac OS X, Linux also has too many issues with graphics cards and drivers to be friendly enough to the average gamer. This is just a summary of the reasons why desktop OpenGL adoption is low. Now don't get me wrong, OpenGL can be a great open source alternative to DirectX but some things need to be addressed first.bobvodka - Tuesday, August 7, 2012 - link
Just a minor correction; OpenGL isn't 'open source' it is an 'open standard' - you get no source code for it :)whooleo - Tuesday, August 7, 2012 - link
Whoops! Thanks for the correction!beginner99 - Tuesday, August 7, 2012 - link
maybe I got it all wrong but aren't the normal gaming gpus rather lacking in OpenGL performance? I always thought that that was one of the factors the workstations cards differ in (due to driver). Wouldn't that impact game performance as well?Cogman - Tuesday, August 7, 2012 - link
> As OpenCL was designed to be a relatively low level language (ANSI C)OpenCL was BASED on C99. It is not, however, C99. They are two different languages (in other words, you can't take OpenCL code and throw it into a C compiler and vice versa).
Sorry for the nit pick, however, it is important to note that OpenCL is its own language (Just like Cuda is its own language).
UrQuan3 - Thursday, August 16, 2012 - link
Maybe someone can set me straight on this. Years ago, I had a PowerVR card for my desktop (Kyro II). While this was not a high end card by any means, I seem to remember a checkmark box "Force S3TC Compression". The card would then load the uncompressed textures from the game and compress them using S3TC before putting them in video RAM. The FPS performance increase was very noticeable although load times went up a little.Am I confused about that? If I'm not, why isn't that more common? Seems like that would solve the problem of supporting multiple compression schemes. Of course, if a compression scheme isn't general purpose, that could cause problems.