WebGPU Viewer

[ashwinbhat]

• Reorganize GLSL based shader generators into sub folders.

• Update WGSL shader generator to replace GLSL with wgsl. Introduce GlslToWgsl helper that works with binding context and syntax support.

Add a WebGPU rendering path alongside the existing WebGL one.
The viewer generates WGSL WgslShaderGenerator and routes it to Three.js TSL NodeMaterial.

• mxtsladapter.js: mtlx WGSL -> TSL bridge
• wgslmanifest.js: reflection manifest for wgsl shader

This work is towards these issues:
#2558
#2751

[jstone-lucasfilm]

Hello @ashwinbhat!

I'm really happy to see these steps forward for WebGPU support, which has long been a goal for MaterialX. I have some questions, though, that I think are worth working through before we commit to a direction, mostly about the scope of the PR and the long-term shape of the WGSL path:

1. Could this be split into smaller PRs? As it stands it bundles three fairly independent changes: (a) the essl, vk, and wgsl folder reorganization, (b) the new WGSL generator with GLSL -> WGSL converter, and (c) the JS viewer's WebGPU/TSL path. At roughly 7k lines they're hard to review as a unit, and the converter, which requires the greatest care in review, is the easiest to lose in the noise. Would it make sense to propose these separately?
2. Can you clarify the goals that the folder reorganization addresses? All of our sibling generator modules use a flat, prefix-named layout, so we'd need a strong motivation for making changes to the layout of this one. These are also installed public headers, so moving them is potentially a breaking change for downstream clients. Is the reorganization needed beyond giving the new converter a home? If the converter lived flat (e.g. WgslGlslConverter.cpp), would any restructuring be required at all?
3. Could the bespoke transpiler be replaced by a production compiler, integrated as an optional dependency for builds that require WebGPU support? GlslToWgsl.cpp is roughly 3,800 lines of string rewriting over machine-generated GLSL, plus eight whole-shader post-passes. It's impressive work, but it's a bespoke transpiler that the MaterialX project would own and maintain indefinitely, and it can break silently as our codebase evolves. Production compilers already do this job, with the added benefit that their output is valid WGSL by construction -- correctness is guaranteed, with no separate validation step to build or maintain. Two possible options are Tint and Naga, each with its own tradeoffs. Have you evaluated either, and what led you to the bespoke approach?

[ashwinbhat]

Hello @ashwinbhat!

I'm really happy to see these steps forward for WebGPU support, which has long been a goal for MaterialX. I have some questions, though, that I think are worth working through before we commit to a direction, mostly about the scope of the PR and the long-term shape of the WGSL path:

1. Could this be split into smaller PRs? As it stands it bundles three fairly independent changes: (a) the essl, vk, and wgsl folder reorganization, (b) the new WGSL generator with GLSL -> WGSL converter, and (c) the JS viewer's WebGPU/TSL path. At roughly 7k lines they're hard to review as a unit, and the converter, which requires the greatest care in review, is the easiest to lose in the noise. Would it make sense to propose these separately?
2. Can you clarify the goals that the folder reorganization addresses? All of our sibling generator modules use a flat, prefix-named layout, so we'd need a strong motivation for making changes to the layout of this one. These are also installed public headers, so moving them is potentially a breaking change for downstream clients. Is the reorganization needed beyond giving the new converter a home? If the converter lived flat (e.g. WgslGlslConverter.cpp), would any restructuring be required at all?
3. Could the bespoke transpiler be replaced by a production compiler, integrated as an optional dependency for builds that require WebGPU support? GlslToWgsl.cpp is roughly 3,800 lines of string rewriting over machine-generated GLSL, plus eight whole-shader post-passes. It's impressive work, but it's a bespoke transpiler that the MaterialX project would own and maintain indefinitely, and it can break silently as our codebase evolves. Production compilers already do this job, with the added benefit that their output is valid WGSL by construction -- correctness is guaranteed, with no separate validation step to build or maintain. Two possible options are Tint and Naga, each with its own tradeoffs. Have you evaluated either, and what led you to the bespoke approach?

Hi @jstone-lucasfilm

Thanks for taking an initial look, it was draft PR to get some early input and possible more interested contributors 😉
It can certainly be split-up.

The folder reorganization is independent from WebGPU and can be split up into a separate PR. The reorg is mainly for clarity while working with the code. Unlike other sibling generators, GLSL generator is getting extended to multiple targets. I found this a little confusing while onboarding new developers, and I think reorganizing will be helpful though not required.

Regarding the bespoke transpiler for wgsl, I have the same concerns as you do and I would like to seek input from community.
The core issues we need to address are:

• shader readability: current transpiler options such as Tint and Naga, generate source that is very verbose, hard to read and without comments. This cause issues debugging the shader to diagnose issues and further customization.
• compile time: the current pipeline we offer is:
  mtlx -> glsl -> spirv (IR) -> wgsl -> [browser] -> spirv (or proprietary IR) -> binary -> driver
  by using a direct wglsl generator (either custom transpile or with a WGSL shadergen) we can reduce it to
  mtlx -> wgsl -> [browser] -> spirv (or proprietary IR) -> binary -> driver

I'll continue to explore other options that might be more acceptable and meet our desired goals.