Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using offset-allocator to pack multiple effects into the same buffer #391

Open
pcwalton opened this issue Oct 24, 2024 · 2 comments
Labels
A - internal Internal change on a core system C - enhancement New feature or request C - performance An issue with performance

Comments

@pcwalton
Copy link
Contributor

Bevy 0.15 uses https://github.com/pcwalton/offset-allocator to pack vertices and indices from separate meshes into a small number of GPU buffers. This saves on wgpu overhead because it doesn't have to switch bindings so much. We should consider doing this.

@djeedai djeedai added C - enhancement New feature or request A - internal Internal change on a core system C - performance An issue with performance labels Oct 29, 2024
@djeedai
Copy link
Owner

djeedai commented Dec 22, 2024

I looked briefly @pcwalton, and although that looks neat for vertices and indices, that's sounds pretty useless for anything else, unless I missed something. The reason is that it doesn't guarantee alignment, so you can't use it to sub-allocate a storage buffer, because if you don't align to min_storage_buffer_offset_alignment then you can't bind the sub-allocation directly. You'd have to use dynamic indexing inside the shader for that (bindless style), which is a lot more complex to handle. But agreed for vertices and indices though.

@djeedai
Copy link
Owner

djeedai commented Dec 22, 2024

Note for self: looking at the bin table, it looks like for any allocation size greater than or equal to align * 8, then all bins are aligned on align. That means for any allocation of at least 256 bytes (align=32, e.g. NVIDIA) or 2048 bytes (align=256, macOS/Metal), we can use the allocator. Otherwise the problem is trivial, so we can manually round up to the nearest multiple before asking the allocator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A - internal Internal change on a core system C - enhancement New feature or request C - performance An issue with performance
Projects
None yet
Development

No branches or pull requests

2 participants