Better handling of runtime shader generation

[cyanreg]

I'd like to share some feedback on behalf of FFmpeg, and libplacebo. Both libraries are very widely used, and use shaders to handle everything from scaling, filtering, decoding, encoding and even running user-provided shaders.

All the shaders are generated at runtime, from text to SPIR-V, and may even dynamically be recreated. Pretty much all of our shaders generally revolve around linking different chunks of GLSL code to perform all operations we need to.
This has various overhead. libplacebo had to write a complex system to hash text code of shaders just to check if recompilation is required, due to parameters changing. Despite the generated shaders being hardly a few hundred lines, on certain platforms, such as Windows, compiling shaders may take a very long time (more than a second!).

What we're looking for is a language that makes this more comfortable and lower-overhead.
Ideally, what we'd like is the possibility to precompile chunks of code, such as functions, down to incomplete SPIR-V or other form of IR, which we could then link during runtime. Preferably, this would also involve validation (currently you have to read through the printout of the entire shader to figure out what went wrong).

[csyonghe]

Slang is designed from the right beginning with modular compilation in mind. Please take a look at our documentation regarding module pre compilation: https://shader-slang.com/slang/user-guide/link-time-specialization.html

The tldr is that we allow you to compile your "fixed" part of code to slang ir, and then link them with the run time generated code to produce the final spirv/ whatever downstream code. This will remove all the redundant parsing and type checking logic on the fixed part of your code.

We are currently experimenting with pushing the envelope even further down the chain, by precompiling to spirv as much as possible to reduce more redundant work. The high order bit is that all slang features are designed to be compatible with modular compilation (and that is an important reason why we support generics rather than templates), and we envision a future where gpu code can be compiled the same way as cpu code as modules of native machine code and linked at runtime right before execution, and slang's language design is intended to be compatible with that future.

[haasn]

Do you think it could become possible to manipulate / generate ASTs at runtime? For example, parsing a user-provided expression and compiling it down to shader code at runtime, without going the long route of generating text.

[csyonghe]

It is possible, but this isn't supported today and likely has very low !/$.

The steps of parsing text and producing the initial ast is very lightweight(these steps take less than 1% of total compile time), allowing the user to directly manipulate the ast will not lead to measurable performance wins.

The main challenge of exposing expression level asts directly is that we will need to provide a stableness guarantee on the ast design, which will restrict the ways we can evolve the language implementation going forward.

If you can share more on your use case, we can discuss in more details all the available options in slang that may help you architect your system cleanly and efficiently.

[tangent-vector]

To reiterate and follow up on some of what Yong has said:

Some use cases that would require generation of shader source code via metaprogramming when using other languages/compilers can be accomplished in Slang using things like our support for separately-compiled modules, generics, etc.

We are aware of many well-tested constructs we could add to Slang to facilitate more powerful and easier metaprogramming, but so far we have no prioritized development of those constructs, instead focusing more of our effort on the features that can often eliminate the need for metaprogramming in the first place.

That priority may shift over time, if metaprogramming starts to seem like the best way to achieve the goals of many of our users. If/when it does, we have many plans we’d be ready to start implementing.

[bmillsNV]

Let's move this to a discussion since we don't currently have a work item. If there are items that spawn out of the discussion, we can create issues and track them.