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.