It wasn't a technical decision. Apple decided to veto the use of any Khronos IP such as SPIR-V or GLSL due to a private legal dispute which was never elaborated on. That left the committee with no choice but to reinvent the wheel with WGSL, and now we're stuck with it forever.

It's not the end of the world for web-only projects which can just target WGSL exclusively, but it's a pain in the ass for cross platform engines which now needs to support Yet Another Shader Backend. Representatives from Adobe and Unity were practically begging the committee to just use SPIR-V, which they already supported.

From a previous thread on this topic: https://news.ycombinator.com/item?id=23089745

>It's literally in past WebGPU meeting minutes: Apple objected to SPIR-V due to disputes with Khronos. Tint is a compromise, it doesn't matter who proposed it.

>"MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that. NT: nobody is forced to come into Khronos’ IP framework."

>https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...

So apple's making graphics apis worse this time around :)

The 'bad' parts in WebGPU (anything related to BindGroups) are actually coming from Vulkan 1.0, while the 'good parts' are taken mostly from Metal.

WGSL vs SPIRV is really just a side issue that people want to focus on but doesn't really matter much in the bigger picture.

> Vulkan 1.0 Possibly even from Vulkan's Mantle days?

IIRC AMDs hardware had already adopted a fully bindless model by the time they were developing Mantle, so probably not. Vulkan 1.0 had to go backwards in terms of complexity to accommodate a wider range of hardware, with mobile causing the most pain.

Modern Vulkan code doesn't even use bind groups anymore. For buffers you just push the device address as a push constant and for textures you push the index of a single large texture array

As far we are aware, it goes back to how Khronos managed OpenCL after Apple gave it to the group, and also one of the reasons Metal came to be.

SPIR-V is not precompiled in any meaningful sense of the word. It's just a SSA graph representation of the source code, and only saves you the lexing, parsing and SSA gen steps. The real meat of the compilation happens after that, when the GPU driver compiles the representation into actual GPU shader assembly.

Right, of course SPIR-V is a IR format for the drivers and not the final GPU machine code. I don't think WGSL is a bad language by any means, but I still find it odd that the spec doesn't allow loading SPIR-V to cut out the extra transformation steps, and potential bugs or bad transformations in the WGSL implementation.

What makes you think there wouldn't be a translation step? The majority of the world is on DirectX and Metal, so even if it turn in SPIR-V there would be translation step.

Vulkan runs everywhere (apart from Apple ecosystem and browser), DirectX accepts SPIR-V nowadays.

As far as I'm aware, any SPIRV isn't directly fed into the Vulkan backend, it's more like "WebGPU SPIRV => IR => validation => Vulkan SPIRV".

Also I wouldn't rule out that some browser vendors will accept SPIRV as WebGPU shader input as a non-standard extension one day (disclaimer: talking out of my ass here since I'm not on any of the WebGPU implementation teams). The WebGPU API is prepared for accepting different types of shader inputs (that's how the native implementations accept SPIRV instead of WGSL). I bet that this would solve exactly zero problems though ;)

> DirectX accepts SPIR-V nowadays

That doesn't mean much since SPIRV has different incompatible flavours, e.g. you can't feed a GL SPIRV blob into Vulkan, or a Vulkan SPIRV blob into D3D (does D3D actually already accept SPIRV or is this still in the 'planning stage'?)

SPIR-V is also a bad format for shaders (according to shader compiler devs):

https://themaister.net/blog/2021/09/05/my-personal-hell-of-t...

The TLDR is SSA erases the structured control flow (like loops), which need to be recovered to support how branching is done on SIMD architectures (enabling/disabling lanes).

One of the problems is that libraries consuming SPIR-V are generally not robust enough to handle untrusted web shaders. Also, DirectX doesn't (yet) accept SPIR-V shaders so you'd mandate some translation to HLSL, which in turn would be compiled by dxcompiler.dll

You could always translate to DXIL directly, though the Chromium team has brought up drivers are used to DXC's output

No need to transcode to HLSL, DXC already accepts SPIR-V input (and both Chrome and FF are shipping DXC).

But writing an entirely new, bespoke high-level shader programming language is more robust? And robust in what way? The SPIR-V format is vastly easier to parse than a textual language.

And WGSL will still bounce through HLSL for DirectX because DXIL is an awful, undocumented mess of ancient LLVM-IR with a giant pile of bolt-on special semantics. Directly authoring DXIL is awful.

This probably wont help at all when it comes to the cost of compilation. WGSL -> SPIR-V is very fast. It is the pipeline compilation that is slow (aka whatever happens in the drivers).

If you have precompiled SPIR-V you can simply use SpirvReader to go to wgsl.

https://dawn.googlesource.com/tint/+/refs/heads/chromium/466...

There are some new interesting developments though: https://github.com/gfx-rs/wgpu/pull/8217 Just sadly not in the spec as mentioned.

Technically there are no "precompiled shaders" in any 3D API (outside game consoles). Even in D3D/Vulkan/Metal, shaders are passed into the API as an intermediate bytecode format, which is then compiled to the actual native instructions in the GPU driver, and that's why you get the infamous 'shader compilation stutter' even in the latest AAA PC games.

The expensive part isn't parsing text into an intermediate bytecode format like SPIRV (especially for WGSL which mostly just maps SPIRV-semantics to text), but what happens after that.

And specifically in WebGPU, even when it takes SPIRV as input, that SPIRV is taken apart, validated and then translated into bytecode formats for D3D, Metal or reassembled into another SPIRV blob for Vulkan.

From what I'm understanding from lurking in the WebGPU discussion group, the current main problem with shader compilation is that some innocent looking shaders may unexpectedly 'explode' due to loop unrolling down in the backend 3D API and a few lines of input may take seconds to compile in the worst case - and for that problem, WGSL vs SPIRV input would be irrelevant.

No it doesn't, because not every WebGPU implementation is based on Vulkan.

The native WebGPU implementations accept SPIRV as input, but (AFAIK) it's still taken apart, validated, and translated into the backend-specific shader bytecode formats (AFAIK even for the Vulkan backends the SPIRV isn't simply passed through - at least in Dawn/Tint, not sure about wgpu.rs)

> I don't understand why WebGPU does not accept pre-compiled shaders.

See here for one 'technical pov' from somebody who was involved:

https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html