This repository was archived by the owner on Oct 31, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 31, 2025. It is now read-only.
Render graph design #21
Description
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
Activity
repi commentedon Nov 13, 2020
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 commentedon Apr 7, 2022
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 commentedon Nov 7, 2022
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.
repi commentedon Nov 21, 2022
closing this old issue because we already have a GPU render graph in
kajiyaas 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