Address common community WGSL string interpolation cases in WESL

[mighdoll]

Community projects in WGSL (and other shader communities) typically rely on string interpolation to inject some host specific variation into shaders.

Let's enumerate the common string interpolation use cases in this issue (and make separate issues for the uncommon cases) and then document them on the spec site.

We originally planned to address these common cases by standardizing a string interpolation mechanism (see SimpleTemplating). I think the current discussions lean towards more precise language features than string insertion, but either way a clear understanding of the use cases will help validate our solutions. When we agree on spec features to address these community use cases, we can document them alongside.

[k2d222]

Some of what I have seen (mostly glsl)

• substitute a function name (similar to @link)
• concatenate identifiers, e.g. alias array${N}f = array<f32, ${N}>;
• inject a bunch of code, for example a prelude, polyfills, or imports.
• repeat N times, unroll loops or implement recursion (usually implemented with other special markers in code)
• feature flags, e.g. const my_feat: bool = ${MY_FEAT_ENABLED};
• inject cpu-precomputed math: e.g. let my_const = ${3+2}
• conditional compilation (with string injections that may be empty) e.g. ${DEBUG_BEGIN} ... some stuff ... ${DEBUG_END}
• writing metadata in the file: build date, time, file name, line number, deploy url, file hash...
• markers for parsing
• stateful injections, e.g. @bind(${i++})

[mighdoll]

pixijs: host code controlled linking via string insertion here
pixijs: aligning vert and frag @location indices here
pixijs: custom code generation for blur filter: here

[mighdoll]

nanite-webgpu

• all wgsl is inline TypeScript strings
• string insertion for numeric constants for array sizes, const values
• static module linking (via string insertion) example
• binding numbers inserted by host code

[mighdoll]

lygia

• mostly static functions
• assumes existence of an #include facility
• glsl versions use #define and possibly function overloading, wished for features in WGSL

[mighdoll]

webgpu-torch

• full custom code generation

[mighdoll]

pbmpm

• home grown include / insert

[mighdoll]

frostbitten-hair-webgpu

• wgsl in TypeScript strings
• static module insertion
• uniforms
  (ah, same author as nanite-webgpu, similar techniques)

[mighdoll]

gpu-curtains

• wgsl as js strings
• import by string insertion
• numeric constants from host

[mighdoll]

alpenglow

• the most advanced templating system I've seen for WGSL: example
• modular string templates take arguments
• code generating string templates can do loop unrolling, conditions, imports, etc.

[mighdoll]

Egrogia

• custom #include and #ifdef preprocessor
• (no runtime injection of strings or numbers AFAICT)

[mighdoll]

strahl

• wgsl in typescript strings
• import by string insertion
• no runtime injection via strings, some use of override

[mighdoll]

luma.gl

• wgsl in typescript strings
• string substitution for uniforms
• wgsl fragment insertion
• uses reflection on constructed WGSL shader to integrate with TypeScript host code
• fn name selection
• bound variable insertion?
• (probably more)

[mighdoll]

vello

• custom #import implementation
• custom #ifdef implementation
• no runtime injection of strings(?)

[mighdoll]

webgpu-particles

• a small demo with just static wgsl files

[mighdoll]

webgpu-marching-cubes

• uses WGSL override to inject e.g. SCAN_BLOCK_SIZE, WORKGROUP_SIZE
• some host controlled concatenation of wgsl files

[mighdoll]

webgpu-volume

• module linking by string concatenation

[mighdoll]

frac_gen

• custom import preprocessor

[mighdoll]

rerun

• custom import preprocessor

[mighdoll]

kmeans-gpu

• yet another custom import preprocessor

[mighdoll]

pixijs-filters

• image plugins with standard plugin uniforms and separate per plugin uniforms

[mighdoll]

cell_simulation

• custom import preprocessor

[mighdoll]

GraphWaGu

• file per shader, copy paste for struct sharing