Render graph design

[repi]

A high-level goal for this project is to also design a GPU rendering/compute graph to tie it all together and enable users to to develop small reusable graph components inside crates that contain Rust CPU and GPU code and that can be easily connected and tweaked.

We talked briefly about it today in #15, but will require quite a bit of design and the lower level parts of SPIRV codegeneration and Rust bindings overall (#10) is higher priority

[repi]

As we said in the meeting yesterday (#227) feel free to discuss goals, high-level designs, and gather references from other implementations for this here in the issue. cc @vojd

If it does start getting somewhat extensive, could also just write it up an a markdown file and check in. I think later for the design phase we'll go through MCE / RFCs but also prototypes directly in our engine codebase (Ark)

[tema3210]

Given the scope of project (it's not proposing its own render API (right?)), I think we need to make a mechanism for gathering and exporting information about which resources are acessed by our shaders. This would allow, for example, a wgpu reason about what shaders we passed to it use what data.

The rest of the design of render graph is implementation specific.

My vision of this is that we should assist developers in creating render graph systems, not make yet another one.

[TrueDoctor]

For Graphite we are developing a node based image editor where every node is a rust function that can be executed on the cpu/gpu. The user can then modify the nodegraph visually which is then either dynamically linked or ad hoc compiled and executed. We probably target an even more high level/abstract user experience then you would try to provide, but the issues that come up during our implementation could potentially inform your design.

• Embark could potentially profit from a software such as graphite because it would be trivial to integrate your own tools as nodes in a graph and use the already provided ui. The project is of course fully open source.

[repi]

closing this old issue because we already have a GPU render graph in kajiya as well as our own production renderer.

@TrueDoctor I think the type of render node graph you are talking about is a different thing, this was specifically about coordinating GPU rasterization/raytracing/compute passes on the GPU and it is memory management. for early work on it see the FrameGraph in Frostbite