Dzmitry Malyshau (kvark), a graphics engineer on WebGPU and wgpu, writes about SPIR-V, shaders, and GPU APIs.
HN commenters cite his SPIR-V posts as a technical explanation of why WebGPU uses WGSL, and call his summary of the debate balanced.
The author list and W3C document are pretty much irrelevant, the actual working group is what counts.
After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy.
The story is essentially:
Apple wants SPIRV dead.
Mozilla wants SPIRV alive.
Google wants SPIRV alive.
Google developed a human readable text version for SPIRV, which is isomorphic to the binary version, akin to WASM <-> WAT.
Mozilla wants SPIRV, which Apple fully rejects (because of some legal dispute with Chronos, where Apple probably tries to get a patent for something that Chronos has as prior art or something), but they are open to googles proposal of a textural intermediary, which is isomorphic.
Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal.
This decision is captured in the W3C proposal which to this day contains the Isomorphism property.
That's the Embrace, WGSL is born.
Apple convinces Mozilla and Google that WGSL should be even more human readable, since user readable formats are the backbone of the open web. But for more convenience WGSL will need more features. Extend.
Apple convinces Mozilla and Google that now that the language has grown anyways they should make it much more compatible with other shading languages in general, SPIRV will not be the only target,…
Faith Ekstrand has an impressive track record of compiler work and has written a few blog posts[1], [1a]. Her Mastodon[2] is also worth a follow.
SPIR-V is important in the compute shader space, especially because DXIL and Metal's AIR are similar. I'm going to link three articles critical of SPIR-V: [3], [4], [5].
WebGPU [6] is interesting for a number of reasons, largely because they're trying to actually nail down the semantics, and also make it safe (see the uniformity analysis [7] in particular, which is a very "compiler" approach to a GPU-specific problem). Both Tint and naga projects are open source, with lots of high quality discussion in the issue trackers.
Shader languages suck, and we really need a good one. Promising approaches are Circle [8] (which is C++ based, very advanced but not open source), and Slang [9] (an evolution of HLSL). The Vcc work (also related to [4]) is worth studying.
Best of luck! This is a fascinating, if frustrating, space, and there's lots of room to improve things.
[1]: https://www.gfxstrand.net/faith/blog/
[1a]: https://www.collabora.com/news-and-blog/blog/2024/04/25/re-converging-control-flow-on-nvidia-gpus/
[2]: https://mastodon.gamedev.place/@gfxstrand
[3]: https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
[4]: https://xol.io/blah/the-trouble-with-spirv/
[5]: https://themaister.net/blog/2022/08/21/my-personal-hell-of-translating-dxil-to-spir-v-finale/
[6]: https://github.com/gpuweb/gpuweb
[7]:…
What he wrote was not just a devils advocate position. I encourage everyone to read it in full. Also his 'Horrors of SPIR-V' article a year later[0] which has this conclusion:
> I had a chance to work with SPIR-V rather intimately, and I’m becoming convinced that most of the defenders of this format (who like to criticize WGSL in turn) have little experience actually doing anything with it [...] I was one of them. SPIR-V is probably a good format for what it was made for: driver compilers. It’s not as good for the intermediate portable representations of your shaders.
[0] http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
> Apple's other stance, very strongly stated, was that no binary IR of any kind was acceptable, full stop.
Very strongly stated /where/?
I linked my source, in which kvark clearly stated two things (not as part of his 'devils advocate' position) that directly contradict your claim:
> There is much more to it than just "Apple cannot do X" that often shows up.
> the group agreed to [...] take the semantics of SPIR-V where it makes sense
If there really is a source for it, I'd love to see it (genuinely).
You may want to read this summary of the arguments pro and con SPIR-V, made by Kvark a gfx engineer at Mozilla, so you have a more balanced view of the topic :
The summary exists in two variants: a graphic summary[1] and a textual one[2].
[1] https://kvark.github.io/webgpu-debate/SPIR-V.component.html
[2] https://kvark.github.io/webgpu-debate/SPIR-V.html
Apparently wgsl was created because SPIR-V isn't well suited for being an intermediate representation to target graphics APIs other than Vulkan itself.
Some notes of intrest: https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
WebGPU on native is the best bet to bring back the times where you could reasonably write once and run everywhere. See also - http://kvark.github.io/web/gpu/native/2020/05/03/point-of-webgpu-native.html