Kompute: Vulkan Compute Without the Vulkan Boilerplate

The Vulkan boilerplate Kompute removes

Writing a single Vulkan compute dispatch by hand means creating an instance, enumerating physical devices, selecting a queue family with compute capability, creating a logical device, allocating a descriptor set layout, a pipeline layout, a compute pipeline, a command pool, command buffers, and then managing buffer memory against the right heap flags. Kompute collapses that into a Manager object, tensors allocated through the manager, and an algorithm built from a compiled shader. The README's first C++ example shows the whole flow in about thirty lines, ending with a comment that the manager releases all CPU and GPU memory resources when it goes out of scope. That lifetime coupling is the design decision worth noticing: you do not call a teardown function, you let the manager destruct. For a library intended to be embedded in a larger Vulkan application, this is convenient, but it does mean the manager's lifetime defines the window in which your tensors are valid. The project describes itself as bring-your-own-Vulkan, meaning it is meant to sit alongside an existing Vulkan setup rather than replace it.

Tensors, algorithms and sequences: the actual data flow

The README's example makes the three-part model explicit. Tensors are created through the manager, either with the default float constructor (mgr.tensor) or the typed constructor (mgr.tensorT) which the documentation says supports uint32, int32, double, float and bool. Algorithms bind a set of tensors to a compiled shader, a workgroup size, specialization constants and push constants. Sequences record operations against those algorithms and evaluate them, either synchronously with eval() or asynchronously with evalAsync() followed by evalAwait(). The example records an OpSyncDevice, dispatches the algorithm, evaluates, then records a second dispatch with different push constants and evaluates only that last operation. That second eval shows the sequence is not a batch that reruns everything; it evaluates what has been recorded since the previous evaluation. The asynchronous path is the one that matters for real workloads: the README shows evalAsync on an OpSyncLocal, then other host work, then evalAwait. The documentation also refers to GPU family queues for parallel processing, which is the mechanism behind running independent work concurrently rather than serially on one queue.

Building and calling it: commands and config keys

The repository builds with CMake; the README badge states the build system and the version badge reads 0.7.0 even though the latest release listed on the repository is v0.9.0, so treat the badge as stale. The documentation site at kompute.cc hosts the build and installation pages, and the README points to the Python module as the faster path to a first run. The Python interface is described as a module with the C++ SDK available for optimizations, which tells you the intended split: prototype in Python, drop to C++ when the dispatch pattern is settled. Shaders are supplied either as raw strings passed through a compileSource call or precompiled to SPIR-V and C++ header files using the Kompute tools, as the example's comment notes. The manager constructor takes device index, queue and extensions; the example uses the default, which the comment describes as device 0, first queue and no extensions. That default is fine for a single-GPU desktop and wrong for a multi-GPU or headless server where the compute-capable device is not index 0.

Where Kompute is the wrong tool

The API surface is not stable across releases in a way that matters for long-lived binaries. The gap between v0.8.1 in April 2022 and v0.9.0 in January 2024 is nearly two years, and the README still advertises version 0.7.0. A project that pins Kompute should expect to read the release notes before every bump and to test shader and sequence code against the new tag. The second limitation is scope. Kompute is a dispatch and memory framework, not a numerical library. The README's examples are element-wise and matrix operations written as shaders; there is no mention of a BLAS-equivalent, no autograd, no kernel fusion compiler. If your workload is a dense matrix multiply, you will be writing the tiling and shared-memory staging yourself, and the how-to-optimize-gemm project listed among the users exists precisely because that work is not in the framework. Third, the Python badge states 3.7 to 3.9. If you are on a newer interpreter, verify the module builds before planning around it. Finally, the mobile examples are Android NDK examples; the README does not claim iOS support, so do not assume it.

What you give up against CUDA and against raw Vulkan

Against CUDA, the difference is portability versus tooling. CUDA gives you cuBLAS, cuDNN, Nsight, and a compiler that has been tuned for one vendor's hardware for over a decade. Kompute gives you one code path that the README says targets AMD, Qualcomm, NVIDIA and others through Vulkan, which is why GPT4ALL and a LLaMA port appear in the users list: on-edge inference across heterogeneous consumer hardware is exactly the case where a single vendor stack fails. Against raw Vulkan, the difference is control versus volume. Raw Vulkan lets you manage descriptor pools, memory aliasing and pipeline caches precisely, which matters if you are already deep in a renderer and want to share resources. Kompute's memory ownership model is documented as explicit for GPU and host, but the abstraction sits between you and the driver. If your application already has a Vulkan device and a resource cache, adopting Kompute means either duplicating device state or using the bring-your-own-Vulkan path, and the README does not spell out how much of an existing VkDevice Kompute will accept. That is a question to answer from the documentation before you commit.

Maintenance, licensing and what to check first

The licence is Apache-2.0, which permits commercial and closed-source use and includes a patent grant. It does not require you to publish your shaders or your host code. The usual obligations apply: keep the licence and notice files, and state changes if you modify the source. This is not legal advice; your counsel should review the NOTICE file and any bundled third-party code, since a Vulkan framework will pull in Vulkan headers and possibly other dependencies with their own terms. On maintenance, the project is hosted by the LF AI & Data Foundation, which the README states, and it is not archived. The release cadence is the practical concern: three releases listed, spanning 2021 to 2024, with the most recent push to the default branch in August 2026. A repository that is active but slow to tag means you may be tracking master to get fixes, which is a different risk profile from consuming tagged releases. Before adopting, check the release notes for v0.9.0 against the API in the README example, confirm your device's compute queue family is exposed, and decide whether you are willing to build from source rather than depend on a packaged version.

Editorial conclusion

Adopt Kompute if your application already owns a Vulkan instance and you need compute dispatches on AMD, Qualcomm or NVIDIA hardware from the same codebase, or if you want to call compute shaders from Python without a CUDA dependency. Do not adopt it if you need a versioned ABI, if your target is a single NVIDIA generation where CUDA or cuBLAS already covers the workload, or if you cannot accept pinning to a release that has not moved since January 2024. Before committing, verify three things on your own hardware: that your target device exposes the queue families the Manager expects, that your shaders compile to SPIR-V through the documented compileSource path or the bundled tools, and that the Python module installs against your interpreter version, since the README badge states Python 3.7 to 3.9 while the C++ side is documented as C++14 to C++20.

Official sources

1. KomputeProject/kompute on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases