MVP Task List

[stefnotch]

Introduction

We are building a minimal version of WESL, to let our first users enjoy a modular shading language along with IDE tooling! In this version, we're limiting ourselves to the bare necessities, and are prioritizing the most common use-cases. If you need a feature, let us know. Or even better, join in and help us ship this sooner.

We invite everyone to come and help out! There's a lot to do, from setting up a web documentation to extending language servers.

Tasklist

Sorted in order of importance

• 1 working WESL linker
  • Rust linker
  • JS linker (@mighdoll and @stefnotch )
• Features
  • Imports
    • Spec (@stefnotch )
  • Conditional compilation
  • Out of scope: wesl.toml
  • Injecting code: Overrides are enough for now. (@k2d222 Please double-check)
  • Mangling and host code exposing: Linker specific for now
  • Stretch goal: Super basic "provide string to linker - aka library"
• Documentation like gleam - start with GitHub wiki (@stefnotch )
  • Super basic intro
  • Demo page
  • Language tour/Reference
  • Stretch goal: Cheatsheet
  • Installation guide
• IDE Tooling:
  • Syntax highlighting
  • Language Server
    • Depends on: Spec, linker implementation, test code
  • Stretch goal: Tree-sitter grammar

[stefnotch]

@ncthbrt Does this sound good?

[ncthbrt]

That seems good. Though how does the language server work without a manifest for modules? Just thinking about bevy's use case

[stefnotch]

@ncthbrt Really good question. My thoughts are

In the first round, they'll just use their existing heuristics to find files. (e.g. Only analyze the open file)
After we got that to work, we introduce the wesl.toml configuration for language servers.

And after the MVP, we can fully standardise it and make it part of what linkers understand.

I wanted to break it up into smaller steps, because just getting language servers to accept wesl syntax at all might be quite a lot of effort.
And at every step, we at least have something better than the status quo for Bevy.

[ncthbrt]

While that makes sense, it is a bit unfortunate as this immediately rules out bevy as an initial consumer unless we somehow special case it.

[stefnotch]

Right, a language server couldn't resolve import bevy_pbr::some::absolute::path without a wesl.toml.

Well, time for me to write up a minimal wesl.toml proposal for language servers.

Is there anything else that Bevy needs?

[ncthbrt]

Conditional compilation for sure. And the ability to import bindings are a must. The ability to integrate with the asset loader system is also important. The loader uses the asset path to determine what asset loader and asset source to use. But bevy also uses the module name directive in the source to locate a module from within a shader once it _was_ loaded. So that needs to be solved.

…

On Thu, 10 Oct 2024 at 12:09, stefnotch ***@***.***> wrote: Right, a language server couldn't resolve import bevy_pbr::some::absolute::path without a wesl.toml. The Well, time for me to write up a minimal wesl.toml proposal for language servers. Is there anything else that Bevy needs? — Reply to this email directly, view it on GitHub <#54 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCJEWIPSF3I4QMCJK6KCQDZ2ZG4BAVCNFSM6AAAAABPVBZNECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBUGY3DIOBXGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[k2d222]

[x] Injecting code: Overrides are enough for now. (@k2d222 Please double-check)

The situations in the WGSL spec where overrides are not allowed but constants are:

• the element count of a fixed-size array (EXCEPT that the outermost array's element count of a var may be an override)
• case selector expressions
• @align, @binding, @blend_src, @group, @id, @location, @SiZe (interestingly, NOT @workgroup_size which can accept overrides).
• the component and offset parameters of textureGather* and textureSample* functions
• naturally, const-declarations and const-assertions.

So, it seems it's still the case that arrays sizes must be const-expressions. except that one edge case.

Still, I'm checking that mark anyways. Linker implementations will always be free to override an import (which is the trick I used in my personal project) which allows injecting arbitrary code. It does not have to be part of the WESL standard for now. For libraries, they cannot use this non-standard extension and would therefore have to abstain themselves from hitting one of these edge-cases.

[stefnotch]

@k2d222 Thank you very much! And good to know what the workaround is, and what limitations it comes with. I suppose we'll have to address it in a future version. :)

[mighdoll]

this vscode doc left me a little confused about the need for tree-sitter. It seems to suggest that a language server is all you need, but I'm not sure if I'm reading it correctly..

[mighdoll]

Since we're inviting more people to review this issue, I'd suggest we add a brief intro above the task list, defining the MVP, its goals and context with our work.

[mighdoll]

Since override isn't enough, ought have something in as a stretch goal feature in for MVP? It seems possible if we want it e.g. for bevy or other key early projects.

@k2d222 your demo showed we could generate new const elements from a link() api. That might be enough.

If we think an MVP language server might complain unless we rewrite elements that are already in the WGSL, we could do that with e.g. your unitialized consts proposal. (And for MVP, I suppose we could just make these global, e.g. not worry about package or module namespacing).

[ncthbrt]

This is mostly bikeshedding but I'm somewhat against the syntax of link rather than the idea in principle.