naga VS gpuweb

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

Think of Vulkan, Metal, DirectX 12 (DX12) as different database engines. They run compute/render shaders which are incompatible dialects of each other (like Oracle SQL != Postgres SQL != MySQL). WGPU tries to be the ANSI SQL.

This an oversimplification ofc. Today most shaders compile to an intermediate form Spir-V which then targets different backends and can lead to some funny translation.

See https://github.com/gpuweb/gpuweb/issues/566

If you do know Rust and know what to pick from, but want to be at bleeding edge and have the best Rust centric graphics libraries can offer, try wgpu which is an implementation of WebGPU. There's a tutorial on how to get started too.

There's an open bug about it: https://github.com/gpuweb/gpuweb/issues/390

When reading "wgpu", I wondered if it used the WebGPU implementation of the same name (wgpu) rather than Dawn. It may be worth changing mentions of "wgpu" to "WebGPU" in zgpu (and these titles) similar to how its dependency, mach-gpu-dawn, uses these names,

Yup! See https://github.com/gpuweb/gpuweb/pull/2562 and linked issues for more context on that one.

Wgpu has performance close to Vulkan in some cases, but still no compute performance benchmarks. Just curios, why wgpu couldn't just make extension to use advanced atomics, multiple queues or other high-performance feature in hardware that supports it? One of Vulkan and wgpu goals are to make it highly customizable through extensions. edit: actually already there is wgpu extension that supports (subgroup operations)[https://github.com/gpuweb/gpuweb/pull/1459]

It is xkcd though.

WebGPU as proposed by Ape was basically Metal. Naturally other vendors weren't keen on implementing this, so they arrived at a compromise which is a bastard child of Metal and Vulkan.

They couldn't even adopt an existing shader language and invented a new one. That goes as far as invent new and unprecedented language constructs https://github.com/gpuweb/gpuweb/issues/569

https://github.com/gpuweb/gpuweb/issues/386 It looks like mipmap generation is coming eventually. In that thread they mention people are using webgl to generate mipmaps and then just sending those into webgpu

The documentation is lacking some information of how to implement or rather use push constants. The closest I could find is this here: https://docs.rs/wgpu/latest/wgpu/struct.RenderPass.html#method.set_push_constants As well as the part that got removed from the Wgsl language: https://github.com/gpuweb/gpuweb/pull/615/files