Render Graph as Systems #5062
Description
What problem does this solve or what need does it fill?
Currently the render graph runs as a exclusive system as it traverses the graph and builds the final rendering output. This provides great flexibility, but is fundamentally single-threaded. With ongoing work to introduce stageless (bevyengine/rfcs#45), this represents a large bottleneck each frame.
What solution would you like?
Bring the render graph into the native language of Bevy: ECS systems. Each render graph node or subnodes should be represented as individual systems that the graph builds into the app schedule. These systems are still sequentially executed due to the nature of the render graph, but are publicly labeled, and allow other rendering systems (sorting/batching) to run in parallel and declared as explicit dependencies. This should allow the graph to essentially start rendering as soon as the Prepare system command buffers are finished: sorting and batching can run in parallel with render graph systems, and will block further execution of the render graph until a specific nodes dependencies are completed.
For example, in a scene with a large mix of opaque, alpha mask, and transparent objects, the opaque phase will run immediately after opaque sorting is completed, potentially in parallel with transparent and alpha mask sorting, and subsequent render phases will only run when the requisite dependencies are completed.
What alternative(s) have you considered?
#5042 posits a alternative where we use wgpu's render bundles to use a scatter and collect method for encoding render command buffers before a final collect-and-submit phase. These two approaches are not necessarily mutually exclusive, and can be used together to split the render graph into smaller, more parallelizeable chunks.