PoCL: a conformant OpenCL implementation you can build and read

What PoCL is, and what the conformance claim covers

PoCL is described as a conformant implementation, for CPU and Level Zero GPU targets, of the OpenCL 3.0 standard which can be easily adapted for new targets.

That last clause is the project's premise. PoCL is not a driver for one piece of hardware. It is a framework for writing OpenCL implementations, built on LLVM and Clang so that a new device type means writing a new backend rather than a new compiler stack. The Khronos conformance listings linked in the README record PoCL as a conformant submission for both CPU and Level Zero.

The official web page is portablecl.org and the full documentation is hosted there as well.

The project carries an OpenSSF Best Practices badge and a Coverity Scan build badge, and the repository layout shows a mature C project: CMakeLists.txt with a set of .in.cmake templates for configuration headers and the ICD file, a cmake/ directory, lib/, include/, pocld/ for the daemon, poclu/ for utility code, tools/, tests/, examples/, doc/, thirdparty/, and a CHANGES file. There is a ToolchainExample.cmake, which is the file a new backend author would start from.

The primary language is C, which is the right choice for a component that has to be a loadable library inside somebody else's process, next to a GPU driver.

The driver table tells you exactly what to expect

The most useful thing in the README is the device driver table, and the fact that it publishes CTS pass rates is what makes it credible.

The README states that PoCL supports several backend drivers with different levels of maturity in terms of received testing, reliability and available features. The table gives, per driver, the maturity, the CTS pass rate, the developed OpenCL version and the input SPIR-V version.

For CPU/x86_64 the maturity is very high, the CTS pass rate is 100%, the developed OpenCL version is 3.0 and the input SPIR-V is 1.4. CPU/RISCV is high with a 100% pass rate. CPU/ARM64 is high with more than 99%. LevelZero is high with more than 99%, a developed OpenCL version of 3.0, and input SPIR-V given as the Level Zero runtime. The CUDA, OpenASIP and Vulkan rows are all low maturity with no CTS pass rate given.

The prose adds the caveat about how to read that column. CPU/x86_64 is continuously tested to pass CTS, and is also able to pass more than 99% of all CTS tests when built with Thread or Address sanitizers. CPU is also tested on RISCV and ARM64. CPU on ARM32, i386, PPC and S390x is not tested or supported, and the project is explicit that it won't prevent building on these architectures, but doesn't actively support them currently.

There is also a note that CTS pass rate reflects the expected pass rate of OpenCL-CTS tests when PoCL is compiled with the ENABLE_CONFORMANCE=ON setting, which is how a reader should interpret the number rather than taking it as a claim about a random build.

Building against a recent LLVM, and running from the build tree

The build requirements are spelled out in full, and they are the reason PoCL is a source project rather than a package most people install.

You need the latest released version of LLVM and Clang, and the development files for LLVM and Clang plus their transitive dependencies, with examples given as libclang-dev, libclang-cpp-dev, libllvm-dev, zlib1g-dev and libtinfo-dev. You need CMake 3.15 or newer, and either GNU make or ninja. Optional pieces are pkg-config, hwloc v1.0 or newer such as libhwloc-dev, python3 which is enabled by default for support of LLVM bitcode with the SPIR target, and llvm-spirv with spirv-tools for SPIR-V support in CPU or CUDA, with the Vulkan driver supporting SPIR-V through clspv.

The hwloc requirement is the interesting one. hwloc is the library that describes the machine's topology, how many cores, which sockets, which NUMA nodes, and PoCL uses it to schedule work across the host CPU. It is optional, but a build without it will schedule badly, and the fact that it is optional rather than required is a reasonable compromise for a project that also has to build for unusual targets.

The build itself follows the usual CMake steps, and there is one important detail. PoCL can be used from the build directory, without installing it system-wide.

That is a significant practical point for anyone evaluating the project. A CMake build of LLVM and Clang is a heavy operation, and being able to run the result straight out of the build tree, or to install it into a prefix, means you can try it without touching the system OpenCL loader.

The full build instructions, including the list of available options, are in the install guide at portablecl.org/docs/html/install.html.

The ICD loader, the daemon and the library, in three directories

The repository structure shows the three moving parts of any OpenCL implementation, and it is worth understanding how they relate.

The lib/ directory holds the implementation itself. include/ holds the public headers, and the .in.cmake templates in the root generate the headers that depend on the build configuration, including pocl_opencl.h.in.cmake, pocl_version.h.in.cmake, config.h.in.cmake and config2.h.in.cmake. The pocl.icd.in and pocl.icd.in.cmake files generate the ICD vendor file, which is the small JSON or ini fragment that tells the system OpenCL loader that a new implementation is installed.

