Zig and GPUs

Thu, 17 Apr 2025 00:00:00 +0000

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.

// SPIR-V:
//     zig build-obj -target spirv64-vulkan-none -mcpu vulkan_v1_2+int64 \
//     -ofmt=spirv -fno-llvm kernel.zig
//     zig build-obj -target spirv64-opencl-none -mcpu opencl_v2+int64 \
//     -ofmt=spirv -fno-llvm kernel.zig
//
// PTX:
//     zig build-lib -dynamic -target nvptx64-cuda-none -mcpu <gpu-model> \
//     -femit-asm -fno-emit-bin -fno-ubsan-rt kernel.zig
//
// AMDGCN:
//     zig build-lib -dynamic -target amdgcn-amdhsa-none -mcpu <gpu-model> \
//     -fno-compiler-rt kernel.zig
//

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!

Donate

Wed, 16 Apr 2025 00:00:00 +0000

If you like my work, please consider donating to one of these addreses! Don’t hesitate to reach me out via email or by the alichraghi username in discord and telegram to let me know who you are or if you have any questions!

Monero

43S2tCrmsURechR5n1jdGyRG951roMReZNdvGYX9V1T5huT2dgM9JLKCCCXpNXox2BFz3HsScDDQeLLTbPSrxYX8HRvwCSW

USDT (BEP20)

0x55948246A13181863b4Db18330f87438Fb403b26

Ali Cheraghi