naga

That wouldn't have been all that different from WGSL though, the most important thing is that whatever WebGPU uses for its shaders can be translated to and from SPRIV (e.g. via https://dawn.googlesource.com/tint and https://github.com/gfx-rs/naga).

Minor nitpick: this translation happens in separate libraries/tools which just make use of the SPIRVTools library for some SPIRV processing tasks, but not the actual translation to WGSL. Tint (Google, implemented in C++): https://dawn.googlesource.com/tint/ Naga (Mozilla(?), implemented mostly in Rust): https://github.com/gfx-rs/naga Both are a bit similar to SPIRV-Cross, except that they also support WGSL.

> What guarantees do you have it won't happen again? Apple was pretty clear about their intent not to ship WebGL2, and they did the opposite for WebGPU so it's not gonna be the same story. Of course, I can't be 100% sure that Apple won't change their mind (like they eventually did for WebGL2) or anything, but there is no reason to believe they'll do so. > Even if Apple had done it on time, it was a 2012 hardware API for 2017 hardware Most games released in 2017 had to support hardware from 2012 anyway. Even AAA games released this year support GPU released in 2012[0]! For non AAA games, targeting a 5-years old API is probably the newest you can afford. We're not talking about bringing the bleeding edge GPU tech to the web (it won't, it's never standardised anyway, like Mesh shaders you talked about). The goal is to provide modern standard

I took a very different approach for porting my WebGPU shaders over: I have far too many shaders to port (sometimes pretty massive ones! [0]), so I used Naga [1] at to runtime-translate my GLSL shaders to WGSL. I had to get involved a bit upstream to fix quite a few different bugs in the implementation, but once I got it working I was really happy with the result. It's quite fast, it compiles to a pretty light-weight WebAssembly module, and it works surprisingly well. [0] https://github.com/magcius/noclip.website/blob/e15f8045cf262... [1] https://github.com/gfx-rs/naga/

Shipping compiled shaders is a feature request that pops up from time to time in gfx-rs land [1]. So far, we have been skeptical about this. Something like a serializable pipeline cache would help, but not entirely solve the shipping binary size. Although, is it really important? "Hello Triangle" may be a few megs, but the code for shader translation is a constant addition to it, so extrapolating this 5.2Mb value is not useful. Currently, both Dawn and wgpu-native use SPIRV-Cross for translation of shaders. The plan is for both is to migrate to in-house translation. In case of wgpu, that would be Naga [2]. Sometime in the future, you could be able to include it with only WGSL -> AIR (Apple's shader IR) code path compiled in, without anything else. Could be good enough for the code size? :) [1] https://github.com/gfx-rs/gfx/issues/3117