search

wgsl-tooling-wg / wesl-spec

A set of well-specified language extensions and tools for WGSL
BSD 3-Clause "New" or "Revised" License
6 stars 2 forks source link

bound variables in packages #41

Open mighdoll opened 4 hours ago

mighdoll commented 4 hours ago

It's pretty clear that we don't want to a wesl utility package published on npm/cargo to write:

@group(0) @binding(1) var<storage, read> src: array<f32>;

because the package is in no position to know what group and binding indices to use. The application wesl or even better the application host code is in a better position to provide the binding numbers.

So what should users write for bound variables in packages?

ncthbrt commented 4 hours ago

My thoughts around this were that either generics or the wesl manifest file could specify a binding offset for libs and the libs could specify a range so you can calculate the next offset?

mighdoll commented 4 hours ago

one approach suggested elsewhere is to expect packages to use names for the indices, e.g.

@group(FooGroup) @binding(FooBinding) var<storage, read> src: array<f32>;

And then the binding problem becomes similar to other known problems we expect to solve for host visible names in packages (entry points, overrides).