Build batches across phases in parallel. #17764
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pcwalton
added
A-Rendering
Currently, invocations of `batch_and_prepare_binned_render_phase` and `batch_and_prepare_sorted_render_phase` can't run in parallel because they write to scene-global GPU buffers. After PR bevyengine#17698, `batch_and_prepare_binned_render_phase` started accounting for the lion's share of the CPU time, causing us to be strongly CPU bound on scenes like Caldera when occlusion culling was on (because of the overhead of batching for the Z-prepass). Although I eventually plan to optimize `batch_and_prepare_binned_render_phase`, we can obtain significant wins now by parallelizing that system across phases. This commit splits all GPU buffers that `batch_and_prepare_binned_render_phase` and `batch_and_prepare_sorted_render_phase` touches into separate buffers for each phase so that the scheduler will run those phases in parallel. At the end of batch preparation, we gather the render phases up into a single resource with a new *collection* phase. Because we already run mesh preprocessing separately for each phase in order to make occlusion culling work, this is actually a cleaner separation. For example, mesh output indices (the unique ID that identifies each mesh instance on GPU) are now guaranteed to be sequential starting from 0, which will simplify the forthcoming work to remove them in favor of the compute dispatch ID. On Caldera, this brings the frame time down to approximately 9.1 ms with occlusion culling on.
pcwalton
force-pushed
the
parallel-batch-and-prepare
branch
from
08de0fe to
c1f9764
Compare
superdump
reviewed
Feb 10, 2025
examples/3d/occlusion_culling.rs
Outdated
| @@ -185,6 +190,10 @@ fn main() { | |||
| .set(RenderPlugin { | |||
| allow_copies_from_indirect_parameters: true, | |||
| ..default() | |||
| }) | |||
| .set(PbrPlugin { | |||
| allow_copies_from_indirect_parameters: true, | |||
There was a problem hiding this comment.
Could this be reused from the RenderPlugin? Rather than having to set it in two places.
There was a problem hiding this comment.
Could you elaborate as to how that would work? The problem is that the PbrPlugin can't reach into the RenderPlugin to check its value.
There was a problem hiding this comment.
I think this is fine for now but it's a rather particular option and I might suggest subsuming it some kind of broader "debug renderer" setting if we ever have a second instance of this kind of thing.
There was a problem hiding this comment.
Yeah, good point. Or maybe a "debug flags"?
There was a problem hiding this comment.
I went ahead and switched this to a RenderDebugFlags so that we can have more of them.
tychedelia
approved these changes
Feb 11, 2025
superdump
approved these changes
Feb 13, 2025
alice-i-cecile
added
S-Ready-For-Final-Review
This was referenced Feb 13, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, invocations of
batch_and_prepare_binned_render_phaseandbatch_and_prepare_sorted_render_phasecan't run in parallel because they write to scene-global GPU buffers. After PR #17698,batch_and_prepare_binned_render_phasestarted accounting for the lion's share of the CPU time, causing us to be strongly CPU bound on scenes like Caldera when occlusion culling was on (because of the overhead of batching for the Z-prepass). Although I eventually plan to optimizebatch_and_prepare_binned_render_phase, we can obtain significant wins now by parallelizing that system across phases.This commit splits all GPU buffers that
batch_and_prepare_binned_render_phaseandbatch_and_prepare_sorted_render_phasetouches into separate buffers for each phase so that the scheduler will run those phases in parallel. At the end of batch preparation, we gather the render phases up into a single resource with a new collection phase. Because we already run mesh preprocessing separately for each phase in order to make occlusion culling work, this is actually a cleaner separation. For example, mesh output indices (the unique ID that identifies each mesh instance on GPU) are now guaranteed to be sequential starting from 0, which will simplify the forthcoming work to remove them in favor of the compute dispatch ID.On Caldera, this brings the frame time down to approximately 9.1 ms with occlusion culling on.