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

Created on 28 Feb 2019  路  11Comments  路  Source: gfx-rs/gfx

  • 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: https://github.com/gfx-rs/wgpu/issues/78

Metal request OSX ready for work bug medium

Most helpful comment

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.

All 11 comments

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: cd495957d58adbc900a22232a7b4ce0e9b178900
OS: macOS 10.14.3
GPU: AMD Radeon Pro 560 4GB

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.

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

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.

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

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

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

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.

@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.

cmd+h and minimized is fixed with https://github.com/gfx-rs/gfx/pull/2973
Fullscreen still kills the fps and leaks.

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kvark picture kvark  路  3Comments

norru picture norru  路  4Comments

kvark picture kvark  路  3Comments

grovesNL picture grovesNL  路  3Comments

mjadczak picture mjadczak  路  4Comments