OpenCL 2.0: What's New

Wrapping things up, Khronos’ other OpenCL announcement for this morning is the announcement of the release of the provisional specification for OpenCL 2.0. Like OpenCL SPIR 1.2 this is a work in progress specification, with Khronos continuing to take comments and leaving the door open for further adjustments, with a goal of finalizing the standard within 6 months.

As an established and maturing standard, the key enhancements and additions slated for OpenCL 2.0 are being designed in part around the technologies and hardware Khronos and its members believe will be the most important over the next few years. Which is to say that a lot of the major functionality going into OpenCL 2.0 is focused around HSA and HSA-like devices where GPU and CPU are capable of sharing memory, pointers, cache, and more. OpenCL 1.x is already capable of running on these devices, but it lacks effective means to take advantage of the interconnected hardware, which is where OpenCL 2.0’s additions come in.

The biggest addition here is that OpenCL 2.0 introduces support for shared virtual memory, the basis of exploiting GPU/CPU integrated processors. Kernels will be able to share complex data, including memory pointers, executing and using data without the need to explicitly transfer it from host to device and vice versa. Making effective use of this ability still falls to developers, who will need to figure out what work to send to the GPU and what work to send to the CPU, but as with other, similar proposals, the performance benefits can be immense in the right situations by allowing GPUs to work on parallel code without the need to constantly make expensive swaps with the CPU to move data or get the results of serial code.

Along these lines the addition of atomics from the C11 language standard should also prove beneficial to programmers looking to exploit GPU/CPU synergy, allowing work-items to be visible across work-groups and across devices. Generic address space support is also coming in OpenCL 2.0, alleviating the need in OpenCL 1.x to write a version of a function for each named address space. Instead a single generic function can handle working with all of the named address spaces, simplifying development and cutting down on the amount of code that needs to be cached for execution.

Of course while most of OpenCL 2.0’s feature additions are geared towards integrated CPU/GPU devices, there are some notable features that will be applicable to all devices. Key among these will be dynamic parallelism, which was first introduced with NVIDIA’s Tesla K20 based cards and is currently only available under CUDA. We won’t go too deep on this since we’ve covered it before, but in a nutshell dynamic parallelism allows for kernels to launch other kernels, saving both time and resources by skipping costly host interactions and thereby leaving the host CPU to work on other tasks. Dynamic parallelism is one of K20’s more potent features, so OpenCL developers should be pleased that they’re finally getting a crack at it.

Finally, on the gaming/graphics side OpenCL is getting some new image manipulation functionality that is slated to further enhance the existing OpenCL/OpenGL interoperability capabilities. OpenCL 2.0 will define the ability to work with sRGB color space images, alongside the ability for multiple kernels to read and write to the same OpenCL image. Furthermore OpenCL will now be able to generate images from multi-sampled and mi-mapped OpenGL textures, allowing OpenGL to pass work to OpenCL under more scenarios.

OpenCL SPIR 1.2: An Intermediate Format For OpenCL
Comments Locked


View All Comments

  • chris81 - Monday, July 22, 2013 - link

    Standing for Standard Portable Interface Representation -> Intermediate Representation
  • Ryan Smith - Monday, July 22, 2013 - link

    Aww geeze. Thanks for catching that. Fixed.
  • iwod - Tuesday, July 23, 2013 - link

    Hopefully within a year or two we should finally see some adoption into OpenCL acceleration. Which i have yet to see much software using it. ( May be CPU today is already fast enough for 95% of what we need. )

    Does OpenGL 4.4 matters? Do Microsoft Still support it on Windows ( I remember there were words on dropping support etc i didn't remember what turns out )
    And Apple, even with their unreleased OSX Maverick has ONLY just updated to OpenGL 4.0
    ( Yeah this is depressing )

    So the most important OpenGL would be OpenGL ES, where it is dominating / monopolizing the mobile world. Why isn't there any update on it?
  • Klimax - Tuesday, July 23, 2013 - link

    OpenGL is implemented by GPU vendors and connecting into graphics subsystem using provided interfaces.
  • Krysto - Tuesday, July 23, 2013 - link

    What do you mean? They've just updated it to Open GL ES 3.0 last year. They won't update ES every year.

    That being said, with Nvidia starting to use the full OpenGL in mobile next year, I think Khronos needs to release ES 4.0 next year, so the other GPU chip makers can catch-up a bit, since adopting the full OpenGL 4.3/4.4 might be too hard for them. Nvidia had to use its PC architecture to do that, and even Intel on its latest Haswell for notebooks and PC's doesn't support more than 4.0, which they barely adopted at the last moment, too.

    So either Khronos gives the others ES 4.0 to work with, or the other mobile GPU makers will be literally *years* behind future Tegra devices, when it comes to graphics capability.
  • przemo_li - Thursday, July 25, 2013 - link

    Geometry shaders, and tesselation shaders consume much power and that was reason why they did not landed in OpenGL ES 3.0. It will be interesting to see if Nvidia can come up with some good solution here.

    (Also Intel is utilizing Mesa drivers for their Android efforts, those are already at full OGL 3.1, and 3.2/3.3 should come this year.)
  • Codeledger - Tuesday, July 23, 2013 - link

    As someone who is following Google's GPGPU efforts with Renderscript, it looks like OpenCL 2.0 and OpenCL SIPR are trying to address some of the issues brought up by the Android team. I would be curious to know if the various vendors are using Renderscript as a test bed DSL or in the future will Android adopt and expose OpenCL formally.
  • Wwhat - Sunday, July 28, 2013 - link

    New in OpenCl: DRM type crap

    No need to worry though, we keep the word 'open' in the name...for 'your' convenience.

Log in

Don't have an account? Sign up now