Some Thoughts on Bevy WGSL

[cart]

I will make some assertions:

1. Baseline WGSL is missing functionality that use cases like Bevy require (a module / import system, abstractions to support extendible templates/materials, etc). We have already built some of this, and we will continue to do so.
2. There are no suitable existing specifications / implementations of this in the ecosystem that we can latch on to.
3. To support these things, we need to break baseline WGSL syntax, which in turn breaks baseline WGSL tooling
4. It is therefore on us to provide (a) a specification of these changes (b) an implementation (c) developer tooling
5. It is in everyone's best interest if we build something that is generically useful / "best fit" for projects outside of Bevy, as that will encourage an ecosystem to develop, and it may even give us enough political capital to drive changes to upstream WGSL.

We have already embraced this world, by nature of adding import and virtual function syntax to WGSL. I think we should do it more fully:

1. We've relied on preprocessor macro syntax in some cases in the interest of compatibility with WGSL tooling. Given that this is a battle we have already lost, we should revisit this choice. We should still use macro syntax where it is appropriate (ex: working with shader defs). But for true language extensions, we should embrace nicer / first class syntax. For example: #import a::b::c should become an actual language keyword use a::b::c;
2. We should define clear rules for how we extend WGSL. Ex: "always be additive ... it is ok to define a new keyword, it is not ok to redefine an existing one", "don't break valid core WGSL expressions", etc.
3. When designing new features, we should ask ourselves "is this what someone building the general purpose Extended WGSL Ecosystem would do".
4. We should define a grammar for Bevy WGSL and maintain a TextMate grammar for it, in the interest of providing better IDE support.
5. We should provide Bevy WGSL tooling that works independently of upstream Bevy (ex: a Bevy WGSL -> WGSL compiler, a language server, etc)
6. We should give a name to Bevy WGSL that is more palatable to non-Bevy consumers.

[Froidoh]

Why not rust gpu?

[cart]

1. Bevy shaders have many variants that in many cases cannot be compiled ahead of time. This means that we need to be able to deploy the Bevy shader compiler with Bevy apps. Deploying the Rust compiler with Bevy games is (1) not possible at all on some platforms (2) not compelling on the platforms that it is possible on, as a Rust install is hundreds of megabytes
2. Rust GPU requires a (very specific) nightly version of Rust. This makes it impossible to build Bevy games using just a stable Rust compiler.
3. Setting up Rust GPU requires manual nontrivial steps from developers, making it harder for new developers to get started with Bevy. Bevy really needs to work "out of the box" with a standard stable Rust install.
4. Rust GPU is still unstable / in flux / the future is a bit uncertain. I personally have high hopes for it and the future does look bright.

I do want Bevy to support Rust GPU shaders, but I haven't yet seen how it could fill the niche we need our default shader compiler to fill. I'm reasonably confident that 2-4 will resolve themselves eventually. But (1) is a pretty significant blocker from my perspective.

[tychedelia]

I do want Bevy to support Rust GPU shaders

We technically already do, as you can pass raw spir-v as a shader source.

[mighdoll]

non-Bevy consumers.

I’d be interested in helping to standardize a set of wgsl extension and supporting them for the javascript community. (I wrote the TypeScript wgsl linker.) Sounds like this is a nice moment to build some bridges between the javascript and rust sides of the wgsl ecosystem.

What are the extension features of interest?
. import / export
. packaging (npm, crates)
. visibility control (public vs. private, re-exporting)
. generics
. conditional compilation (#if)
. variable substitution (#define)
. virtual functions
. struct inheritance (extends)
. runtime linking (e.g. in the browser)

A few others (led by @stefnotch, @k2d222, @dannymcgee) have also been working towards a clean set of wgsl extensions and associated vscode tooling. That discussion has moved to a new discord server here: WebGPU tooling.

[cart]

Thanks for the heads up! I do like the idea of having a centralized placed to spec these things out. Can't promise we'll be able to adopt what gets built there, but we should at least give it a shot!

[cart]

A this point we're most interested in:

• imports
• conditional compilation
• variable substitution
• virtual functions

imports are likely to be the most immediate clash, as we're interfacing with the bevy asset system (and a "shader module" system) that we need to be compatible with.

[eidloi]

My main issue with shader writing currently is tooling. wsgl-analyzer is already halfway there to support an okay experience, though it is unmaintained at the moment. It supports auto formatting and imports if it is given a settings file. A good first step could be to touch up this extension and maybe export / generate a config file from bevy each release. This, a good example of how to set up hot reload for shaders, and a brows-able doc for supported shader fns would probably cover 95% of developer pain.

The point here is that if we have an extension that is tailored to Bevy, adding new syntax wouldn't be too much of an issue and everyone could benefit from the improvements immediately. This in turn would allow the syntax to grow independently of the standard and we could propose most common / useful things from our side once based on experience rather than theory.