GPU programming used to mean wrangling C++ compilers, bloated SDKs, and vendor-specific toolchains. That’s changing. You can now write GPU code in modern languages like Rust and Zig with fewer layers. This post walks through the current state of Zig’s GPU backends and how they stack up across Vulkan, OpenCL, and native ISAs.

SPIR-V, PTX and AMDGCN

Zig’s GPU backend support has been steadily evolving. After roughly 4 years, the self-hosted SPIR-V backend is now mature enough to experiment with and port basic shaders and compute kernels. In case you don’t know, SPIR-V is an intermediate typed IR used by Vulkan, OpenCL, and soon DirectX. Zig can also use LLVM to directly generate PTX (NVIDIA) and AMDGCN (AMD) code, producing native binaries that can be loaded at runtime. This opens the door to writing high-performance GPU code without needing to touch CUDA, HIP, or HLSL.

export fn kernel() callconv(.kernel) void {}

For a complete example, checkout snektron/shallenge.

Vulkan vs. OpenCL

Today, Vulkan and OpenCL are the two major SPIR-V environments — but they diverge in a few aspects. in OpenCL, capabilities like Kernel and Addresses are guaranteed to be available. As a result, pointer arithmetic and casting are permitted. Whereas the baseline features for Vulkan and OpenGL environments tend to be more limited. This is why when targeting baseline Vulkan 1.2 features, Zig’s SPIR-V backend passes about 50% of Zig’s behavior tests and ~75% for the OpenCL target. Note that these numbers are not expected to get significantly higher since a lot of these tests are not meant to be working in GPUs anyway.

Challenges

One core challenge in targeting SPIR-V from a general-purpose language like Zig is the need to explicitly specify address spaces (a.k.a. storage classes). Zig supports this via the addrspace keyword, but nearly all Zig code assumes pointers live in the generic address space. That works fine until you need to lower to SPIR-V, where we sometimes rely on OpPtrCastToGeneric. Unfortunately, Vulkan doesn’t support that, so as a temporary workaround, all pointers are assumed to be local (Function) memory.

Both Vulkan and OpenCL expose hardware-accelerated math instructions via OpExtInst, which sometimes can be mapped directly to Zig’s @builtins target-specific instructions when available. However, subtle differences exist. For example, unlike Zig or OpenCL, some Vulkan instructions (fma, sqrt, exp, log) do NOT guarantee correctly rounded results.

What’s next?

• Composite integers
• spirv-val should never fail on a binary emitted by Zig. As Zen says, “Compile errors are better than runtime crashes”.
• Increase passing behavior tests.
• Provide bindings to CUDA/HIP runtime.
• Add or extend a set of common algorithms in stdlib to work under GPUs (prefix sum, reduction, matmul, etc).
• You tell!