GPUShaderDescriptor for interface abstraction
This is a first draft of what the Shader Descriptor system could be.
A shader descriptor provides a way to define shader structure, resources
and interfaces. This makes for a quick way to provide backend agnostic
binding informations while also making shader variations easy to declare.
- Clear source input (only one file). Cleans up the GPU api since we can create a
shader from one descriptor
- Resources and interfaces are generated by the backend (much simpler than parsing).
- Bindings are explicit from position in the array.
- GPUShaderInterface becomes a trivial translation of enums and string copy.
- No external dependency to third party lib.
- Cleaner code, less fragmentation of resources in several libs.
- Easy to modify / extend at runtime.
- no parser involve, very easy to code.
- Does not hold any data, can be static and kept on disc.
- Could hold precompiled bytecode for static shaders.
This also includes a new global dependency system.
This is a prototype to support `#include` directive inside glsl sources.
I went for a C type shader description with static array for the given reasons:
- Simplicity: this is compiled language, can be extended at runtime by
C and C++ without much effort, no parsing involved.
- Readability: Can use designated initializers which allow meaningful
syntax (like `.push_constants` or `` for the 1st bind point).
- Combinations: We can combine descriptors to create shader variations
really quickly. See `workbench_prepass.desc.h` in the branch for some crazy combination.
- Avoid having to write a C++ interface for C usage.
Note that the CMake changes are just to make things work.
What is remaining:
- GL backend to generate uniforms and support push constants (via uniforms).
- pyGPU API
What I would like to discuss:
- Naming: Is "descriptor" too much similar to vulkans descriptors set? This might create
confusion. Maybe MetaData is better? But it may hold more than meta data.
- Choose the right extension for descriptor files.
- Choose the right folder. Do we keep them alongside shader files even if name could differ?
- Indentation is 4 spaces for some reasons in descriptors definitions.
- Memory usage might be a concern. We are talking about ~3 MByte of data in the executable.
- Syntax: Is using  to specify binding index clear enough or using `VERTEX_INPUT(0, ...)`
makes more sense? What about future proofing if we one day want to compile this as C++ code.
- This format has nice benefits but it needs manual writting on our ends to modify the shaders.
That said, writting all shaders variations for the workbench prepass was quite easy and fast.
- How would we expose this through pyGPU?
Differential Revision: https://developer.blender.org/D13360