pocld/ is the daemon, and poclu/ is a set of utility helpers shared across the codebase. The cl_offline_compiler.sh.in.cmake script is a generated shell wrapper for the offline compiler, and pocl.pc.in.cmake generates the pkg-config file so that a program linking against PoCL can find it.

The ICD piece is what makes PoCL a drop-in rather than a replacement. cl_khr_icd is listed as available at platform level if compiled with ENABLE_ICD=1, alongside cl_khr_create_command_queue, cl_pocl_content_size and cl_ext_buffer_device_address. The ICD mechanism is the standard OpenCL way of having several implementations coexist, so an application links against the Khronos loader and gets whichever implementation the vendor file points to.

The other piece of infrastructure is the pocl.pc file and the pkg-config optional requirement, which is the ordinary Unix way of letting a build system find the library.

The examples/ directory is a good sign of the project's scope. It contains ports and wrappers for a wide range of real workloads, with CloverLeaf, Rodinia, ViennaCL, VexCL, PyOpenCL, Halide, OpenCV, OpenVX, IntelSVM, arrayfire, clBLAS, clFFT, CLBlast, Glow and accel among them, plus SYCL and OpenVX conformance test directories. The tests/ directory at the root holds the project's own test suite, and the CHANGES file tracks what moved between releases.

Extension support is a matrix, not a promise

The README publishes a large table of OpenCL extension support per driver, with a legend of supported with all hardware and LLVM versions, partially supported with notes, unsupported, and an empty cell for unknown status.

The table is long because OpenCL's extension surface is long, and the interesting signal is in the pattern rather than in any single row. The device address and atomics extensions are broadly supported: cl_ext_buffer_device_address is supported on CPU and Level Zero and CUDA but not on Remote, cl_khr_device_uuid is supported on CPU and Level Zero but not Remote, and the integer atomics family, cl_khr_global_int32_base_atomics and the int32 and int64 extended variants, is green on CPU, Level Zero and CUDA for the base forms.

The subgroups family is where the partial support concentrates, which is expected since subgroup support depends on how closely the device maps onto the underlying hardware's execution model. cl_khr_subgroups is partially supported on CPU, Level Zero and CUDA, and the vendor extensions, cl_intel_subgroups and its short, char and long variants, are partially supported on CPU and Level Zero.

There is also a note that matters for anyone building a multi-device setup. Remote devices pass through most of their extensions, with a few exceptions, and those are the ones marked Unsupported in the table. A remote device is therefore a different target with a different feature set, not just a slower one.

The full table runs to many more rows in the source, covering the cl_exp_tensor and cl_exp_defined_builtin_kernels experimental extensions, the cl_khr_command_buffer family, and the three-dimensional image and integer dot product extensions.

Version 7.2, a release candidate, and a maintained line

The release history shows v7.2 from 2026-09-04, preceded by v7.2-RC1 from 2026-08-07 and v7.1 from 2025-10-08. The last push was on 2026-10-15, so the tree is being worked on after the current release.

The presence of a release candidate a month before the final release is the normal pattern for a project that tracks an upstream standard closely. PoCL's version numbers track OpenCL releases in a sense, since the developed OpenCL version is a per-driver column in the driver table, and the major version bumps when a new OpenCL version is targeted.

The driver table lists 3.0 as the developed OpenCL version for CPU, Level Zero and CUDA, with the OpenASIP driver lagging at 1.2. So PoCL is a project whose headline version number and the OpenCL version it implements are related but not identical, and that distinction is worth holding on to when reading release notes.

There is a SECURITY.md at the root and a COPYING file alongside a LICENSE.with.3rdparty file, which is the standard pairing for a project that vendors third-party code and needs to record which licence applies to which part. The licence identifier in the repository metadata is listed as a custom licence GitHub cannot classify, and CREDITS records the contributors.

The project has been running for long enough to have a CREDITS file, a CHANGES file, a .mailmap for contributor name normalisation and a Doxygen configuration in CMakeDoxyfile, which is what a mature infrastructure project accumulates.

Editorial conclusion

PoCL suits a developer who needs an OpenCL implementation they can build from source, read, patch and retarget, and who is working on CPUs or on a device PoCL already supports, because the whole thing is a CMake project over LLVM with no vendor dependency. It is the wrong tool if you need production GPU performance on a vendor card, since the CUDA and Vulkan drivers are marked low maturity with no CTS pass rate given, and it is the wrong choice if you need a hosted GPU platform, since PoCL is a library and ICD loader rather than a service. Before you build it, check the driver maturity table for your target and read the install guide, and note that PoCL can be used from the build directory without installing it system-wide, which is the fastest way to evaluate it.

Frequently asked questions

Official sources

1. Issues
2. pocl/pocl on GitHub
3. Project website
4. README
5. Releases