Swap material and mesh bind groups

[JMS55]

Objective

• Materials should be a more frequent rebind then meshes (due to being able to use a single vertex buffer, such as in Meshlet rendering (initial feature) #10164) and therefore should be in a higher bind group.

---

Changelog

• For 2d and 3d mesh/material setups (but not UI materials, or other rendering setups such as gizmos, sprites, or text), mesh data is now in bind group 1, and material data is now in bind group 2, which is swapped from how they were before.

Migration Guide

• Custom 2d and 3d mesh/material shaders should now use bind group 2 @group(2) @binding(x) for their bound resources, instead of bind group 1.
• Many internal pieces of rendering code have changed so that mesh data is now in bind group 1, and material data is now in bind group 2. Semi-custom rendering setups (that don't use the Material or Material2d APIs) should adapt to these changes.

[JMS55]

As a followup PR, we'll probably want to sort draws by pipeline id.

[cart]

Hmm pretty sure someone flipped these for some reason awhile back (with some reasonable justification for going against the "mesh before material" bind frequency advice) . Iirc it was some sort of technical details thing (ex: architectural limitation, platform support), not a performance thing. Worth trying to find that context.

[cart]

Because yeah this is the right approach. And I'm pretty sure I did it this way in the past.

[robtfm]

cart from the past says:

Pretty sure for performance reasons we need to sort by bind frequency / assume that "later" bind groups will be rebound if earlier ones change. Given that we should be sorting by material and then drawing many meshes with the same material, I think the current order is correct

the current order used to be (potentially) better for performance before we batched meshes. now it makes more sense to put mesh first as the batch of meshes won't need frequent rebinding.

[JMS55]

Right so after moving mesh data (not mesh vertex data, just the MeshUniforms) to GpuArrayBuffer, the bind group should almost never need to be rebound (for normal meshes).

What does need rebinding is:

• When the type of mesh data changes (regular model only, skinned mesh, mesh with morph targets)
• I think an extra dynamic index for each skinned/morph target mesh, but I'm not 100% sure having never really touched that code

(Note: We probably want to sort draws so regular/skinned/morph meshes are grouped together, after material sorting)

So the only way this PR loses out currently is for e.g. skinned meshes, where you may have two different skinned meshes with the same material. This PR would cause you to have to rebind the material for each unique skinned mesh, which is expensive. But this PR is better for regular meshes...

[JMS55]

For CPU-driven rendering, I guess maybe it makes more sense to keep this as-is to avoid expensive material (pipeline) rebinds. For GPU-driven, where the pipeline is the only rebind, I can just put materials in bind group 2 anyways. I'm thinking we should close this.

[cart]

Cool yeah that all makes sense!

[superdump]

@JMS55 I'm not so sure. I think this is useful for CPU-driven as well. Considering the two bind groups:

• The mesh bind group has to be bound once for all non-skinned/non-morphed mesh entities, and rebound for each individual skinned / morphed mesh entity currently.
• The material bind group has to be rebound for every single material instance (as in, each material asset regardless of its type) currently.

The usual case for mesh assets is lots of non-skinned + non-morphed mesh entities and few skinned / morphed mesh entities. So prioritising the defaults for non-skinned / non-morphed entities makes sense. And those require one binding as all the data they need is in one buffer.

The usual case for material assets with the current solution is a bit less clear:

• One material asset per mesh entity - common for non-instanced models with textures and no texture atlas
• One material asset per many mesh entities - instanced models, or simpler usage with flat colour materials. I don't really feel like we should optimise for the latter as it's simple enough anyway.

Either way, rebinding for a material asset is at best once per group of mesh entities, and at worst once per mesh entity. The only situation I can think of where it would be 'worse' would be for entities using different skinned/morphed mesh assets which have the same material. Unless I'm missing something, that seems very niche and unlikely?

I think at this point it does make sense to swap the material and mesh bind groups. I'd suggest reopening this and merging it, as well as in a separate PR, changing the sorting of the opaque and alpha mask passes. If we do swap the binding order, then we would want to sort by pipeline id, mesh bind group id + dynamic offset, material bind group id, z front to back. Though we'd want to test the impact on sorting performance for non-trivial configurations to see whether we could cut down on those sort key fields.

[JMS55]

Would it be possible to move the skinning and morph data into storage buffers? More perf, and we'd avoid this whole issue to begin with.

[robtfm]

lgtm.

one lingering "group 1" in a comment in bind_group.rs:

/// ... in Bevy material bind groups
/// are generally bound to group 1.

i haven't checked performance - i don't expect any regressions but maybe we ought to benchmark?

[JMS55]

i haven't checked performance - i don't expect any regressions but maybe we ought to benchmark?

Shouldn't be any regressions atm I don't think, as we don't sort primarily by pipeline/bind group yet. It'll limit the max perf we can have for skinned meshes/morph targets in the future though (as they use a separate vertex buffer per mesh), but that's a tradeoff we'll have to accept, unless we want to add a toggle to the shader code to switch the group orderings (which we could also easily do).

EDIT: I personally can't benchmark anything well for the next 2 weeks, as I only have access to an old laptop atm.

[superdump]

Would it be possible to move the skinning and morph data into storage buffers? More perf, and we'd avoid this whole issue to begin with.

I have a branch locally that does this for skinning. Morph uses textures so it's a different beast. And we still can't avoid it because the current approach is the best we can do for uniform buffers and not everyone has access to storage buffers.

[superdump]

🚀