Graphics Threading: Render the previous frame while processing game logic for the current frame

One thing I noticed after looking at the Timeline view in the Profiler, is that a bunch of time is being spent on the Main Thread rendering.

This seems suboptimal to me. Suppose it were arranged differently: While the rendering thread is busy dealing with culling, sorting objects by distance, figuring out how to batch items, calculating which LOD to draw, etc., the main scene could be setting up the objects to be rendered in the next frame (I.E. running gameplay logic).

Obviously if Unity tried to render the scene as you were modifying it, you'd have a very glitchy mess where, for example, the Rendering Thread may be trying to sort an object by distance, when it is suddenly deleted on the Main Thread and now has no valid position information.

Instead, you'd have to have a "staging" process that occurs at the very end of all game logic, where all the game objects' rendering-relevant states are "copied" to the render thread. This data would never be touched by the main thread again after the rendering thread gets its hands on it, and thus no conflict is possible. Perhaps some form of double-buffering could be employed instead of copying. Or, have staging data - basically a list of scene changes that are fast to submit - that is accumulated on the main thread as objects are created, destroyed, moved, or changed, that is then passed to the render thread to sort out. Then the main thread starts with a cleared list.

To make an analogy: It'd be a bit like dumping all the receipts (records of simple scene changes) you've been collecting in a pile every time you empty your pockets over the year (assembling them as lazily and cheaply as possible as the game state evolves) onto your accountant's desk (the rendering thread) and letting them sort out your taxes (reconstruct a copy of the scene from the changes) while you keep your mind on other things (advancing a game tick).

It wouldn't be simple and might break a lot of main-thread callbacks like OnWillRenderObject, but in my case it'd double the frame rate. I believe this is how in-house developed engines for specific consoles are designed.