← Back to Blog
RISC-V Development

OpenCL 3.1.2 Ships With Finalised Command Buffers as PoCL 7.2 Adds RISC-V Conformance

2026-09-21 5 min read EN
RISC-V OpenCL PoCL Khronos LLVM command buffers GPGPU conformance SPIR-V CPU device

Table of Contents

Published: 2026-09-21 · Category: RISC-V Development · Reading time: ~5 min · Status: DRAFT

Two releases, two different claims

Two things happened close together and they are easy to conflate, so let's separate them first:

Note the version gap. PoCL 7.2's conformance claim is against OpenCL 3.0, tested with OpenCL-CTS tag v2026-03-25-00. It is not a claim of 3.1 or 3.1.2 conformance. If you are writing a compliance matrix, those are two rows.

What command buffers actually buy you

Khronos describes cl_khr_command_buffer in one sentence with a large implication: it "lets applications record a sequence of commands once and replay it repeatedly, reducing CPU overhead and giving drivers opportunities to optimize across the entire sequence."

The workload that benefits is the one with a repeated execution pattern — and Khronos names it directly: AI inference. An inference loop enqueues the same kernel graph thousands of times. Today each submission pays enqueue cost and gives the driver only one command of lookahead. A command buffer amortises the submission and lets the driver see the whole graph.

That matters more on RISC-V than on x86, because on a RISC-V host the CPU-side enqueue path is frequently the constraint rather than the kernel. Anything that removes per-iteration host work is worth measuring.

What is inside PoCL 7.2

From the GitHub release notes for tag v7.2 (published 4 Sep 2026 14:11, maintainer franz):

Two of those extensions are worth calling out for ML work: cl_khr_integer_dot_product is the integer dot-product path that quantised inference leans on, and cl_khr_suggested_local_work_size lets an application ask the implementation what work-group shape it actually wants instead of guessing.

The LLVM floor is the part that will break your build

Minimum LLVM 18 is the operational headline. If your RISC-V toolchain image is pinned to LLVM 17, PoCL 7.2 will not build. Conversely, if you are on LLVM 23 you are only covered on the CPU device — CUDA and LevelZero paths stop at 22.

For a RISC-V CPU-device deployment this is straightforward: LLVM 18 through 23 works, and 22 or 23 is the natural target.

Why "conformance" is not "performance"

Conformance means the implementation passes the conformance test suite — it behaves correctly against the specification. It says nothing about throughput, and it does not mean two conformant devices expose the same feature set. OpenCL 3.0 makes many things optional beyond the 1.2 baseline, so two conformant platforms can differ materially in what your kernels may legally use.

Practically: query for the extension you need, do not infer it from the conformance badge. cl_khr_integer_dot_product being in the release notes tells you it may be exposed; clGetDeviceInfo on your actual board tells you whether it is.

OpenCL 3.1 context, and the SDK

Khronos released OpenCL 3.1 on 4 May 2026, moving several previously optional capabilities into the core — SPIR-V kernel consumption, subgroups, integer dot products, a suggested work-group size query, and a device UUID query matching Vulkan's. Implementations were listed as in progress from Arm, Imagination, Intel, Mesa and Qualcomm, plus Rusticl, PoCL and CLVK on the open-source side.

Also on 14 September 2026, Khronos issued an RFP for OpenCL SDK maintenance, covering the samples, utility libraries, language bindings and CI. Worth watching if your build depends on the SDK rather than the runtime alone.

Not disclosed / not verified

Sources

Verification notes

Open RISC-V — RISC-V Silicon & Development Board Store — open-riscv.com