Webgpu and the Price of Compiling Wgsl

Posted3 months agoActive3 months ago

todsacerdoti

45 points

26 comments

hugodaniel.comTechstory

calmmixed

Debate

40/100

WebgpuWgslGPU Programming

Key topics

Webgpu

Wgsl

GPU Programming

The article discusses the author's experience with WebGPU and the performance issues encountered when compiling WGSL shaders, sparking a discussion on shader compilation, GPU programming, and potential optimizations.

Snapshot generated from the HN discussion

Discussion Activity

Very active discussion

First comment

Peak period

0-12h

Avg / period

8.7

Comment distribution26 data points

Loading chart...

Based on 26 loaded comments

Key moments

01Story posted
Oct 6, 2025 at 5:14 PM EDT
3 months ago
Step 01
02First comment
Oct 6, 2025 at 7:14 PM EDT
2h after posting
Step 02
03Peak activity
21 comments in 0-12h
Hottest window of the conversation
Step 03
04Latest activity
Oct 13, 2025 at 8:39 PM EDT
3 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (26 comments)

Showing 26 comments

Cloudef

3 months ago

9 replies

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

3 months ago

3 replies

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

3 months 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

3 months ago

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

elabajaba

3 months ago

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

jsheard

3 months ago

3 replies

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

3 months ago

1 reply

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

flohofwoe

3 months ago

2 replies

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

3 months ago

1 reply

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

jsheard

3 months 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

3 months 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

landr0id

3 months ago

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

pjmlp

3 months ago

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

3 months ago

1 reply

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

3 months ago

2 replies

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

3 months ago

1 reply

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 months ago

1 reply

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

flohofwoe

3 months 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

3 months ago

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

pjmlp

3 months ago

1 reply

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

flohofwoe

3 months 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

3 months ago

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.

FrankenApps

3 months ago

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

petermcneeley

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

flohofwoe

3 months ago

> 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

petermcneeley

3 months ago

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

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

View full discussion on Hacker News

ID: 45496406Type: storyLast synced: 11/20/2025, 12:47:39 PM

Want the full context?