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

[macOS] Fullscreen, minimized and hidden (cmd+h) leaks memory and blocks. #2659

Open
TheMDev opened this issue Feb 28, 2019 · 11 comments
Open

Comments

@TheMDev
Copy link

TheMDev commented Feb 28, 2019

  • GFX version: current master
  • OS:
    macOS 10.13.6
    macOS 10.14.3
  • GPU:
    Intel HD Graphics 5000 1536 MB
    Intel HD Graphics 6000 1536 MB
    ATI Radeon HD 4850 with 512MB of VRAM
    Radeon R9 M380 with 2GB of VRAM
    Radeon Pro 570 with 4GB of VRAM

This issue is related to: gfx-rs/wgpu#78

@ghost
Copy link

ghost commented Mar 1, 2019

Just to provide another data point, I'm able to reproduce this with the quad example on my machine as well. Minimizing the window or switching to another workspace will cause the memory usage continuously climb up at a rapid pace.

However, I can see the memory usage climb up (even though at a slower pace) even if I do nothing special, which seems to indicate that there's also another smaller memory leak (or several) in the Metal backend.

GFX version: cd49595
OS: macOS 10.14.3
GPU: AMD Radeon Pro 560 4GB

@JohnColanduoni
Copy link
Contributor

There is frequent output in the console when running the quad example in these situations:

SwapchainConfig { present_mode: Fifo, composite_alpha: OPAQUE, format: Bgra8Srgb, extent: Extent2D { width: 2048, height: 1536 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT }

Which indicates the swapchain is being continuously recreated (the responsible println! is here). This still shouldn't cause a leak, but it would also be best to avoid unnecessary swapchain recreations in these situations.

The cause of the swapchain recreation appears to be recreating the swapchain in response to a present error that occurs sometimes when the window is offscreen.

@fu5ha
Copy link
Contributor

fu5ha commented Jun 26, 2019

Could someone test if this is still an issue? It might be fixed by #2596

@ghost
Copy link

ghost commented Jun 26, 2019

I remember testing this after #2835, and I could still see the memory usage climb while the window was minimized, but this time it recovered as soon as the window was unminimized.

@kvark
Copy link
Member

kvark commented Jun 26, 2019

Could be addressed by #2863
Currently, it looks like IOSurface appear to be piling up and not freed in time.

@TheMDev
Copy link
Author

TheMDev commented Jun 30, 2019

I just got back from out of the country yesterday. Sadly it looks like the issues still persist. The first two times I tried to open it in full screen it crashed but the third time it did not crash but the memory usage continuously climbed up at a rapid pace. If you need any more information on the crash reports or more logs just let me know.

Commit: 47d5b5c

Crash Reports

@seivan
Copy link

seivan commented Aug 20, 2019

@termhn It is still there, but I am not sure if that patch you mentioned has been moved into wgpu master branch yet.

@ghost
Copy link

ghost commented Aug 21, 2019

I'm still seeing fullscreen windows leak memory when not visible, as in BronzeMtlRenderCmdEncoders seem to be building up rapidly, but are freed as soon as we switch back to the window. See issues #2899 regarding blocking and #2900 regarding performance. I wonder if #2899 is related to the encoders building up.

@kvark
Copy link
Member

kvark commented Aug 21, 2019

@aleksijuvani we are clearly not handling the case where a submitted command buffer doesn't get executed. If this is what happens on fullscreen, then it's clear how to investigate this.

@seivan
Copy link

seivan commented Aug 22, 2019

cmd+h and minimized is fixed with #2973
Fullscreen still kills the fps and leaks.

@kvark
Copy link
Member

kvark commented Sep 11, 2019

For the last problem, this choice makes it inefficient on Apple platforms. We should try to prefer "3" there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants