Is it possible to code material shaders using nothing but Rust proper?

[crabdancing]

As it stands, all the material shader example code I've looked at uses .wgsl at somepoint. I'm curious where the syntax of these files comes from, because it seems like a strange mix of Rust-like syntax, mixed with C, which seems to be compiled/interpreted as a resource (potentially hot-reloaded) when the app launches. This makes me wonder: is it possible to compile material shaders in pure Rust for Bevy?

If it's not, I'm also very curious as to why. A lot of shader code seems to be distributed as if it's a script, despite being a compiled C-like language. The Rust compiler is bigger and more complicated, but it still seems like it should be possible to embed the binary code as an asset instead of compiling on the fly.

It also seems a shame, as rust-analyzer can't analyze wgsl files before compilation.

[nicopap]

WGSL is a programming language for shaders. It was designed for WebGPU under the umbrella of the W3C, by engineers from Google, Mozilla and Apple.

The best place to learn about WGSL right now is the standard draft: https://gpuweb.github.io/gpuweb/wgsl/#intro

Code running on GPU (graphic processing unit) has different constraints than code running on CPU (Central processing unit). Code running on GPU is called "shader", it has a different binary representation than code running on CPU, due to the drastic difference in architecture. You can't¹ just compile rust code and run it on GPU. The WebGPU standard, and by extension, the graphics library bevy uses, named wgpu², specify WGSL as a mandatory supported shader language, so this is what bevy use.

But IIRC the same standard specifies that WebGPU should support SpirV³.

The WGSL syntax is pretty bad, but definitively better than its predecessors. The #import and #define instructions are not part of WGSL, they are special syntax added by naga_oil. wgpu itself only accepts whole files, so either we use massively large files, or use some sort of pre-processor to put them together. naga_oil basically copy/cut/paste code across every WGSL files.

WGSL analyzer

There is a VSCode plugin that adds a language server for WGSL files that use the naga_oil syntax. It is WGSL analyzer. It is specifically designed with bevy in mind. It's not as fully-featured as rust analyzer, but it's a pretty good start.

Hot reloading

WGSL code is different from rust code, in that bevy consider WGSL shaders as "assets". Which means, you can launch your game, run it, see the result of your shader, modify the file, save it, and bevy will reload the shader and you'll immediately see the changed shader. This is very different from rust code, where you have to close the game, recompile it, and re-open it.

Hot reloading enables you to see the result of your shader changes in a fraction of the time it would make to just type-check your game.

Rust-GPU

There is a project spear-headed by Embark that aims to bring Rust to the GPU. It is rust-gpu Some serious people are working on it, but it's still pretty much a prototype. You could theoretically use rust for your shaders, but rust-gpu has serious limitations such as very slow compile times.

Footnotes

1. Well actually this is a lie. Nothing prevents you from trying, but you would need to rewrite a large chunk of C++ and Rust. ↩

2. Do not confuse WebGPU and wgpu. WebGPU is a web standard, while wgpu is a rust crate implementing this standard. ↩

3. SpirV is the equivalent of assembly for GPUs. GPUs do not run the same instruction sets as your CPU (x86_64 or ARM), GPU runs their own custom instruction sets, SpirV is not a GPU instruction set, but is a common standard that can be translate to modern GPU's instruction sets by modern graphic drivers. ↩

[crabdancing]

Thank you for the in-depth answer! :D It's actually kinda fascinating that the WGSL syntax actually resembles a version of Rust that survived some sort of horrible accident. I wonder who was involved in making it. I thought originally that there was some connection to the Rust toolchain involved in that, but it seems to be actually completely unrelated?

I had no idea about wsgl-analyzer! That should make my workflow a lot easier. It actually looks like Helix has support for it as well, which is great for me. :3

I actually also have a few follow up questions, if you don't mind. For one thing, the way shaders are handled as assets during runtime, kind of implies that the wsgl compiler is somehow embedded into the Rust binary, and then is running in the background during initialization. Or at least, this is the impression I'm getting. Is this correct? Where can I learn more about this? (I'm comfortable reading Bevy's source, if you wanna point me there, BTW!)

I'm also curious about possible exploits, if a nontrivial shader turns out to have a memory bug. Since compute shaders are a thing, it seems like it ought to be possible for a memory exploit in the GPU to lead to the CPU being compromised. I'm not sure what sort of threat model I should have for high-security applications that make use of shader technology.

[nicopap]

Yep — well — for native builds the WGSL compiler is part of the naga crate, which itself is a dependency of wgpu. For web builds that use WebGPU (this is off by default, since only chrome ships with WebGPU today), the WGSL compiler is removed from wgpu, since wgpu will directly use the browser WebGPU API¹.

Though, in the future, you will likely ship bevy games without the WGSL compiler. WGSL files can be translated to SpirV, and the SpirV can be directly fed to the GPU driver, so no compilation required. The compilation can run on the developer's computer using the newly added asset pre-processing system.

The WebGPU standard has a section on risks and potential malicious uses so you can add that to your reading list.

Footnotes

1. The Firefox WebGPU implementation² will use wgpu, so wgpu will use the WebGPU API, which itself will use the wgpu native implementation 🤯 ↩

2. The Mozilla devs working on Firefox's WebGPU did use the bevy examples to validate their implementation ↩

[crabdancing]

Thanks for the info! :)

[crabdancing]

The Firefox WebGPU implementation2 will use wgpu, so wgpu will use the WebGPU API, which itself will use the wgpu native implementation 🤯 ↩

That's actually very cool. :O Recursive abstraction layer.