Zig and GPUs

Summary

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 AMDGCNZig’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. OpenCLToday, 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.ChallengesOne 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. Un...