OpenCL 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.

Adaptive Scalable Texture Compression
POST A COMMENT

46 Comments

View All Comments

  • Wreckage - Monday, August 06, 2012 - link

    Hopefully OpenGL can return to prominence again. There needs to be competition against the closed proprietary DirectX, which has stagnated lately.

    Valve's move to Linux and the rise of Android as a gaming platform should provide additional support for more games to use alternatives to DirectX.
    Reply
  • Flunk - Monday, August 06, 2012 - link

    You forgot Macs, those things are pretty hot right now too. Blizzard has made a load of cash off the Mac versions of their popular games. Reply
  • KoolAidMan1 - Tuesday, August 07, 2012 - link

    And iOS, arguably the fastest growing segment in the gaming market right now.

    There is TONS using OpenGL right now, hopefully it keeps improving thanks to its resurgence.
    Reply
  • bobvodka - Tuesday, August 07, 2012 - link

    OpenGL|ES is not OpenGL, they are two seperate specs - iOS and Android can grow all they like, they still aren't using OpenGL. Reply
  • djgandy - Monday, August 06, 2012 - link

    Please explain how DX has stagnated? Reply
  • nevertell - Monday, August 06, 2012 - link

    Well, tessellation was supported by OpenGL years before DX11 was released. Reply
  • B3an - Monday, August 06, 2012 - link

    Even John Carmack admitted recently at the Quakecon 2012 event that DirectX is now overall better than OpenGL, and Carmack has always used OpenGL. So i dont think Microsoft have anything to worry about.

    With DX11.1 Microsoft have also rewritten and optimised much of it for better performance, efficiency and mobile GPU support. So MS now basically have a single fully featured API for both desktop and mobile GPU's that can do everything. DX11.1 also introduced Target Independent Rasterization which i don't think OpenGL has.
    Reply
  • PrinceGaz - Monday, August 06, 2012 - link

    The problem with DirectX is it is not royalty-free and supported across all platforms. The days of game development being led by Windows PCs is over; it is now all about convergence and supporting as many target markets as possible from mobile-phones (Android, iOS mainly at the moment) as well as game consoles, plus PCs and Macs as well with one common language.

    It will mean compromises at the high-end, but graphics are so good these days it hardly matters. We want better games, not better graphics, so the less developers need to worry about the graphics and the more time they can spend on making a good game which will run on a wide range of devices, the better in my opinion.
    Reply
  • inighthawki - Monday, August 06, 2012 - link

    Since when has DirectX not been royalty free? Reply
  • Ryan Smith - Monday, August 06, 2012 - link

    I'd have to double-check, but since at least DX6, when Microsoft included S3TC as part of the standard. You can't be DX compliant without S3TC, and you have to pay to license S3TC. Reply

Log in

Don't have an account? Sign up now