What shall we do with shader languages?

[hadronized]

Problem

We’re exposing the shader source code as String. I hate that. It’s opaque, it lives at runtime, it doesn’t scale (no cross-language support when writting shaders, no modules/libs). We have to find a way out of that situation

Solution 1 – EDSL via macros

Writing an EDSL would solve that in the most elegant way. The idea is to have a set of types, functions and macros to help creating shader stages directly in rust. Such work is partially implemented in the lsl branch.

Advantages

• compile-time ;
• because of being an IRL, we can write several compilers in backends to target shading languages ;
• possibility to link inputs / outputs directly to the luminance pipeline, adding an extra, cool layer of type safety.

  Drawbacks

• tedious to maintain (rust macros) and hard to use (because of macros errors being a pain in the ass) ;
• no direct shader hot reloading; even though I don’t really care about that, it might be a problem (can be fixed with hot recompilation with rustc though, so not really a problem, just something to know).

  Solution 2 – DSL

We can have a DSL written in a language of our own. We would load it, parse it, compile it and turn it into a graphics executable at runtime. Exactly like we already do with GLSL.

Advantages

• because of being an IRL, we can write several compilers in backends to target shading languages.

  Drawbacks

• runtime compilation (no static safety) ;
• basically still String, so as opaque as the current ;
• no way to link inputs / outputs ; doesn’t enhance the static safety of the pipeline.

  Solution 3 – EDSL via compiler plugins

From the reading of this, it should be possible to use the compiler plugins power of rustc to create directly the EDSL in rustc itself.

Advantages

• compile-time ;
• because of being an IRL, we can write several compilers in backends to target shading languages ;
• possibility to link inputs / outputs directly to the luminance pipeline, adding an extra, cool layer of type safety ;
• seamless integration with Rust!

  Drawbacks

• might be used to maintain / write because it’s a nightly rustc extension ;
• no feedback on that yet, so we’re going blind.

---

Which one to choose?

[samhocevar]

You may also consider Solution 4 – do nothing and work on something else.

I don’t understand the hate: text-based GLSL shaders are great, they’re cross-platform and cross-engine, you can copy whole chunks of them around, you can debug them directly using RenderDoc and have access to the original source code that you know and understand, instead of some generated intermediate code.

[hadronized]

Interesting idea. The problem with string shaders is the fact they’re opaque at compilation and that static analysis is performed at runtime. I’m not sure whether I truly want that to happen without a compile-time pass to check the correctness of the code.

[nical]

I'm with Sam on this one. Shader compilation happening at run-time is actually a blessing rather than a curse: you can write tools that let you live-edit your shader without rebuilding/restarting the engine. Especially for demoscene prods where you typically spend a lot of time tweakig shaders, it is a much bigger productivity win than having the guarantee that shaders build without running the engine.

[hadronized]

I kinda disagree with that in the sense that tweaking shaders is not about changing code, it’s about changing values passed in as uniforms.

[nical]

I really meant tweaking shaders as in modifying the source code (changing uniform values is not tweaking a shader). I am very surprised you don't do that all the time. How do you write new effects?

[hadronized]

I write the shader code as GLSL and run / restart the program when I tweak the shader. Which can be tedious, that’s true, but it’s not that much compared to visual tweaks.

[samhocevar]

@phaazon IMHO if you can tweak your shaders by changing uniforms rather than changing the code, then they are very simple and they don’t actually need the compile-time verification you strive for.

[hadronized]

Good point. :)

[hadronized]

Ok, so, I’ll just leave the shaders as plain String. There’s already pragma injection in the OpenGL backends (#version 330 core for instance). The rest is YOLO.