DiligentGraphics
[WebGPU, Dawn]: Upgrade Dawn and new features for WebGPU
To build for the web, an update to Emscripten 4.0.20 is required (the WebGPU integration method changed starting from 4.0.10).
Previously, Tint had two paths to translate SPIR-V to WGSL. Unfortunately, the one we were using has been removed, and we also had to apply a few changes in order to make everything work through ReadIR (unfortunately, not everything works yet — more on that later).
The new Tint version cannot automatically infer the access mode for StorageTexture (it defaults to read_write), so we had to patch the SPIR-V code using additional metadata embedded into HLSL (the same logic we use for the texture format).
We also ran into an issue where Tint merges structure types in WGSL when converting cbuffer, which made it impossible to reliably recover the resource binding group by name from the WGSL output. It took quite some effort to convince the Tint team to acknowledge this problem(https://dawn-review.googlesource.com/c/dawn/+/278115).
However, there is still another issue: the new converter version appends a _ [1–9] suffix to types for uniform buffers according to some unclear logic. As a result, if the user explicitly adds a suffix like _1, _2, etc. to a cbuffer name in HLSL (e.g. Buffer_1, Buffer_2), it becomes impossible to resolve the name unambiguously — we cannot tell whether the suffix originally came from the user or was generated by Tint.
Thanks for looking into this - I tried updating Dawn a couple of months ago and realized it was hopeless.
To build for the web, an update to Emscripten 4.0.20 is required (the WebGPU integration method changed starting from 4.0.10).
If I update Emscripten to 4.0.20, it will break current WebGPU build?
The new Tint version cannot automatically infer the access mode for StorageTexture (it defaults to read_write), so we had to patch the SPIR-V code using additional metadata embedded into HLSL (the same logic we use for the texture format).
This is just so annoying. They keep breaking things that used to work. How does it work for them, so they can't use SPIRV themselves? Are you sure there is no other way, it just so strange.
Yes, if you update Emscripten to version 4.0.20, the project will stop building without my PR. It also frustrates me that backward compatibility keeps breaking. I haven’t found any way to enable automatic access-mode inference. I’ll ask in the WebGPU chat whether they can bring back the old functionality (most likely not — it’s very difficult to argue with them. I spent almost a week trying to convince them to disable type merging for uniform buffers). In theory, we could infer the access mode ourselves, but that would require a deep understanding of the SPIR-V specification to handle everything correctly.
With every update they seem to make things worse (I have a complex shader set and one of the shaders stopped compiling with the new version of Tint, even though it worked with the old one). But unfortunately, without these updates it’s impossible to enable new features — and “texture-tier1” / “texture-tier2” are very useful features.
In which version did they break Tint? Can we update to that version? Maybe later they will fix something.
In which version did they break Tint? Can we update to that version? Maybe later they will fix something.
We need to check the change history to find when they removed the tint::spirv::reader::Read() function. It’s possible they removed it before adding support for the new texture-format features, in which case updating doesn’t make much sense in my opinion.
It still makes sense, at least we will be able to break this giant change into smaller parts, and start with changes related solely to the API changes