PoCL 7.2-RC1 landed on August 7 with something more interesting than a version bump. The release candidate claims official OpenCL 3.0 conformance for its CPU device on RISC-V as well as x86-64, validated against the Khronos conformance test suite. That is the difference between an implementation that mostly works and one that has been measured against the specification by the body that wrote it. For anyone building compute on RISC-V boards, and there are more of those every quarter, it means the portable compute story on that architecture stopped being a promise. We looked at what conformance covers, what it does not, and which boards were actually tested.
The short answer
PoCL 7.2-RC1 arrived on August 7 with official OpenCL 3.0 conformance for its CPU device on both RISC-V and x86-64, validated against Khronos conformance test suite tag v2026-03-25-00. Testing ran on the Star64 and Milk-V Jupiter RISC-V boards and an AMD Ryzen 9 9900X. The CPU driver gained seven extensions including integer dot product and suggested local work size, program scope variables were re-enabled, and LLVM support now reaches version 23 for the CPU back end.
Anyone who has tried to do compute work on a RISC-V board has hit the same wall, and it is never the silicon. The chip is fine. What is missing is the layer above it, the runtimes and libraries that every other architecture takes for granted, and the usual answer has been that something technically builds and nobody has checked how correct it is. PoCL 7.2-RC1 moves one piece of that off the list.
What conformance means, and why it is not a formality
The Portable Computing Language is an open source OpenCL implementation whose distinguishing feature is that it does not need a GPU. It compiles OpenCL kernels through LLVM and runs them on CPU cores, and through additional back ends it also targets NVIDIA GPUs via libCUDA, Intel GPUs via Level Zero and remote devices.
The claim in 7.2-RC1 is official OpenCL 3.0 conformance for the CPU device on RISC-V and x86-64, validated against the Khronos conformance test suite at tag v2026-03-25-00. It is worth being precise about what that buys you, because conformance is a word that gets used loosely.
The test suite checks that the API behaves as specified, that the kernel language compiles what it should, and critically that numerical results fall inside the error bounds the specification mandates. That last part is the one people underestimate. An implementation that is subtly wrong in the last bits of a transcendental function will pass every test you write and then quietly diverge from the reference over a long computation. Conformance testing is designed to find exactly that, and the results are submitted and reviewed rather than self declared, which makes the claim checkable in a way that "we implement OpenCL 3.0" is not.
What conformance does not mean is speed. Nothing in the suite measures throughput. A conformant implementation computes the right answer, in the right amount of error, and says nothing at all about how long it took. Given the boards involved that distinction matters here more than usual.
The RISC-V part, read carefully
The hardware is the detail that makes this credible. Validation ran on a Star64 and a Milk-V Jupiter, both ordinary single board computers you can buy, plus an AMD Ryzen 9 9900X for x86-64. Conformance claims are sometimes established against simulators or internal reference models where behaviour is easier to control, so testing against shipping boards means the result reflects real RISC-V systems, including the optional parts of the architecture that vary between implementations.
Now the caveat that matters most, because it is the thing most likely to be misread. This is CPU device conformance. PoCL compiles your kernels and executes them on the host processor cores, and the RISC-V in the announcement refers to the architecture of that host, not to a graphics processor. There is no RISC-V GPU story here.
What you get instead is a portable, verified path to run OpenCL code on RISC-V hardware, which is useful in two concrete situations. The first is development: writing and validating kernels on a RISC-V machine without needing accelerator hardware attached to it. The second is embedded and edge deployment, where the CPU is the only compute available and the value of OpenCL is having a data parallel programming model with correct semantics rather than hand written threading. Neither of those is GPU acceleration and both are real work.
The extensions worth caring about
Seven extensions joined the CPU driver: cl_khr_extended_bit_ops, cl_khr_device_uuid, cl_khr_suggested_local_work_size, cl_khr_integer_dot_product, cl_khr_kernel_clock, cl_khr_spirv_linkonce_odr and cl_khr_spirv_no_integer_wrap_decoration. Two of them change what it is like to write code against this runtime.
Integer dot product is the primitive that sits underneath quantised inference. If you are doing eight bit arithmetic, and on a CPU only target you very likely are, the alternative is building the same operation out of multiplies and adds in kernel code and hoping the compiler recognises the pattern. Having it exposed as an extension means the runtime can map it to whatever the hardware actually provides.
Suggested local work size is smaller and more immediately satisfying. Choosing a work group size has traditionally meant guessing, benchmarking, or hardcoding a number that was right on the machine you developed on. This extension lets the runtime tell you a sensible value for the kernel and device in front of it. On a project targeting several architectures, that removes a tuning step that never generalised anyway.
The rest of the release is maintenance of the kind that keeps a project alive: program scope variable support re-enabled, LLVM support extended to version 22 for the CUDA and Level Zero back ends and to versions 22 and 23 for the CPU device, and the minimum LLVM requirement raised to 18. Dropping old LLVM versions is how a project that lives on top of LLVM avoids drowning in compatibility code, and 18 is a reasonable floor in 2026.
For anyone deciding what to do with this, the split is straightforward. If you work on RISC-V compute, install the RC and run your own kernels against it, because RISC-V is the newest surface in this release and therefore the one with the fewest independent testers. Bug reports from real workloads are worth more to the project right now than anything else. If you are shipping something, wait for final 7.2. The conformance result will not be withdrawn between RC and release, so waiting costs nothing.
Sources and further reading
- PoCL 7.2-RC1 brings official OpenCL 3.0 conformance on RISC-V and x86_64 CPUs, Phoronix, August 7, 2026
- PoCL releases on GitHub, including the 7.2-RC1 release notes
- PoCL project homepage, portablecl.org
- Khronos OpenCL conformance test suite
- The OpenCL 3.0 specification, Khronos Group
- PoCL 7.0 released with official OpenCL 3.0 conformance on x86_64 CPUs, Phoronix
Frequently asked questions
What does OpenCL conformance actually guarantee?
That an implementation passed the Khronos OpenCL Conformance Test Suite, a large body of tests that exercises the API surface, the kernel language and the numerical accuracy requirements of the specification. PoCL 7.2-RC1 was validated against CTS tag v2026-03-25-00. The guarantee is about correctness and portability rather than performance: a conformant implementation computes what the specification says it should, floating point results fall inside the mandated error bounds, and API calls behave as documented. Nothing about conformance says the implementation is fast. What it buys you in practice is the ability to stop writing defensive code for one particular runtime's quirks, which is most of the actual cost of targeting a new platform. It is also a claim someone can check, since conformance submissions are reviewed rather than self declared, and that distinguishes it from a project simply asserting that it implements a standard.
Which RISC-V hardware was this tested on?
Two boards, the Star64 and the Milk-V Jupiter, both readily available single board computers rather than simulators or internal silicon. On the x86-64 side the CPU device was validated on an AMD Ryzen 9 9900X. That choice of hardware is worth noticing, because conformance claims are sometimes made against emulators or reference models where behaviour is easier to control. Testing on shipping boards means the result reflects what a real RISC-V system does, including the parts of the architecture that are optional and vary between implementations. It also sets the expectation correctly. These are modest processors, so the conformance result tells you your kernels will produce correct answers, not that they will produce them quickly.
Does this mean OpenCL runs on RISC-V GPUs?
No, and this is the most common misreading. The conformance is for the CPU device, meaning PoCL compiles your OpenCL kernels and executes them on the host processor cores. The RISC-V part refers to the CPU architecture of the machine, not to a graphics processor. PoCL does target accelerators through other back ends, NVIDIA GPUs through libCUDA and Intel GPUs through Level Zero, and it gained Level Zero conformance alongside x86-64 CPU conformance back in the 7.0 release. But on a RISC-V board today, PoCL gives you a correct and portable way to run OpenCL code on the CPU. That is genuinely useful for development and for embedded work, and it is not the same as GPU acceleration.
What else changed in 7.2 besides the conformance result?
The CPU driver picked up seven extensions: cl_khr_extended_bit_ops, cl_khr_device_uuid, cl_khr_suggested_local_work_size, cl_khr_integer_dot_product, cl_khr_kernel_clock, cl_khr_spirv_linkonce_odr and cl_khr_spirv_no_integer_wrap_decoration. Two of those matter more than the rest for typical work. Integer dot product is the primitive underneath quantised inference, so having it exposed rather than emulated in kernel code is the difference between reasonable and painful for anyone doing low precision arithmetic. Suggested local work size lets the runtime tell you a sensible work group size instead of leaving you to guess or benchmark, which removes a genuinely annoying piece of tuning. Program scope variable support was also re-enabled, and LLVM support moved forward: up to LLVM 22 for the CUDA and Level Zero back ends, LLVM 22 and 23 for the CPU device, with the minimum raised to LLVM 18.
Should I use a release candidate?
For evaluation yes, for production no, which is the ordinary answer and it applies here. An RC exists so that people run it on configurations the developers do not have, and a project supporting this many architectures and LLVM versions genuinely needs that. If you work on RISC-V compute, testing this RC and reporting what breaks is the single most useful thing you can do, because RISC-V is the newest surface in the release and therefore the one with the fewest independent testers. If you are shipping something, wait for the final 7.2. The conformance result is not going to be withdrawn between RC and release, so nothing is lost by waiting, and an RC is by definition a build the project has not finished validating.