Revisit Render/DrawFunction Design #5117

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.