Revisit Render/DrawFunction Design

[james7132]

What problem does this solve or what need does it fill?

After a round of optimizations for rendering and ECS in general, the render phase is now the largest CPU-side bottleneck when rendering more complex scenes. Speeding up the render phase is central to having a performant rendering pipeline.

What solution would you like?

DrawFunctions incur the following costs as unavoidable overhead.

• Dynamic dispatch: each PhaseItem incurs at least one dynamic dispatch via Box<dyn Draw>.
• System Param/Query State initialization: every call must reinitialize a SystemParamState from the World and then query for the target entity. While typically a low overhead, doing this once for every visible entity from every view can easily take up the majority of the time in each phase.

These costs are mitigated via CPU caching and SystemState/QueryState level checks, but ideally, these costs should be moved out of the hot loop and into a preparation stage of some kind. What form this takes may not be too clear given the constraints the phase is operating under.

What alternative(s) have you considered?

All of these are orthogonal approaches for chunking/splitting/speeding up the phase:

• Parallelizing the render phase via wgpu's RenderBundles: Parallelize the core pipeline passes with wgpu's RenderBundles #5042.
• Allowing the render phase to run in parallel with per-phase dependencies: Render Graph as Systems #5062.
• Minimizing the number of draw calls via GPU instancing or batching: GPU Instancing #89.
• Optimizing the individual structures within each draw function by optimizing Query::get.
• Full bindless rendering: shift the cost to the GPU. Not universally supported.

[superdump]

What I'm going to write doesn't contradict what you have written. Hopefully it just clarifies my perspective on it. :)

Instancing, batching, bindless, and GPU-driven rendering address overall rendering performance. I'd express it as they don't improve the performance of the render graph node code that create passes and encode the draw commands, rather they just reduce the amount of work for the render graph nodes to do, one way or another.

Because it is not always possible to use those approaches for various reasons, I think we should both look into those approaches (which I intend to do) and try to optimise the current situation of one draw per mesh.

[james7132]

• System Param/Query State initialization: every call must reinitialize a SystemParamState from the World and then query for the target entity. While typically a low overhead, doing this once for every visible entity from every view can easily take up the majority of the time in each phase.

This has been addressed as a part of #6885 and #7084.

[james7132]

With the efforts in batching and parallelization, this is no longer the biggest bottleneck when rendering. Closing out as no longer planned.