Introduce two-level bins for multidrawable meshes.

[pcwalton]

Currently, our batchable binned items are stored in a hash table that maps bin key, which includes the batch set key, to a list of entities. Multidraw is handled by sorting the bin keys and accumulating adjacent bins that can be multidrawn together (i.e. have the same batch set key) into multidraw commands during batch_and_prepare_binned_render_phase.

This is reasonably efficient right now, but it will complicate future work to retain indirect draw parameters from frame to frame. Consider what must happen when we have retained indirect draw parameters and the application adds a bin (i.e. a new mesh) that shares a batch set key with some pre-existing meshes. (That is, the new mesh can be multidrawn with the pre-existing meshes.) To be maximally efficient, our goal in that scenario will be to update only the indirect draw parameters for the batch set (i.e. multidraw command) containing the mesh that was added, while leaving the others alone. That means that we have to quickly locate all the bins that belong to the batch set being modified.

In the existing code, we would have to sort the list of bin keys so that bins that can be multidrawn together become adjacent to one another in the list. Then we would have to do a binary search through the sorted list to find the location of the bin that was just added. Next, we would have to widen our search to adjacent indexes that contain the same batch set, doing expensive comparisons against the batch set key every time. Finally, we would reallocate the indirect draw parameters and update the stored pointers to the indirect draw parameters that the bins store.

By contrast, it'd be dramatically simpler if we simply changed the way bins are stored to first map from batch set key (i.e. multidraw command) to the bins (i.e. meshes) within that batch set key, and then from each individual bin to the mesh instances. That way, the scenario above in which we add a new mesh will be simpler to handle. First, we will look up the batch set key corresponding to that mesh in the outer map to find an inner map corresponding to the single multidraw command that will draw that batch set. We will know how many meshes the multidraw command is going to draw by the size of that inner map. Then we simply need to reallocate the indirect draw parameters and update the pointers to those parameters within the bins as necessary. There will be no need to do any binary search or expensive batch set key comparison: only a single hash lookup and an iteration over the inner map to update the pointers.

This patch implements the above technique. Because we don't have retained bins yet, this PR provides no performance benefits. However, it opens the door to maximally efficient updates when only a small number of meshes change from frame to frame.

The main churn that this patch causes is that the batch set key (which uniquely specifies a multidraw command) and bin key (which uniquely specifies a mesh within that multidraw command) are now separate, instead of the batch set key being embedded within the bin key.

In order to isolate potential regressions, I think that at least #16890, #16836, and #16825 should land before this PR does.

Migration Guide

• The batch set key is now separate from the bin key in BinnedPhaseItem. The batch set key is used to collect multidrawable meshes together. If you aren't using the multidraw feature, you can safely set the batch set key to ().

[pcwalton]

For reviewers: If you're wondering why this is CPU-based instead of the GPU-based scatter/prefix sum/collect thing discussed on Discord, it's because the CPU has to know the GPU memory location of the indirect parameters in order to issue the indirect multidraw call. For the CPU to have that knowledge, it must be managing the allocations of the indirect parameters within the indirect parameters buffer. When meshes are added, those allocations could be resized, which yields the problem described in this PR description.

There's still room for GPU work scheduling as a follow-up to this patch, but I believe that this patch is required no matter what, at least until we have something like DGC where the CPU doesn't need to know where the indirect parameters live.

[pcwalton]

All suggested dependencies have landed now, so marking as unblocked.

[IceSentry]

LGTM

[tychedelia]

Lgtm! This was more straightforward to follow than I thought.

[aevyrie]

I'm unfamiliar with multidraw, binning, or this level of the bevy renderer, so take this review with a hefty grain of salt. The only thing I can contribute here is another set of eyes for obvious errors.

[aevyrie]

I don't understand the point of this unit type as a key. Is there more information on this pattern and what it's doing?

[pcwalton]

It's just a placeholder because we need to put some type there. DrawMesh2d doesn't multi-draw, so the batch set key is irrelevant.

[github-actions]

Your PR increases Bevy Minimum Supported Rust Version. Please update the rust-version field in the root Cargo.toml file.