Parallel Mesh Collection

[aevyrie]

Objective

• Speed up collect_meshes_for_gpu_building, a bottleneck for scenes with many moving meshes.

Solution

• Parallelize the gather step for mesh collection.
• Immediately start up a task for serial collection of meshes, which cannot be parallelized.
• Spawn many tasks for gathering meshes, and send batches of these to the collection task
• This allows the serial collection step to start immediately, instead of being delayed until after all collection is finished.

Testing

• Built a new bevymark_3d stress test for benchmarking dynamic 3d mesh scenes. This is not currently covered by our stress tests. Bevymark 3D #22298
• With 200k meshes, this drops total frame times from 16.4ms to 12.3ms (-4.1ms)

• Mesh collection itself drops from 7.9ms to 3.6ms (-4.3ms)

[alice-i-cecile]

CI failures are real, but should be easy to fix.

[aevyrie]

@alice-i-cecile g2g now

[aevyrie]

Added to the milestone as it seems about equivalent to my others perf PRs that were also added.

[aevyrie]

This PR needs more thorough testing before I'd feel comfortable merging. Parallelizing isn't always a speedup and can increase the total amount of CPU work needed even if throughput increases.

So far, things are still looking promising after my latest round of commits

cargo rer bevymark_3d --features=debug,trace_tracy -- --benchmark --waves 250 --per-wave 1000

comparing this branch to main

frametime

collect_meshes_for_gpu_building

[pcwalton]

The logic looks fine, but I think with some different factoring this would be easier to maintain and check. I'm not 100% sure the refactoring is viable, but I'd like to see if we can try.

[pcwalton]

OK, I love this. This will help so much with making other parts of the system parallel, and addons and apps should be able to use this for increased parallelism too. In fact, it's essentially a big upgrade for the ECS, allowing easy parallelism in situations where par_iter() on a query isn't enough.

Thanks a bunch for taking the time to refactor it!

[aevyrie]

Revisiting benches after visibility optimizations merged, the improvements are still reproducible, and overall frametimes are improved thanks to the optimizations on main.

[Aceeri]

Profiled the changes here vs not and got some decent results on my project. The main important peaks are those 2 at the end which this PR reduces from ~22ms to ~10ms.

The faster portions are a result of flying out to lower LODs so not super representative, but maybe shows a bit of the overhead for smaller amounts of meshes (left 2 peaks are 18 meshes), increasing it from 25µs to ~35-50µs.

[Aceeri]

I like this, the buffered channel seems useful for my own parallel code and the recycling is something I have been doing as well but making it generic is very nice.

Solid performance improvement on my project as well: 22ms -> 10ms in the expected case.

[aevyrie]

Thanks for testing in your project - that gives me way more confidence this is a positive change. I'm pretty happy with how the buffered channel turned out!

[github-actions]

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.