OpenCL, once lauded as the future of GPGPU computing, has more recently faded out of the spotlight. Most of the PC companies that supported it have found reasons to pursue other goals: Apple has its own Metal API, Nvidia has the phenomenally successful and self-created CUDA, and AMD has been focused on Linux and its RoCm solution. Intel seems to be the only company working on its OpenCL drivers and support on a consistent basis.
Even so, the OpenCL 2.2 standard, which was published in 2017, isn’t yet supported by any vendor in the entire computing industry. It’s not a good sign when you can’t find a single company to support your standard three years after you publish it, and the Khronos Group is taking a radical approach to OpenCL 3.0 development. Specifically, they’re junking OpenCL 2.0 and going back to a fork of OCL 1.2 development.
To be clear, OCL 2.x code and capability won’t be stripped out of the standard, it’ll simply become an optional way to support OCL hardware. All features introduced up to OpenCL 2.2 will remain available for any vendor that wants to write a driver to support them. The reason the new standard is based on OpenCL 1.2 is that this is the last version that everyone agrees contains absolutely necessary functions required to support the full sweep of use-cases for the standard. The agreement is important in this case because Khronos is a consortium comprised of various member organizations, but it doesn’t wield any power of its own.
Other than the core OCL 1.2 capabilities, everything introduced to the standard in OCL 2.x and 3.0 will be optional. Each vendor will be able to support specific capabilities that make sense for their hardware, but there are no “one size fits all” restrictions of the sort that led vendors to walk away from the standard in the first place. This new approach is modeled on the way Khronos rolled out Vulkan, and OCL 3.0 will be easy for developers to support. All OpenCL 1.2 apps will run perfectly on an OpenCL 3.0 device and OpenCL 2.x applications will run perfectly on OCL 3.0 devices so long as those devices support the features the app is using. If you have an OCL 1.2 or 2.x app, you don’t have to worry about OCL 3.0 impacting your backward compatibility.
Those of you who were hoping to see OpenCL C++ catch on, though… we have bad news. The language is being junked entirely. It will be replaced by “C++ for OpenCL,” which is similar to OpenCL C++, but distinct from it and run under the auspices of a different project.
The big new feature of the standard is Asynchronous DMA support, which allows DMA transactions to run at the same time as compute kernels or synchronously with other DMA transactions.
Anandtech has more details on the low-level features and capabilities being added to the standard if you want to read up on the topic. It’s not clear that this new version of OpenCL will make any real difference for the PC industry, especially for Windows users. Despite the fact that applications like Folding@Home and Blender use OpenCL for various purposes (Blender uses it for Cycles rendering on AMD GPUs, for example), none of the major vendors seem to be making the language front and center to their future plans, though this could change once Intel launches the datacenter version of Xe.
Now Read:
- Apple Defends Killing OpenGL, OpenCL as Developers Threaten Revolt
- Nvidia Supercharges ARM HPC Deployments
- AMD Announces CDNA, RDNA2 Architectures, Significant Leap in Performance-per-Watt
No comments:
Post a Comment