- Also *no bindings*, all shader resources were passed using shared structs, that directly embedded buffer/texture descriptors or pointers to other structs. Easy to describe and easy to change.
- And had great hot reload support for iteration/debugging, press a key in VS to recompile the shaders in that file and instantly replace in live game.

...

Anyhow, best system I've used. Super easy to add new shaders, share code between CPU and GPU, and iterate live.

Likely only practical due to having fixed platforms (PS4/Pro) and compilers (clang and psslc), and shaders being code not content, but is the benchmark I judge shader pipelines against. :)

@mjp @sjb3d you don't need to pass such a struct directly into the shader though. A shader compiler could code-generate C-structs for the uniform data expected by the shader, and a separate struct for the resource bindings. A 3D wrapper API can then consume the bindings struct and map that to traditional 3D API resource binding calls.

This wouldn't be faster, but a lot more 'type-safe'.

@mjp @sjb3d in sokol-gfx (which is a wrapper for 'traditional' 3D APIs) I code-generate a C struct for uniform data in the offline-shader compiler - along with a lot more reflection data from the shader, like the expected resource types and their bind slots.

I didn't go the last step to code-generate a struct for the resource bindings too, but tbh the more I think about it, the more I like the idea...

@floooh @mjp yeah on PC, even though there is no standard GPU memory layout I still find structs useful to manage a whole "descriptor set" of resources at once.

If you are using Slang for shader code, there is "ParameterBlock" syntax that maps really well to this, and avoids the need to specify bindings at all.