Improve WgslShaderGenerator to generate actual `wgsl` source

[ashwinbhat]

WgslShaderGenerator doesn't actually produce wgsl, but just an adapted variant of glsl that is suitable for conversion to wgsl. For real-time web environments this workflow from MaterialX -> GLSL -> SPIRV -> wglsl is not performant. We should investigate in a direct wgsl generator.

I've logged this issue to get feedback from community about their thoughts and ideas in this area.

[ld-kerley]

I think this is a really good idea, and something we should lean in to across all the languages. Delivering native code tuned to be as performant as possible to the different destination implementations seems like a good mission statement for the project.

[thc1006]

I can't agree with u more!!! and I’m also interested in helping with this.

From the docs it looks like WgslShaderGenerator is currently a WGSL-flavored Vulkan GLSL generator (i.e., intended for conversion), which matches the issue description. (MaterialX)

To scope this properly, might need to clarify some acceptance criteria?

1. Target stages: fragment-only first, or full vertex+fragment (and compute?)
2. Require node coverage for "done": e.g., Minimal set needed to render MaterialX Viewer / Web Viewer sample graphs.
3. Binding layout expectations: should the generator emit fix @group/@binding convention (and which ones) or expose reflection metadata for the app to build bind groups? (WebGPU/WGSL uses group+binding as the core model. (W3C)
4. Preferred compilation path for validation: direct WGSL compile in WebGPU, or still allowing an intermediate toolchain for tests?

[aviralgarg05]

I would like to solve the issue, please assign me

[thc1006]

I would like to solve the issue, please assign me

Dear @aviralgarg05 , I think this issue need more discuss, maybe u can share ur fixing way and tag the Moderator ask idea.

[ashwinbhat]

The scope would be fragment and vertex shaders, basically implementing a full class WgSlShaderGenerator : public HwShaderGenerator

A native wgsl generator would be more performant, easy to read and could be tuned as needed. Similar to genglsl we would have genwgsl with wgsl implementation for many of the fragments.

Now this would be another maintenance overhead since for every new node we would need glsl, osl, msl, mdl, slang and wgsl

Depending on AI policy we could try to use AI assisted translation to convert the glsl fragments to wgsl, but with Human in the middle to ensure the translation is correct.

Our glsl nodes use a lot of overrides e.g.

vec2 mx_matrix_mul(vec2 v, mat2 m) { return v * m; }
vec3 mx_matrix_mul(vec3 v, mat3 m) { return v * m; }
vec4 mx_matrix_mul(vec4 v, mat4 m) { return v * m; }
vec2 mx_matrix_mul(mat2 m, vec2 v) { return m * v; }
vec3 mx_matrix_mul(mat3 m, vec3 v) { return m * v; }
vec4 mx_matrix_mul(mat4 m, vec4 v) { return m * v; }
mat2 mx_matrix_mul(mat2 m1, mat2 m2) { return m1 * m2; }
mat3 mx_matrix_mul(mat3 m1, mat3 m2) { return m1 * m2; }
mat4 mx_matrix_mul(mat4 m1, mat4 m2) { return m1 * m2; }

For wgsl we would use the native support.

On the other hand these glsl functions:

float mx_square(float x)
{
    return x*x;
}

vec2 mx_square(vec2 x)
{
    return x*x;
}

vec3 mx_square(vec3 x)
{
    return x*x;
}

would become with the type in the name qualifier.

fn mx_square_f32(x: f32) -> f32 {
    return (x * x);
}

fn mx_square_vec2(x: vec2<f32>) -> vec2<f32> {
    return (x * x);
}

fn mx_square_vec3(x: vec3<f32>) -> vec3<f32> {
    return (x * x);
}

[ashwinbhat]

The current MaterialX Web Viewer uses three.js. If three.js can support raw wgsl shader, that could be good or we might need to look at other WebGPU frameworks.

[ashwinbhat]

Here is a more updated PR #2996