Gpuweb: [wgsl] Shading language syntax and porting.

[krogovin]

This issue is to raise awareness on how different WSL is from all the platform high level shading languages (GLSL, HLSL, Metal Shading Language). From the point of view of a developer, if I have something running on native, the effort to get it to the web via WebGPU is now so much greater. Indeed, API calls can often be abstracted (and in truth there is a common nature for much of it across the API's), but now the nature of shaders is a giant can of worms. The syntax is not even close, so one cannot hope to hide the differences behind #define's and #ifdef's. It is just utterly different to just declare a function.

Yet, one of the goals of the shading language is that it is easily translatable to SPIR-V, with the spec almost exposing SPIR-V already and the very scary "While we recognize that most Vulkan devices will not support VulkanMemoryModel we expect the SPIR-V generated to be converted by SPIRV-Tools after the fact to make the shader compatible".

I can understand not wanting to use SPIR-V as the shading language, but making the syntax of WSL soo different than the others will incur additional burden to move native applications to web. The shader burden, for me, cannot be understated as I am looking at a project with literally thousands of lines of shader code along with a run-time assembly of shaders.

The ask is this: can the syntax be more line with others OR the W3C releases with the WebGPU spec a set of libraries (preferably as WASM modules) that converts/compiles/something the already existent shading languages into WSL?

[Kangz]

WSL

The name is WGSL for Web GPU Shading Language. WSL is a former proposal from Apple.

The ask is this: can the syntax be more line with others OR the W3C releases with the WebGPU spec a set of libraries (preferably as WASM modules) that converts/compiles/something the already existent shading languages into WSL?

It's unlikely that the W3C group itself will produce translators libraries. However Tint, Chromium's future WGSL compiler and Naga, Firefox's future WGSL compiler, are both looking at having a SPIR-V input and WGSL output.

This would make same usable SPIR-V -> WGSL compiler and you could use any toolchain you want to go to SPIR-V. For GLSL in particular there's been some discussion of making a direct GLSL -> WGSL compiler, but no concrete plan yet.

[krogovin]

Any movement on making the shading language less different than other, already existing, 3D API shading languages?

[magcius]

The current charter makes it difficult, if not impossible, for the WG to produce or maintain software or tooling. This is unfortunate. One of the biggest wins in Vulkan was changing the structure of Khronos to allow for the Vulkan WG to officially support & recommend tooling, and make sure it was at a decent quality level, cross-checked with all IHVs.

The process to get there was messy, but it's way, waaay better than the era of OpenGL. Modern graphics APIs need tooling. I would like for the charter to be changed so that the WG can recommend & support tooling, or, if not, a thorough explanation for why WebGPU has no official tooling.

[grorg]

Our charter does allow us to produce tooling.

[grorg]

I'm going to close this issue considering we're now well on the way to specifying WGSL.

For tooling, as was mentioned, Tint will likely be able to translate to and from SPIR-V. Other tools will come too. We could consider making a wasm library to translate GLSL on the client.