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.
jsheard 6 hours 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.
>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."
So apple's making graphics apis worse this time around :)
torginus 6 hours 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 4 hours 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 4 hours 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 3 hours ago [-]
Vulkan runs everywhere (apart from Apple ecosystem and browser), DirectX accepts SPIR-V nowadays.
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
MindSpunk 5 hours 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.
lights0123 6 hours ago [-]
You could always translate to DXIL directly, though the Chromium team has brought up drivers are used to DXC's output
elabajaba 5 hours ago [-]
No need to transcode to HLSL, DXC already accepts SPIR-V input (and both Chrome and FF are shipping DXC).
petermcneeley 5 hours ago [-]
If you have precompiled SPIR-V you can simply use SpirvReader to go to wgsl.
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).
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.
>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...
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.
https://dawn.googlesource.com/tint/+/refs/heads/chromium/466...