clspv and the path from OpenCL C to Vulkan compute shaders

Clspv compiles OpenCL C, not SPIR-V, and the input dialect is narrower than OpenCL

clspv is a compiler for OpenCL C targeting Vulkan compute shaders. That framing matters more than it first appears, because the alternative route to a Vulkan compute shader is to write SPIR-V directly or to use a shading language such as GLSL. clspv lets you keep an existing OpenCL C kernel and change the target, which is the common case for teams that already have a working OpenCL codebase and a Vulkan driver underneath.

The catch sits in the word subset. The README describes the `clspv` command as a compiler for a subset of OpenCL C, and states plainly that the input language is OpenCL C version 1.2. The mapping from that subset into Vulkan compute shaders is documented separately in the OpenCL C on Vulkan Specification, which the README points to for information on support and mapping.

That document is the contract. It also means the subset boundary is a moving target tied to the specification rather than to the full OpenCL 3.0 feature set, so a kernel that uses an unusual OpenCL C construct has to be checked against that document rather than assumed to work.

Two halves: a set of LLVM passes and a command line driver

The README describes clspv as consisting of two parts. The first is a set of LLVM Module passes that transform a dialect of LLVM IR into a SPIR-V module containing Vulkan compute shaders. The second is the command line compiler tool named `clspv`, which compiles a subset of OpenCL C into a Vulkan compute shader.

The split tells you where the interesting work lives. The passes operate on an LLVM IR dialect, not on OpenCL C source, so the pipeline is Clang and LLVM front ends first, then clspv's own transformation passes, then SPIR-V assembly. The repository layout matches: `lib/` holds the implementation, `include/` the headers, `tools/` the driver, `amber/` an additional test corpus directory, and `test/` the test suite.

Because the compiler is built on top-of-tree Clang, LLVM and libclc, the dependency set is not light. `deps.json` records the external projects, and `utils/fetch_sources.py` pulls the exact commits into a `third_party` directory.

Compiling a kernel: SPIR-V output, C initialisers, defines and OpenCL flags

The command line surface is small enough to learn in a minute. The base case compiles a set of kernels into a SPIR-V binary module:

    clspv foo.cl -o foo.spv

You should get a `foo.spv` file next to your source. The output can also be emitted as a C initializer list, which is how you embed a shader directly in a C or C++ program source:

    clspv --output-format=c foo.cl -o -

Preprocessor symbols are passed with the familiar `-D` form:

    clspv -DWIDTH=32 -DHEIGHT=64 foo.cl -o foo.spv

OpenCL compiler options are accepted directly as well:

    clspv -cl-fast-relaxed-math -cl-single-precision-constant foo.cl -o foo.spv

That last line is worth pausing on. `-cl-fast-relaxed-math` is an OpenCL option, and forwarding it means the numerical behaviour of your kernel depends on options that the Vulkan pipeline does not have a direct equivalent for. The README does not document how such options are mapped onto Vulkan, so this is a place to verify rather than assume.

Help output is available through `clspv -help`.

Building from source: fetch the pinned dependencies, then configure with CMake

There is no package manager route in the README. Building requires CMake, Python3, a C++ compiler and git. The dependencies come first: clspv needs the sources for other projects at specific commits, and the fetch script places them in the `third_party` directory.

    python3 utils/fetch_sources.py

After that you create a build directory and configure:

    cd <clspv-dir>
    mkdir build
    cd build

Then the two CMake commands that produce the compiler:

    cmake <clspv-dir>
    cmake --build .

The result lands at `bin/clspv` under the build directory. The README recommends the Ninja build tool when it is available, in which case the last two commands become:

    cmake -G Ninja <clspv-dir>
    ninja

One configuration option is called out. Passing `-DCMAKE_BUILD_TYPE=RelWithDebInfo` produces a release build with debugging information, while the default is a debug build. That default matters in practice, since a debug build of an LLVM based compiler is markedly slower than what you would want for a shipping toolchain.

check-spirv is the test suite, and the spec lives beside the compiler

Verification is driven from the build directory through a CMake target:

    cmake --build . --target check-spirv

Or, with Ninja:

    ninja check-spirv

The target name tells you what the suite checks. It validates the generated SPIR-V rather than comparing compiler output text, which is the right approach for a backend that emits a binary module.

The repository also carries `docs/`, which holds the OpenCL C on Vulkan Specification that defines the supported subset, plus `kokoro/` for continuous integration configuration and `utils/` for the source fetch script. Note that `docs/OpenCLCOnVulkan.md` is the single most important file for a prospective user, because it is where the mapping decisions are written down, and clspv ships no equivalent of a user manual beyond the README.

Conformance is claimed with clvk as the runtime driver

The README states that clspv has passed OpenCL 3.0 conformance, and it is specific about the conditions. The runtime driver is clvk, the OpenCL implementation for Vulkan, under Khronos submission 419. Two release tags are named for that configuration: `khronos-submission-419` for clvk and `clvk-khronos-submission-419` for clspv.

Read precisely, this is a paired statement. The compiler passed conformance as part of a submission that pairs a specific clspv tag with a specific clvk tag. It is not a general claim about every build, and the tags are the thing to reproduce if you need the same result.

For comparison, the alternative is to stay with the classic OpenCL path and hand your kernel to a CPU or GPU runtime driver, which accepts OpenCL C directly and executes it on its own compute stack. clspv changes where the code ends up: you get a SPIR-V module containing Vulkan compute shaders, and the runtime is now a Vulkan driver rather than an OpenCL one. The trade is portability of the source language for portability of the execution target.

Apache 2.0, no GitHub releases, and a daily compiler-explorer build

clspv is licensed under the terms of the Apache 2.0 license, with the text in the LICENSE file at the repository root. The AUTHORS file lists the copyright owners, individual credit is in CONTRIBUTORS, and contributions are described in CONTRIBUTING.md. The README also notes that materials in the projects clspv depends on are licensed under their own terms, which matters in practice because a clspv build pulls in Clang, LLVM, libclc, SPIRV-Tools and SPIRV-Headers, all with separate licences.

The repository has no GitHub releases, so version tracking happens through commits and through the tags named in the conformance section. The last push was on 2026-10-19.

One more distribution channel is worth knowing about. clspv is available in Compiler Explorer among the OpenCL C compilers, and the README states it is built daily by that infrastructure. For anyone evaluating whether clspv can handle a given kernel, that is a faster path than building LLVM yourself, and it also means a browser based check exercises the compiler as it stands on that day rather than a pinned local build.

Editorial conclusion

clspv is the right tool if you want to keep writing OpenCL C and ship SPIR-V to Vulkan, particularly for compute work where a runtime driver such as clvk is already in your stack, and the documented OpenCL C on Vulkan specification covers the feature you need. It is the wrong tool for code relying on OpenCL extensions or images beyond the documented subset, and it is a poor fit if you want a package manager install rather than a source build. Verify first which OpenCL C features your kernel uses against docs/OpenCLCOnVulkan.md, because the accepted input language is OpenCL C version 1.2 and the conformance claim is scoped to the submission 419 configuration.

Frequently asked questions

Official sources

1. google/clspv on GitHub
2. Issues
3. License: Apache-2.0
4. README