Introduced in 2020.1 is a regression regarding the AsyncGPUReadBack Requests where the memory is never released causing a rather considerable amount of ram per frame to be accumulated. After 15 seconds, my unity instance was consuming more than 8GB of memory.
A similar problem, most likely caused by the same. When using the unity recorder package in movie mode, even in an empty project. All RAM and swap file loaded up to 80+ gb. Video recording was cut off each time at 4000-5000 frames with a critical error of the editor.
Tested in versions unity 2020.1b2, b5, and late alphas. Recorder versions is 2.1.0 and 2.2.0
With a fix that has been readied for a10 for a while, I was curious as to what were the limitations of porting it back to 2020.1 versions were?
I also find it interesting a fix was found roughly around the time 2020.2a7 came out, but was slated for a10? Any reason for this?
There is something very similar happening in 2019.3.12. I have memory leak once the editor loads and memory wont get released. I sent 2 projects and i got no answer or if there is any investigation. Since i’m working in big open world, i’m able to be in the scene like 6 minutes, then everything crashes and i can start all over again… It never encountered anything like that before the port to HDRP…
Hi!
I’m facing the same exact issue when using Unity 2019.4.0f1 or 2019.4.1f1.
Using RequestToNativeArray as julian suggested is an effective workaround, though.
This is happening in 2019.4.38.
Telling someone to upgrade to the latest version of unity to fix it defeats the purpose of LTS.
This is a highly important issue as compute shaders do not release RWStructuredBuffer’s from memory.
I’m not sure what you’re referring to exactly regarding being told to upgrade to latest Unity - I can’t see a message about that.
But I suppose I’m about to say a version of it… so maybe you are preempting me! 2019.4 is no longer supported - our current commitment to LTS is to support each one for 2 years. There will not be any more patches to 2019.4. So at this point you would need to upgrade to at least 2020.3 to get this fix.
To perhaps preempt you - this isn’t the place to discuss how long we support each LTS - you could probably spin up a thread in the General Discussion forum if you wanted to talk about that further.
I totally understand your point and generally agree with it - but in this specific case the bug is almost 3 years old, and should have been addressed for 2019 as well, since it was early 2020.
Ignoring it for 3 years and then mark it as “now unsupported” is not the approach we’d like to see for future issues.