hckrnws

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.

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.

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 :)

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.

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

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

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

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.

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

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

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).