Khronos Announces OpenCL 2.1: C++ Comes to OpenCL

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.