This crate provides an EDSL to build shaders, leveraging the Rust compiler (rustc) and its type system to ensure
soundness and typing. Because shaders are written in Rust, this crate is completely language agnostic: it can in theory
target any shading language – the current tier-1 language being GLSL. The EDSL allows to statically type shaders
while still generating the actual shading code at runtime.
In typical graphics libraries and engines, shaders are opaque strings – either hard-coded in the program, read from a file at runtime, constructed via fragments of strings concatenated with each others, etc. The strings are passed to the graphics drivers, which will compile and link the code at runtime. It is the responsibility of the runtime (i.e. the graphics library, engine or the application) to check for errors and react correctly. Shading languages can also be compiled off-line, and their bytecode is then used at runtime (c.f. SPIR-V).
For a lot of people, this has proven okay for decades and even allowed live coding: because the shading code is loaded at runtime, it is possible to re-load, re-compile and re-link it every time a change happens. However, this comes with a non-negligible drawbacks:
- The shading code is often checked either at runtime. In this case, ill-written shaders won’t be visible by programmers until the runtime is executed and the GPU driver refuses the shading code.
- When compiled off-line are transpiled to bytecode, extra specialized tooling is required (such as an external program, a language extension, etc.).
- Writing shaders imply learning a new language. The most widespread shading language is GLSL but others exist, meaning that people will have to learn specialized languages and, most of the time, weaker compilation systems. For instance, GLSL doesn’t have anything natively to include other GLSL files and it’s an old C-like language.
- Even though the appeal of using a language in a dynamic way can seem appealing, going from a dynamic language and
using it in a statically manner is not an easy task. However, going the other way around (from a static to dynamic)
is much much simpler. In other terms: it is possible to live-reload a compiled language with the help of low-level
system primitives, such as
dlopen,dlsym, etc. It’s more work but it’s possible. And Rust can do it too.
The author (@phaazon) of this crate thinks that shading code is still code, and that it should be treated as such. It’s easy to see the power of live-coding / reloading, but it’s more important to provide a shading code that is statically proven sound and with less bugs that without the static check. Also, as stated above, using a compiled approach doesn’t prevent from writing a relocatable object, compiled isolated and reload this object, providing roughly the same functionality as live-coding.
Important note: this crate does its best to catch semantic bugs at compile-time via
rustc. However, it might still lack opportunities to catch all semantic bugs. If you find such a case, please feel free to open an issue to as that is considered a bug / regression.
Another important point is the choice of using an EDSL. Some people would argue that Rust has other interesting and powerful ways to achieve the same goal. It is important to notice that this crate doesn’t provide a compiler to compile Rust code to a shading language. Instead, it provides a Rust crate that will still generate the shading code at runtime. Other alternatives would be using a proc-macro. Several crates who do this:
- You can use the glsl and [glsl-quasiquote] crates. The first one is a parser for GLSL and the second one allows you
to write GLSL in a quasi-quoter (
glsl! { /* here */ }) and get it compiled and check at runtime. It’s still GLSL, though, and the possibilities of runtime combinations are much less than an EDSL. - You can use the rust-gpu project. It’s a similar project but they use a proc-macro, compiling Rust code
representing GPU code. It requires a specific toolchain and doesn’t operate at the same level of this crate — it can
even compile a large part of the
corelibrary.
- blaze-html, a Haskell EDSL to build HTML in Haskell.
- selda, a Haskell EDSL to build SQL queries and execute them without writing SQL strings. This current crate is very similar in the approach.
If you like type systems, languages and basically hacking compilers (writing code for your compiler to generate the runtime code!), then it’s likely you’ll like this crate. Among all the features you will find:
- Use vanilla Rust. Because this crate is language-agnostic, the whole thing you need to know to get started is to write Rust. You don’t have to learn GLSL to use this crate — even though you still need to understand the concept of shaders, what they are, how they work, etc. But the encoding of those concepts is now encapsulated by a native Rust crate.
- Types used to represent shading types are basic and native Rust types, such as
bool,f32or[T; N]. - Write a more functional code rather than imperative code. For instance, a vertex shader in this crate is basically
a function taking an object of type
Vertexand returning another object, that will be passed to the next stage. - Catch semantic bugs within
rustc. For instance, assigning aboolto af32in your shader code will trigger arustcerror. - Make some code impossible to write. For instance, you will not be able to use in a vertex shader expressions only valid in the context of a fragment shader, as this is not possible by their own definitions.
- Extend and add more items to famous shading languages. For instance, GLSL doesn’t have a
πconstant. This situation is fixed so you will never have to writeπdecimals by yourself anymore. - Because you write Rust, benefit from all the language type candies, composability, extensibility and soundness.
- An experimental monadic experience behind a feature-gate. This allows to write shaders by using the do-notation crate and remove a lot of boilerplate for you, making scopes and shader scopes hidden for you, making it feel like writing magic shading code.
The crate is, as of nowadays, still very experimental. Here’s a list of things you might dislike about the crate:
- The current verbosity is non-acceptable. Most lambdas you’ll have to use require you to annotate their arguments, even though those are clearly guessable. This situation should be addressed as soon as possible, but people has to know that the current situation implies lots of type ascriptions.
- Some people would argue that writing GLSL is much faster and simpler, and they would be right. However, you would need to learn GLSL in the first place; you wouldn’t be able to target SPIR-V; you wouldn’t have a solution to the static typing problem; etc.
- In the case of a runtime compilation / linking failure of your shading code, debugging it might be challenging, as all the identifiers (with a few exceptions) are generated for you. It’ll make it harder to understand the generated code.
- Some concepts, especially control-flow statements, look a bit weird. For instance, a
forloop in GLSL is written with a much more convoluted way with this crate. The generated code is the same, but it is correctly more verbose via this crate.