-
Notifications
You must be signed in to change notification settings - Fork 169
[WebGPU, Dawn]: Upgrade Dawn and new features for WebGPU #727
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
[WebGPU, Dawn]: Upgrade Dawn and new features for WebGPU #727
Conversation
| return Result; | ||
| } | ||
|
|
||
| void StripGoogleHlslFunctionality(std::vector<uint32_t>& SPIRV) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe legalization pass from SPIRV Tools will work for this,
|
Thanks for looking into this - I tried updating Dawn a couple of months ago and realized it was hopeless.
If I update Emscripten to 4.0.20, it will break current WebGPU build?
This is just so annoying. They keep breaking things that used to work. |
|
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? |
We need to check the change history to find when they removed the |
|
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 |
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 acbuffername 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.