You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've floated various ideas for what a vite plugin might do. Let's prototype some of them to explore what's possible. Here are a few ideas:
Produce WGSL Reflection info
Use the linker to parse the source code and produce some TypeScript descriptors of the WGSL code. Things like the names of entry points, and the shape of certain struct elements would be useful for to have in TypeScript. Consider whether to imitate wgsl_reflect format in reporting.
Inject Structs into WESL
Convert some TypeScript structs into their equivalent WGSL structs and generate a WGSL file that WESL users can import.
Produce Auto-Layout
Parse WGSL and generate a GPUPipelineLayout as requested by the WebGPU team. See notes and #4957
Collect WGSL Files
Currently the linker expects that the user collect a set of named shader strings into a Record and pass that Record to the linker. But the list of shader files can be found elsewhere, probably wesl.toml will have the same glob search pattern (so language servers can find the files).
For example, the user might do something like this to collect the shader strings in the common case that they're using vite as a bundler:
Can a vite plugin read wesl.toml and inject the shader source Record into the .js. That would make this code unnecessary and the programmer wouldn't have to maintain duplicate glob search strings in two locations.
The text was updated successfully, but these errors were encountered:
Marking as M1 for the collect wesl files variant. Packaging the user files w/o a plugin will be possible, but it's error prone. A plugin will smooth the first experience for users.
The recent work with unplugin and binding structs plugins shows most of the work needed.
?link is now available in the vite plugin for collecting files. I think this will be the recommended approach for most people to build with wesl-js.
These experimental build extensions are also available: ?simple_reflection - generates both javascript and typescript (.d.ts) descriptions of wgsl structs ?bindingLayout - generates javascript BindingGroupLayoutEntry objects for #4957 style binding structs.
Injection of structs into wgsl is now also available via the virtualLibs option to link().
We've floated various ideas for what a vite plugin might do. Let's prototype some of them to explore what's possible. Here are a few ideas:
Produce WGSL Reflection info
Use the linker to parse the source code and produce some TypeScript descriptors of the WGSL code. Things like the names of entry points, and the shape of certain
struct
elements would be useful for to have in TypeScript. Consider whether to imitate wgsl_reflect format in reporting.Inject Structs into WESL
Convert some TypeScript structs into their equivalent WGSL structs and generate a WGSL file that WESL users can
import
.Produce Auto-Layout
Parse WGSL and generate a GPUPipelineLayout as requested by the WebGPU team. See notes and #4957
Collect WGSL Files
Currently the linker expects that the user collect a set of named shader strings into a Record and pass that Record to the linker. But the list of shader files can be found elsewhere, probably
wesl.toml
will have the same glob search pattern (so language servers can find the files).For example, the user might do something like this to collect the shader strings in the common case that they're using vite as a bundler:
Can a vite plugin read
wesl.toml
and inject the shader source Record into the .js. That would make this code unnecessary and the programmer wouldn't have to maintain duplicate glob search strings in two locations.The text was updated successfully, but these errors were encountered: