Since the announcement of the OpenCL 2.0 standard, a lot of people have been buzzing around excitedly talking about how significant this update is. So much so that some developers are saying that they are only looking at OpenCL for the first time because of the 2.0 update, which is definitely saying something for the significance of this update.
Since then, the Khronos Group members have been working feverishly to define and ratify the standard and that culminates in today’s announcement of the finalization of the OpenCL 2.0 standard. Khronos has provided us with a short list of added features and updates to OpenCL. Some of these were already known and others are new additions.
One of the well known features is the shared virtual memory, which will enable host and devices kernels to share various memory functions which help reduce the need for moving data between the CPU and GPU unnecessarily. Another well known feature is the nested parallelism feature which allows for the GPU to schedule its own tasks and reduce unnecessary calls to the CPU.
There is also the Generic Address Space capability, which allows for functions to be written without having to specify a named address space. There is also improved image support, which is also an already well known feature of OpenCL and OpenGL and is clearly designed to improve interoperability between the two sets of APIs. By supporting sRGB and 3D image writes, OpenCL adds the ability for kernels to read from and write to the same image, making for a smaller footprint and better performance. The addition of pipes will also help store data organized in the FIFO method and with OpenCL 2.0 will provide functions that allow for optimizations for pipes using OpenCL 2.0′s built-in functions for kernels to read and write directly to the pipes.
Last but not least, there will be an Android installable client driver extension that will enable OpenCL implementations (non-native to Android) to be discovered and loaded as a shared object on Android systems. This should make the implementation of 2nd and 3rd party OpenCL drivers to be loaded more easily than they are now and should also go around Google’s own ambivalence towards OpenCL in favor of Renderscript Compute. Everyone except for Google appears to want a native Android implementation of OpenCL, so until Google finally buckles hardware and software companies are going to be forced to install their own client drivers.
In the end, a lot of these features will enable more heterogeneous compute features on OpenCL, which should make the HSA Foundation’s goals more attainable. Many of the Khronos members are also members of the HSA Foundation, so it seems quite reasonable that they would make the Khronos standards the defacto APIs to utilize for cross-platform open heterogeneous compute.