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.