Rethinking render world

[PixelDust22]

Recently I've been working on some rendering features and I realized that the separation between the "main world" and the "render world" requires a lot more boilerplate code to be written. Working with the Extract phase feels awkward, repetitive, redundant and prone to error. I looked back at the bevy 0.6 release notes and here are the benefits claimed for having a two-world design:

- Increased Parallelism: We can now start running the main app logic for the next frame, while rendering the current frame. Given that rendering is often a bottleneck, this can be a huge win when there is also a lot of app work to do.
- Clearer Dataflow and Structure: Pipelining requires drawing hard lines between "app logic" and "render logic", with a fixed synchronization point (which we call the "extract" step). This makes it easier to reason about dataflow and ownership. Code can be organized along these lines, which improves clarity.

There might be a few assumptions we're making here:

• The render app logic is unable to fully saturate the CPU. If the render app alone fully saturates the CPU, both the render logic and the app logic for the next frame will be running slower, causing increased latency and reduced throughput (due to the added extraction phase).
• The time spent on running the render app logic (presumably recording command buffers) dwarfs the cost of extraction. In some applications with primarily GPU-driven rendering, this might not be true. They might only have one or two draw_indirect or trace_rays draw calls and nothing else, in which case the render app logic would be far cheaper.
• The dataflow between the two worlds are strictly one-way. If the app logic depends on the feedback from the renderer, the main world will have to wait for the render logic to finish anyways. If we defer this "back-propagation" work until the next frame, we won't have an opportunity to do so until the Extract phase, at which point the simulation logic has already finished.

Regarding the second point in these arguments, here's another question I have: what makes Render special? If we have a separate subapp for Render, why not also have a subapp for physics, network, etc so we can have "Clearer Dataflow and Structure" everywhere?

In parallel to that, if the increased performance came from overlapping work from two frames, why couldn't this be exploited from the ECS itself so that nothing needs to live in a separate world? Systems on the beginning of next frame could execute in parallel to systems at the end of the current frame as long as they're not accessing the same set of resources.

In general, having two worlds seem to introduce a lot of unnecessary complexity, so I'm hoping that these costs were justified. I haven't seen a conversation on this topic, but I might be missing something. I would appreciate any pointers towards old discussions that might help answering those questions.

[alice-i-cecile]

See #6503 for some of those realized performance gains.

I would very much like to be able to use this pattern more widely though: I agree that special casing rendering feels wrong.

And similarly, being able to swap strategies seamlessly and benchmark the difference in real apps would be lovely.

[PixelDust22]

I'm glad that pipelining the render world yields the promised performance gain, but we should really be comparing it with a one-world strategy. There are examples with a lower (5%) margin, and the overhead caused by the Extract phase might actually offset that, making the pipelined version slower.

We should be able to exploit parallelism across frames in a less intrusive way, potentially from within the ECS itself with a per-system granularity. The stageless API might enable us to do so.

[alice-i-cecile]

Yep, totally agree. The existing strategy is a worst-of-both-approaches situation, and it's unsurprising that actually using it as intended results in performance improvements.