Hey, I discovered that with UE5.8, when running an application with uncapped frame rate with “-renderoffscreen”, there exists a shared GPU memory leak.
When debugging it with the CVar t.MaxFPS to cap the framerate the leak stops. This is visible in the image “Memory_Leak_Visualization”.
The memory leak is also visible if t.MaxFPS is capped at a rate just above the current fps, so it doesn’t need to be unlimited.
The leak is one issue, but another is that the application uses also way more memory on startup.
I tested without “-renderoffscreen” directly after the leak test, so you can see the comparison in the image “Without_RenderOffScreen”.
It gets more clear with the two images “With_RenderOffScreen_TaskManager” & “Without_RenderOffScreen_TaskManager” though.
Here I took a screenshot of the task manager right after starting the application. So the leak itself should have not affected the general memory consumption that much.
Create an empty project or use the attached reproducer project and package it as Development or Shipping, doesn’t matter.
Open the task manager or performance monitoring.
Run the application with the startparameter “-renderoffscreen”, optionally also with “-log” & “-newconsole” for testing.
The frame rate should be uncapped per default (t.maxfps 0) so you should already be able to see the shared GPU memory grow. As this is shared memory you’ll also see it in an increase in the system memory.
Optionally: Run the application without “-renderoffscreen” and compare. Not even does it take only a fraction of the memory on startup, but also the memory leak is gone.
Hey Martin, I did some more investigation and also found out the following:
It only appears to leak once a certain resolution is set. I believe it starts at around 4k. Therefor it is also affected by the screenpercentage. The higher the resolution the bigger the memory leak
I’ll try to find out more about it and let you know, we need this fixed or a workaround.
We also found out that this issue only appears with an empty level, in which no rendering occurs due to no static mesh being in the scene.
Once we add a simple cube in the scene it does not leak anymore, even though there are no lights.
As a workaround we place an invisible(transparent) plane which will always be rendered in the viewport (never culled).
This however doesn’t fix the initial memory increase that was also related to the leak. In the empty reproducer project I get around 1,5gb system memory usage on startup without “-RenderOffScreen”, but with it the process uses ~3gb system memory.
The workaround does not seem to work consistently. We have a level with static meshes being rendered, but the leak is reappearing.
And furthermore this workaround won’t work with out test automation. Between the functional tests there are times when no content is loaded and it is leaking again.
We need a fix / proper workaround to address this issue.
In our tests we saw that within few minutes the allocated memory reaches multiple GB quickly, ultimately crashing the application.
[mention removed] is there any update from your side?
The bug has been assigned but the work has not started. I asked that we consider fixing this bug in a 5.8 hotfix but can’t make any promise.
I recommend capping the frame rate using t.MaxFPS. When using renderoffscreen, it removes some of the sync points between the CPU and the GPU. The current suspicion is that the GPU cannot keep up with the rate the CPU is scheduling work so it accumulates. This was helpful the last time we had a similar issue.
