MEETING AGENDA

Meeting scheduled time:

San Francisco, California, USA: Thu Sep 19, 08:00 / 8:00 am
Bergen, Norway: Thu Sep 19, 17:00 / 5:00 pm
GMT+9: Fri Sep 20, 00:00 / 12:00 am

10m
personal hellos, catch up.

15m
Adoption - What will make people want to use wesl?
Recruiting / Advertising / Marketing - What should we do next?
Libraries - What wesl libraries would we like / expect to see? What shader libraries are important in other shader communities?

1hr
Github Issues perhaps ripe to discuss:
(Feel free to add more to the list, we’ll cover whatever we have time for)
#5 Edition Declaration
#21 Deal with copies of a library
#1 Entrypoints Mangling
#33 Import syntax - Revise or Revisit? - is this ripe to discuss? Please add to the issue.
#25 import should be able to address namespaces / submodules within a file

Implementations - What do prototype implementations need? Sharing test cases? Collect vanilla wgsl test cases?

Meet again?

MEETING NOTES

M: mighdoll
N: nathalie Cuthbert
S: sternotch
K: k2d222/Mathis Brossier
U: unconed

#1 Adoption

M: what makes wesl be adopted?
N: solve the users problem very well => pinpoint the real-world user issues => then expand more and more
S: uses cases: bevy, my master thesis, (K: Agreed)
S: we need a langserver => people just want a lang server that works!
M: libraries are really important +> they are a multiplier for wesl. If a great lib exists for wesl, ppl want to adopt wesl.
N: an advanced particle system is a good use-case that needs complex language constructs and robust libraries (aka wesl)
K: it should probably be integrated with a cpu-side library
M: lib ideas: what nvidia/amd offer is a good source of popular ideas. Mostly math libraries
S+N+M: fxaa, smaa, … color conversion. Gamma to linear. Rng, perlin noise, …
M: Cub: parallel alg lib https://docs.nvidia.com/cuda/cub/index.html => was the idea behind stoneberry
N+M: use case is datavis? No, mostly general purpose algorithms, i.e. a kind of stdlib library
M: super optimized efficient algorithms that bring fancy features for free for the end users
S: a “stdlib” will emerge naturally and perhaps become a de-facto standard?
M: this can only be achieved if we have a great packaging/distribution system
N: debugging is a big thing too. Wgsl is not a great experience for now. => how do we not make it worse for ppl, by adding abstractions?
https://github.com/gpuweb/gpuweb/issues/4844

#2 Recruiting/advertising

M: which communities should we reach out to?
K: should we reach out to these ppl => https://docs.google.com/document/d/1HO8Cx7RL2ExnQ_2bInX4RE-OyRTFlHyfsfMDI35haes/edit
M: visgl super helpful, babylon did not react at all
K: we may have a website some day for hosting the docs
M: we need a weasel mascot

N: a good documentation and SEO goes a long way for visibility. We want the spec, BUT also a good user-facing documentation.
Nth: at bevy this project seems a bit opaque for now, if we want to decide whether we (bevy) want to move to it we need good documentation.
N: look at some of the prog langs out there (go, rust, etc.) documenting in a friendly way goes a long way.
Nth: the Gleam cheatsheet is awesome for different user targets.
K: Too early to write the full doc because we are not decided. Good code examples are self-explanatory.
M: some of the nice docs we can do before we have decided the specifics of generics etc. There’s some higher level docs we can do now.

#5 Edition Declaration

K: editions: very important for packaging, but optional features could be supported by the compilers for user final code
M: what should be definitely not part of wesl, what may be part of it?
N+S+M: semver: in rust all editions are compatible in some way. Scary amount of backward compat burden. Rust is smarter because it notices older constructs and runs with the older edition in this case?
M: experimental features: the trick is wider tool support, because it becomes an implementation and adoption burden.
N: some langs have basically 1 reference implementation. But we have multiple (at least js / compiled). => should we have each project be responsible with their own branding and say whatever features they support?
S: rust does it nightly features, or newer versions of the compiler. If you use a too old version of the compiler it doesn’t compile. => editions are baselines and implementations add stuff on top of it progressively.
M: I wish it was easy to make new features not break the other tools (e.g. langserver).
K: https://discord.com/channels/1275293995152703488/1275293995152703491/1285200713994997892
Nth: I think wesl implementations should be a standard and not have ppl fork away and fragment the ecosystem
M: lots of compromises, we agree on a version and feel good about it.

<unconed just hopped in the call>
M: unconed is years ahead of everyone!
U: I learned my mistakes trying stuff out in glsl

S: argument for the editions: wgsl is gonna evolve, so current semantics are bound to evolve
Nth: js does not have editions and it’s a mess!
M: we need to come up with a way to describe optional extensions.

#21 Deal with copies of a library

S: if libraries can have pipeline-overridable constants, then a library consumer don’t want to expose the pipeline-constant to the outside.

S: we want libraries to not expose side-effects, but consumers decide what the declaration is: an overridable, a variable, const etc.
S: This works with multiple versions of the libraries.
N: if we specialize a generic module it gets generated twice. Same if there is two dependencies of incompatible versions.

U: i used structured hashes (hashing the generated code)
M+S: it needs to be tested. But this is roughly what we want.

#1 Entrypoints Mangling

N: not mangling the global namespace, but mangle anything that is not visible in the global namespace.
M: we explicitly bring the name in, that is deciding to expose that name to the host.
M: we agree that we need a way to expose names to the host (probably a syntax.)

#33 Import syntax - Revise or Revisit?

<side quest>
S: we need a syntax to specialize a module import.

K: similar to the generic modules proposal https://github.com/wgsl-tooling-wg/wesl-spec/blob/dfc0459d6ec0713d4e7e2ae67007c2f1b5a46834/Generics.md#generic-modules
</end side quest>

M: filenames are nice, why do we want module names?? When we import, do we import based on the file name or a module declaration?
N+Nth: it’s an adjacent concern. Bevy ppl prefer symbolic modules. Filesystem is a high assumption. You don’t know how the runtime is knowledgeable about the filesystem.
M: we can have both filenames and explicit modules live together.
U: in shader word we tend to use only a small function from an imported library. So for consumers, the npm package has many tiny wgsl files and you import only one of these files.
N: concerns: implementation difficulty e.g. inline, nested modules are useful for grouping but the impl detail are tricky. But scoping culd allow you to merge files with no effort. You can also alias a specific lib name as the common lib name.
M: if we imagine that we can import from implicit modules (filesystem), but it is also a virtual filesystem, does it break anything?
N: confusing for users because there’s two concepts living together. (implicit + explicit).
K: rust does this and it works in practice, not too confusing
M: if we can extend the file hierarchy, it’s a good way forward: good defaults and extensions possibilities.
K: it can be declared in the wesl.json https://discord.com/channels/1275293995152703488/1275318205530898503/1285198630470549534

M: Logical file system with possibility to add virtual modules is worth exploring
S: We should revisit this issue whether we want to express bevy::util::pbr::yadiyada

S: import bevy::pbr::lightning::utils::foo; => how do we resolve to foo?
<we have to end the meeting, remains to be discussed>

#25 import should be able to address namespaces / submodules within a file

Next meeting: in 3 weeks around oct-10
We’ll do a mailing list and provide a ics calendar invite.

Emails

[redacted]