Hello,
We are rendering our game manually to render textures and displaying those on a realitykit object using a shader graph shader. We have noticed our app crashing within a few minutes due to a memory leak. From profiling we noticed that this comes from GPU memory allocations. By making a GPU trace in XCode after the app has been running for a while, I’ve noticed that there are a ton of 4mb “ScratchBuffers” allocated.
Looking at the call stack of each of these buffers, they all come from the same origin which is PolySpatialRealityKit.CopyRenderTexture.
Is there anything specifically related to render textures to be aware of or is it an issue that needs to be solved within PolySpatial? We noticed it leaks faster when reloading a scene that contains camera’s that render to the textures.
On further investigation it looks like this only happens when a camera rendering to a rendertexture is rendering particles. I’ve managed to reproduce the memory leaking very fast in an empty project. I’ve submitted an indicent report with the project: IN-62760
Hi there,
We also have the same issue. We’re rendering to a 4K texture for each eye, and the RenderTexture objects are static in the project, not allocated on our side each frame or anything. We’re losing tens of MB per second, and running out of memory within two or three minutes.
Note that there are other leaks too, on a project that otherwise has no leaks on other Apple platforms. If I disable render textures entirely, we’re still losing about 5MB/s.
Thanks in advance,
-Jack.
Are you also using particle systems, and seeing this leak specifically with those? Either way, it would be helpful if you could submit a bug report reproducing the issue and let us know the incident number (IN-#####).
I believe that this memory leak in particular is related to an issue that we fixed in core Unity in the latest release. If you upgrade to 2022.3.15f1, you should no longer see this issue. At least, I didn’t see it when I tested your repro project with that version.
Yes we were, but I’m pleased to report back that upgrading from 2022.3.11f1 to 2022.3.15f1 seems to have fixed the issue, thanks!
