intro to wgsl-tooling-wg

[mighdoll]

Hey, wanted to introduce our effort over in the wgsl-tooling-wg to extend WGSL with community tooling. The idea is to extend WGSL to support features like import from local files and cargo/npm packages. We're also looking to add extensions for things like conditional compilation (@if), etc.

It looks like Lygia could really use some standard tooling for import, and maybe conditional compilation.. Is there anything else Lygia would need?

[patriciogonzalezvivo]

Hi @mighdoll! Thank you for reaching out! That's a great project! I will take a deeper look to it.

yes! some import feature would be great. I went for using #include just because I saw several Rust parsers for WGSL that support include commands out of the box. It's a pretty old standard that is also adopted on all other shader languages and/or graphic engines. Of course if import becomes the standard I can change it.

Yes! some precompilation macros (defines and conditionals) would be amazing. As you can see in GLSL, HLSL and Metal, we use them extensively for templating, name collisions and back compatibility between different language version.
We also use function defines also for versioning and templating. For example https://github.com/patriciogonzalezvivo/lygia/blob/main/sampler.glsl#L10

In my wish list for WGSL I also have function overloading! It allow us to build simple and friendly interfaces.

[sdedovic]

+1 to both ideas, this looks awesome @mighdoll. Some of my thoughts:

A standard for imports / code splitting with conditional imports is much needed. An important request for WGSL extensions - they can not break vanilla code. I.e. if import or @if(xxx) statements are added to Lygia, I do not believe it should prevent the code from being used as-is with vanilla WebGPU APIs. This may mean either putting extensions inside of comments or having a new file extension, e.g. wgslx and keeping both vanilla WGPU and WGPU-ext code side-by-side. I think this is important as we should not introduce breaking changes that require third-party libraries.

---

While translating some files from GLSL to WGSL here, I ran into a few issues. Not all have solutions, but I'll enumerate anyway:

1. Function Overloading gpuweb tracking issue

I attempted to document a working pattern in function naming for method overloading, here: DESIGN.md#wgsl-specifics. At the time of writing, I was working on a GLSL -> WGSL translator, attempting to automate this process. I believe it is possible, but more generally, a way to support method overloading with a preprocessor merits investigation, in my opinion.

Example

I could not find a good solution to setting the WORLEY_DIST_FNC option in generative/worley.glsl. As the WGSL version requires two functions,
here and here, I removed this option and documented the omission.

2. Macro Arguments

Example

See the GLSL file here: generative/voronoi.glsl.

// definition
#define VORONOI_RANDOM_FNC(UV) ( 0.5 + 0.5 * sin(time + TAU * random2(UV) ) ); 

// usage
...
    vec2 point = VORONOI_RANDOM_FNC(i_uv + neighbor);
...

At the time of translating to WGSL, I omitted this option, so I would not have to impose a specific preprocessor library on users. Many do not currently support macro arguments.

[patriciogonzalezvivo]

Hi @mighdoll! Recently we had another important PR for the WGSL translation by @josephreisinger. The worked around the same constrains and limitations @sdedovic mention. I just want to introduce him to you and give him space here to make his voice and thoughts heard. Thank you all

[mighdoll]

Awesome, and welcome. Last week we presented a summary of the direction to the WebGPU team. Slides here. It included a first prototype of linking an npm wgsl package, see slide 25 or so.

I'm very much thinking of Lygia for what would be good to support in a first version of the tools. The tools are not stable yet, but it's not too soon for you to peek at the direction. The basic idea is to package the wgsl into strings with a little bit of metadata to make it easy for users to consume libraries.

Either a runtime library to link() or a build tool linker would be used to mix in imported libraries into app code. A vite/rollup bundler plugin would be nice option too.. we could use help on that.

[mighdoll]

Also check out this issue. Ideas about extending / modifying the packaging format welcomed!

[josephreisinger]

@patriciogonzalezvivo @mighdoll super exciting! Glad there is some effort to standardize around this. I'll dig into the spec materials more and see if there are some simple things I can do to align the lygia wgsl stuff a bit. also +1 to the issues that @sdedovic brought up.