yum-mirror/slang
Making it easier to work with shaders
git clone https://git.yummers.dev/yum-mirror/slang
d7ce74a3f
master
Slang "Shader Toy" Example
This example shows how to use Slang's support for generics and interfaces to define shader effects as separately-compiled modules. The effects in this case are based on the popular Shader Toy site.
Goals
The big-picture goals of this example is to define effects as separately-compiled modules of Slang code, and to also allow different methods of executing those effects (e.g., via vertex/fragment shaders or compute shaders) to be defined as modules. Each module should be something the Slang compiler can compile and check independently.
Combining modules (e.g., a particular shader effect with a particular execution method) should be accomplished using first-class operations supported by the Slang API, instead of by ad hoc preprocessing or pasting of strings.
Approach
The key idea here is to codify the rules for what a shader toy effect needs to provide in an interface (here called IShaderToyImageShader), and to use that interface as a contract when checking both implementers and users of that interface.
Individual effects become struct types that declare conformance to IShaderToyImageShader; the compiler can thus issue error messages when a time fails to satisfy its requirements.
Execution methods become generic functions that abstract over any type that implements IShaderToyImageShader; the compiler can confirm that they only use operations that are guaranteed by the interface to be present.
Composition thus consists of "plugging in" a type that implements the interface as a type argument of the generic function that implements an execution method.
While the interfaces and modules that this example works with are relatively low in complexity, these same techniques can be applied to modularize more complex shader code without the need for preprocessor or metaprogramming tricks.
1Slang "Shader Toy" Example 2========================== 3 4This example shows how to use Slang's support for generics and interfaces to define shader effects as separately-compiled modules. 5The effects in this case are based on the popular [Shader Toy](https://www.shadertoy.com/) site. 6 7Goals 8----- 9 10The big-picture goals of this example is to define effects as separately-compiled modules of Slang code, and to also allow different methods of executing those effects (e.g., via vertex/fragment shaders or compute shaders) to be defined as modules. 11Each module should be something the Slang compiler can compile and check independently. 12 13Combining modules (e.g., a particular shader effect with a particular execution method) should be accomplished using first-class operations supported by the Slang API, instead of by ad hoc preprocessing or pasting of strings. 14 15Approach 16-------- 17 18The key idea here is to codify the rules for what a shader toy effect needs to provide in an interface (here called `IShaderToyImageShader`), and to use that interface as a contract when checking both implementers and users of that interface. 19 20Individual effects become `struct` types that declare conformance to `IShaderToyImageShader`; the compiler can thus issue error messages when a time fails to satisfy its requirements. 21Execution methods become generic functions that abstract over any type that implements `IShaderToyImageShader`; the compiler can confirm that they only use operations that are guaranteed by the interface to be present. 22 23Composition thus consists of "plugging in" a type that implements the interface as a type argument of the generic function that implements an execution method. 24 25While the interfaces and modules that this example works with are relatively low in complexity, these same techniques can be applied to modularize more complex shader code without the need for preprocessor or metaprogramming tricks.