naga VS wgsl-mode

There's a compiler that can translate from WGSL to SPIR-V called naga. Having such a compiler is essential, since WebGPU is planned to use WGSL and browsers are expected to implement rendering via Vulkan (and probably Metal and DX12).

You could setup your build manager to use naga-cli to compile your shaders into spir-v on write

Not sure about on the CPU, but naga is a shading language transpiler you can write custom front/backends for.

For cross-platform support look at WebGPU and Vulkan (e.g,: [0] [1]. Essentially, you would need to write the func in WGSL or GLSL, HLSL or MSL. Each of these can be cross-compiled to SPIR-V (what Vulkan needs) with cross-compilers such as spirv-cross and naga.

anyway, here's the test. https://github.com/gfx-rs/naga/blob/master/tests/in/push-constants.wgsl

You might try https://github.com/gfx-rs/naga for that

Personally, one of the most exciting things about this release is that it took me on a little journey to contribute some fixes to the naga shader translator. Specifically, naga 0.8.1 now properly supports the Fused-Multiply-Add function in the HLSL (DirectX) and GLSL (WebGL2 and GLES 3.1) backends. To be frank, this function does not make a big difference on the tiny shader in pixels. It does however mean that using compute-heavy shaders with wgpu 0.12 can now benefit from this function on all supported backends!

universal shader translation

> 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 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 standardized tech to developers, and it does it in a portable way, which makes it even more affordable.

> Intel had two failed attempts to bring compute into the browser.

So what ?

> Yes it is a very bad thing, when Vulkan can keep using GLSL and HLSL, while DX12 happily will use any HLSL from the API history, and Metal can use proper C++14 shaders.

Vulkan uses SPIR-V, not HSL or GLSL. Translation tooling exist, but it also exists for WGSL -> SPIR-V[1]

Each platform has its own shading language, will this one be better than the other, I don't know but I don't think it's gonna be worse either.

> WGSL is web politics as usual.

Not really. See this summary[2] from a Mozilla gfx engineer:

[0]: https://support.activision.com/black-ops-cold-war/articles/m...

[1]: https://github.com/gfx-rs/naga

[2]: https://kvark.github.io/webgpu-debate/SPIR-V.component.html

IIRC, somebody looked at it, but nothing usable yet. There is, however, cargo-wgsl, vscode-wgsl, Emacs plugin, and Vim plugin