The trouble with SPIR-V - Gob's blog

submited by

Style Pass

2021-08-25 23:30:04

If you have been dealing with Vulkan, or other modern GPU APIs in any capacity in the last 5 years, you probably heard of SPIR-V. To recap, SPIR-V is a binary format for writing programs that run on the GPU, and it is designed to be consumed by OpenCL and Vulkan. As well as those two, OpenGL 4.6 added support for SPIR-V shaders, and the WebGPU WGSL is essentially a text-form of SPIR-V.

In the case of Vulkan specifically, SPIR-V replaces GLSL as the default way to feed code to the GPU. This is without question a major improvement: GLSL is a human-readable programming language with a lot of syntactic forms that needs to be parsed correctly, and it has been a steady source of implementation bugs, runtime overhead and intellectual property concerns (as you essentially ship the source of every shader in your app!). SPIR-V, much like Vulkan itself, reduces the surface area of the driver responsibilities, here by moving all the front-end stages of compilation to the outside.

I’m going to complain a lot about SPIR-V soon, so I want to make it clear I consider it a vast improvement over its predecessor for graphics (GLSL). I don’t think there is actually something cripplingly terrible about the fundamentals of it, but the implementation of SPIR-V in the real world is problematic for a few reasons. It can and should be improved, this blog post is an argument about what is wrong and how to improve it.