Blender Git Commits

Merge branch 'master' into gpu-shader-descriptor

Implement OpenGL backend support 1/2

ShaderCreateInfo: Rewrite implementation in C++

Merge branch 'master' into gpu-shader-descriptor

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 `[0]` 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 [0] 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

Fix compilation & dependency depth

Make shaders sources from draw included in the dependency library.

Fix compilation issues on MSVC and a bug in builder

GPUShaderDependency: Initial Commit

This is a prototype to support `#include` directive inside glsl sources.
The sources are aggregated into a list before being translated to byte_array.
This list is used to generate a mapping between the filename and the
associated byte_array. For each byte_array, we search for any `#include`
and store the file to merge.

At runtime, for one input filename we concatenate all byte_arrays that
are needed following the include order and avoiding double include.

This is meant to evolve into a fully supported `#include` system.

GPUShaderDescriptor: Initial Commit

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.