Closed Matt-Is-Confused closed 8 months ago
Could you quickly check other examples of ours, and also a few wgpu
examples? This is definitely an issue, and that will help us narrow down what's causing it.
I forgot to check wgpu for an issue that matches this problem. This Issue exists but it looks to be a frame timing bug. Could be related.
I have collected some release mode data, each is the most memory expensive call stack.
Edit: Tried to make it more presentable
More examples
We are having the exact same issue: Unfortunately, we haven't found any fix for it yet. I'm also not sure this is the same issue or not as https://github.com/gfx-rs/wgpu/issues/1783 There does seem to be a timing element to it. If I, for example, enable MTL Api Validation and Shader Validation in XCode's diagnostic settings, the issue doesn't occur. Also, when putting a breakpoint near the place where all the memory gets allocated (via shown callstack), it sometimes also doesn't happen. FYI, for us it's an iOS (iPadOS) application. When running on a simulator (on a M1, so the sim is also arm64), the issue doesn't occur.
The linked issue in wgpu seems to be resolved. Is this still an issue?
It has been quite some time so I don't have the ability to retest this. From what I remember this was a problem with mac frame management in certain window modes. If wgpu has closed the issue it is probably safe to assume it is no longer a problem in Bevy.
Bevy version
Bevy 0.6
Operating system & version
MacOS Monterey 12.1
What you did
Profile release and debug of the code from the 3D scene example (this one). The tool I used was the Instruments allocation profiler.
What you expected to happen
My assumption is that a basic example would not use that much memory.
What actually happened
The pass node stack trace show excessive memory usage of about 500mb. In my testing it seems that in release the problem is exaggerated a few times over in to the range of GB.
Just in case I ran it without the profiler and it still uses about 700mb debug and 5gb release according to activity monitor
I am not sure if this a bevy problem or a wgpu problem.
Additional information
Release mode stack trace
Screen cap of pass node calls
I can provide / gather any other data needed