I don't understand why WebGPU does not accept pre-compiled shaders. Every WebGPU implementation supports loading SPIR-V, but the spec just doesn't have it.
l11d•4mo ago
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
lights0123•4mo ago
You could always translate to DXIL directly, though the Chromium team has brought up drivers are used to DXC's output
elabajaba•4mo ago
No need to transcode to HLSL, DXC already accepts SPIR-V input (and both Chrome and FF are shipping DXC).
MindSpunk•4mo ago
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.
jsheard•4mo ago
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, and now we're stuck with WGSL 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 need to support Yet Another Shader Backend. From the old minutes:
> Eric B (Adobe): Creating a new high level language is a cardinal sin. Don’t. Do. That. Don’t want to rewrite all my shaders AGAIN.
> Jesse B (Unity): If we can transcode to HLSL to whatever you need, great. If we can’t, we may not support your platform at all.
> Eric B: Would really not like even to write another transcoder. If there’s an existing tool to get to an intermediate representation, that’s good. Would suggest SPIRV is an EXCELLENT existing intermediate representation.
Cloudef•4mo ago
So apple's making graphics apis worse this time around :)
flohofwoe•4mo ago
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.
Permik•4mo ago
> Vulkan 1.0
Possibly even from Vulkan's Mantle days?
jsheard•4mo ago
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.
xyzsparetimexyz•3mo ago
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
>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."
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.
torginus•4mo ago
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.
Cloudef•4mo ago
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.
greggman65•4mo ago
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.
Cloudef•4mo ago
Vulkan runs everywhere (apart from Apple ecosystem and browser), DirectX accepts SPIR-V nowadays.
flohofwoe•4mo ago
As far as I'm aware, any SPIRV isn't directly fed into the Vulkan backend, it's more like "WebGPU SPIRV => internal 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'?)
torginus•4mo ago
SPIR-V is also a bad format for shaders (according to shader compiler devs):
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).
petermcneeley•4mo ago
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).
petermcneeley•4mo ago
If you have precompiled SPIR-V you can simply use SpirvReader to go to wgsl.
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.
pjmlp•4mo ago
No it doesn't, because not every WebGPU implementation is based on Vulkan.
flohofwoe•4mo ago
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)
flohofwoe•4mo ago
> I don't understand why WebGPU does not accept pre-compiled shaders.
See here for one 'technical pov' from somebody who was involved:
Cloudef•4mo ago
l11d•4mo ago
lights0123•4mo ago
elabajaba•4mo ago
MindSpunk•4mo ago
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.
jsheard•4mo ago
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 need to support Yet Another Shader Backend. From the old minutes:
> Eric B (Adobe): Creating a new high level language is a cardinal sin. Don’t. Do. That. Don’t want to rewrite all my shaders AGAIN.
> Jesse B (Unity): If we can transcode to HLSL to whatever you need, great. If we can’t, we may not support your platform at all.
> Eric B: Would really not like even to write another transcoder. If there’s an existing tool to get to an intermediate representation, that’s good. Would suggest SPIRV is an EXCELLENT existing intermediate representation.
Cloudef•4mo ago
flohofwoe•4mo ago
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.
Permik•4mo ago
jsheard•4mo ago
xyzsparetimexyz•3mo ago
landr0id•4mo ago
>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...
pjmlp•4mo ago
torginus•4mo ago
Cloudef•4mo ago
greggman65•4mo ago
Cloudef•4mo ago
flohofwoe•4mo ago
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'?)
torginus•4mo ago
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).
petermcneeley•4mo ago
petermcneeley•4mo ago
https://dawn.googlesource.com/tint/+/refs/heads/chromium/466...
FrankenApps•4mo ago
flohofwoe•4mo ago
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.
pjmlp•4mo ago
flohofwoe•4mo ago
flohofwoe•4mo ago
See here for one 'technical pov' from somebody who was involved:
https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html