Zig and GPUs

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!

Keep your files stored safely and securely with the SanDisk 2TB Extreme Portable SSD. With over 69,505 ratings and an impressive 4.6 out of 5 stars, this product has been purchased over 8K+ times in the past month. At only $129.99, this Amazon’s Choice product is a must-have for secure file storage.

Help keep private content private with the included password protection featuring 256-bit AES hardware encryption. Order now for just $129.99 on Amazon!

Help Power Techcratic’s Future – Scan To Support

If Techcratic’s content and insights have helped you, consider giving back by supporting the platform with crypto. Every contribution makes a difference, whether it’s for high-quality content, server maintenance, or future updates. Techcratic is constantly evolving, and your support helps drive that progress.

As a solo operator who wears all the hats, creating content, managing the tech, and running the site, your support allows me to stay focused on delivering valuable resources. Your support keeps everything running smoothly and enables me to continue creating the content you love. I’m deeply grateful for your support, it truly means the world to me! Thank you!