Open-Source OpenCL Adoption Is Sadly An Issue In 2017

While most of the talks that take place at the annual X.Org Developers' Conference are around the exciting progress being made across the Linux graphics landscape, at XDC2017 taking place this week at Google, the open-source GPGPU / compute talk is rather the let down due to the less than desirable state of the open-source OpenCL ecosystem.

Tom Stellard who formerly worked for AMD on their LLVM compiler stack and compute initiatives who recently joined Red Hat provided a "Current state of Open Source GPGPU" talk. It's not too much of a surprise if you are up-to-date in your daily Phoronix reading and our close coverage of all things Linux GPU. But if you're not a devoted reader or looking for an hour synopsis, check out his presentation embedded in this article.

The quick story is the open-source GPGPU state isn't nearly as nice as the OpenGL 4.5+ state by the Linux drivers or even how well the open-source Vulkan drivers are doing... On the Intel side there is the Beignet project that is one of the good successes but even that's been slowing down this summer. The other corporate-backed open-source initiative is all the work AMD is doing on their ROCm stack but even that isn't in a desirable state with the kernel and LLVM/Clang components not yet being merged back upstream, making it complicated to deploy for the time being due to the limited distribution support. ROCm should be nice for OpenCL on Radeon GPUs moving forward months down the road when it's all upstreamed and widely available, but keep in mind ROCm only supports the newer GCN GPUs.

Outside of the corporate-backed initiatives, the Clover Gallium3D state tracker remains available that AMD previously worked on pre-ROCm. But Clover only supports OpenCL ~1.1, doesn't run too many OpenCL applications, and isn't being worked on in a frequent fashion by community contributors. There's also the POCL Portable Computing Language project that has experienced a fair amount of accomplishments for running OpenCL on the CPU, but its adoption hasn't been too wild and isn't yet onto supporting the newer OpenCL 2 features.

Aside from open-source or not, there hasn't been a real push by vendors in supporting OpenCL 2.1+ and reaching conformance. Most drivers are just targeting OpenCL 1.2 officially and this year the only new OpenCL 2.0 conformant implementation was from ARM.

On the tooling side, GCC and Clang offer offloading support with OpenACC and OpenMP to GPUs with a focus mostly on NVIDIA PTX support, which in turn is just consumed by the proprietary NVIDIA driver. There's also been some Clang CUDA work too that's ongoing, but again for just the proprietary NVIDIA driver.

It's also part of a chicken and egg problem with OpenCL not being widely used by open-source desktop applications. LibreOffice, GIMP / GEGL, Blender, and Darktable are among the few standout programs making use of OpenCL, but not many daily Linux desktop apps.

Part of the problem is NVIDIA's CUDA just totally dominates the GPU compute industry right now, particularly for HPC computing. Going forward, things may get brighter for open-source GPGPU... Khronos has been working on "next gen OpenCL" and a possible merging of the OpenCL and Vulkan compute interfaces, in particular relying more upon SPIR-V. That has the possibility of being a very good thing given the state of the Intel/Radeon open-source Vulkan drivers and on the proprietary driver side seeing great Vulkan/SPIR-V support across the board from all mobile and desktop GPU vendors. There's also the several projects already mating Vulkan/SPIR-V with LLVM Clang / LLVM IR for expanding the realm of language possibilities and tooling. If the compute shift mostly turns to compute drivers consuming SPIR-V, we could see much more widespread support than the current fragmented state of the OpenCL support ecosystem.

Anyhow, hopefully interesting times ahead for open-source GPU computing. Tom's recap of the state can be found embedded below.