Alongside today’s announcements of Vulkan and SPIR-V, Khronos is also using the occasion of the 2015 Game Developers Conference to announce the next iteration of OpenCL, OpenCL 2.1.

OpenCL 2.1 marks two important milestones for OpenCl. First and foremost, OpenCL 2.1 marks the point where OpenCL (compute) and graphics (Vulkan) come together under a single roof in the form of SPIR-V. With SPIR-V now in place, developers can write graphics or compute code using SPIR, forming a common language frontend that will allow Vulkan and OpenCL to accept many of the same high level languages.

But more significant about OpenCL 2.1 is that after several years of proposals and development, OpenCL is now gaining support for an official C++ dialect, extending the usability of OpenCL into even higher-level languages. Having originally launched using the OpenCL C dialect in 2008, there was almost immediate demand for the ability to write OpenCL code in C++, something that has taken the hardware and software some time to catch up to. And though C++ is not new to GPU computing – NVIDIA’s proprietary CUDA has supported it for some time – this marks the introduction of C++ to the cross-platform OpenCL API.

OpenCL 2.1’s C++ support comes in the form of a subset of C++, stripping out a few parallel-compute unfriendly features such as catch/throw, function pointers, and virtual functions. What remains then is virtually everything else, including classes, templates, and C++’s powerful lambda functionality. This opens up OpenCL programming to the same general benefits that C++ enables over C, giving developers access to a higher level language that is more capable, and generally speaking better known as well.

The addition of C++ to OpenCL is driven by the use of SPIR-V, with Khronos creating an OpenCL C++ to SPIR-V compiler to compile C++ down to the intermedia representation, and then the OpenCL runtime executing the SPIR-V code from there. And meanwhile though OpenCL C isn’t going anywhere for both compatibility and tuning reasons, this is the overall direction that Khronos wants to go with OpenCL, pushing everything through SPIR so that the languages supported is largely a function of what compilers are available, and not what the OpenCL runtime can do.


Meanwhile, in the long run C++ support should help Khronos and its partners to better push and deploy OpenCL, with C++ support making the API more useful and accessible than before. Differences such as these have been a big part of the reason that NVIDIA’s CUDA has remained so popular despite being limited to NVIDIA platforms, and though OpenCL C++ arguably won’t erase the gap between the two APIs, it should cut down on the gap significantly. That said, part of this may come down to whether NVIDIA implements OpenCL 2.1 support; with their current dominance with CUDA, NVIDIA has yet to even implement OpenCL 2.0 support, which greatly limits how many discrete GPUs can run the newest versions of OpenCL.

Finally, along with the addition of OpenCL C++, OpenCL 2.1 also adds a few extra features to the overall API to improve the API’s flexibility. Low latency device timers should allow for much more reliable/accurate profiling of code execution than relying on potentially divergent clocks, and kernel cloning functionality has been introduced via the clCloneKernel command.

Wrapping things up, as is common for Khronos, OpenCL 2.1 is initially being released as a provisional specification. While Khronos isn’t commenting on a finalization date just yet, given how early it is in the year, we would be surprised not to see a final version of the API before the year was out.



View All Comments

  • oddity1234 - Tuesday, March 03, 2015 - link

    "NVIDIA has yet to even implement OpenCL 2.0 support"

    NVidia has yet to even implement OpenCL 1.2 support, actually.
  • xdrol - Tuesday, March 03, 2015 - link

    They do have an OpenCL 1.2 implementation for Tegra TK1. (Available on vendor request..) Reply
  • ddriver - Tuesday, March 03, 2015 - link

    Hurray, it is available on a power limited platform if the vendor has explicitly requested it. That's what I call "availability". Reply
  • Deanjo - Saturday, April 04, 2015 - link

    It actually has been available in OS X for quite a while on nvidia cards. Reply
  • lkuhlmann - Tuesday, April 14, 2015 - link

    Can you provide a useful email address for this request? Reply
  • Jaybus - Tuesday, March 03, 2015 - link

    Well, they'd better get with it, because with equal (more or less) usability, the cross-platform library is more appealing for new projects. It allows developers to target a broader range of hardware. There just isn't enough difference in the GPU hardware to justify a proprietary Cuda. Reply
  • deviceprogrammer - Monday, March 09, 2015 - link

    Well, competition for NVIDIA is growing and it will be hard to be a la Microsoft of the 1990s. NVIDIA must convert their GPU into some different kind of animal if they want to dominate with CUDA. Things like virtual memory, preemptive multitasking and so on. Reply
  • sorten - Tuesday, March 03, 2015 - link

    "C++ featured removed ..."
    Wow, they didn't even edit their slide deck?
  • maximumGPU - Tuesday, March 03, 2015 - link

    would be interesting to see who has the more complete C++ features for compute, OpenCL or C++AMP. Reply
  • patrickjp93 - Wednesday, March 04, 2015 - link

    Don't leave out OpenMP. People forget you can use it to offload natively written C++ code to an iGPU or to a Xeon Phi. Reply

Log in

Don't have an account? Sign up now