Misuse of Metal API in rendering preperation
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
# Summary
On MacOS (and iOS) roughly every frame the render pipeline allocates a new temporary buffer, it also reinterprets the currently used texture buffers. This is bad practise as when using the Metal framework MTLBuffers should persist as long as possible and not just a single frame. Also whilst the texture reinterpretations aren't costly at all they do make a small obj-c allocation every frame for every texture.
This might (but probably not directly) be related to the high cpu usage found in #10261
Additionally:
- An Apple Instruments metal allocations trace of the 3d_scene example can be found [https://bevy.inpolen.nl/traces/3d_scene.trace.zip](here)
- Debugging this yourself requires you to properly sign the executable
# Bevy version
Tested on:
- `0d23d71` bevy 0.11.3
- `6178ce9`
- `cb64a4a` bevy 0.17-dev (current main)
All of these have the same bug
Contributor guide
Research direction
Start with the 3d_scene example and reproduce the behavior using the linked Apple Instruments Metal allocations trace. Trace the render pipeline to find per-frame temporary buffer allocation and texture reinterpretation, then verify with Instruments that the completed change avoids those recurring allocations while preserving rendering behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ios, macos, rust
- Domain
- computer-graphics, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100