naga VS shaderc

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

Do you mean how to compile Spir-V at runtime? shaderc repo has an example https://github.com/google/shaderc/tree/main/examples/online-compile

_ _ ___| |__ __ _ __| | ___ _ __ / __| '_ \ / _` |/ _` |/ _ \ '__| \__ \ | | | (_| | (_| | __/ | |___/_| |_|\__,_|\__,_|\___|_| shader helps you with compiling your GLSL files into SPIR-V byte code. Examples: | > shader --webservice | | Use webservice to automatically compile all *.glsl files in this project. | > shader --webservice --watch | | Watch for file system changes and use webservice to compile *.glsl files. | > shader --webservice --dart | | Generates a .dart-file with a loading function instead of byte code. | > shader --webservice --put-in-assets | | Places compiled files into the Flutter assets directory. | > shader --local /path/to/shaderc | | Use local executable of glslc by pointing to a directory to look for it. Usage: -s, --webservice Use a hosted webservice to compile local *.glsl files. -l, --local Use a local executable of the glslc compiler. Specify the path to a location where shader_cli should scan for the glslc executable. Download: https://github.com/google/shaderc -c, --custom-webservice Uses a self-hosted webservice to compile *.glsl files. You can download the webservice at: https://github.com/felixblaschke/shaderc_webservice -w, --watch Watches for file system changes and automatically recompiles the *.glsl files. -p, --path Defines a directory path to scan for files to compiler. If unset, it will use current working directory. -a, --put-in-assets Places the compiled files into this project's assets directory. -d, --dart Generates Dart-file with embedded SPR-V byte code and a simple shader loading function. -h, --help Shows this help text. Updates and more information: https://pub.dev/packages/shader_cli

I am working on an engine that targets Vulkan and Metal. I'm at the point now where I want to be able to dynamically update my shader at runtime to suit the type of data being sent in for drawing. I am currently using offline compilation for my GLSL (for Vulkan) and MSL (for Metal) shaders. What are your workflows for situations like this? For those using tools like SPIR-V Cross and shaderc, what has your experience been with these tools keeping up to date with the latest features in the specs?

shaderc (https://github.com/google/shaderc) is one such shader compiler. It does the job well enough and lets us compile our GLSL shader code into the SPIR-V assembly that the graphics drivers need. However, it's written mostly in C++ and has a rather complicated build system. This means that people wanting to compile Veloren need to install a variety of extra things to get shaderc working with Veloren.

From what I can tell, both glslang/shaderc and Microsoft's DirectXShaderCompiler can compile HLSL to SPIR-V code. Is there a consensus on which of these is the better compiler? (wrt to accuracy, optimisations, feature completeness, etc.)