Hello there,
I have been working for a while with Texture Arrays, using them as flipbooks withing shaders to make 2D animations.
Past months, I have run into an issue when the application crashes on start. After weeks of experimenting, I filled a bug report.
Then, Unity contacted with me and stated that the actual issue was the PC run out of virtual memory (and the bug was that Unity did not prompted any error when this happens). This confused me, as the texture arrays I was using were big, but not that big (something around 180 mb). I then checked the memory profiler, and to my surprise with just two objects using the arrays in an empty scene, texture memory was already around 2-3 gigas. How this relates to virtual memory? AFAIK, the “memory” mentioned in the profiler is RAM.
The arrays are just asigned to the material as variables and sent to gpu, we dont do any work with them in C#.
Could be due to compression format? Unity is kind of obtuse when explaining what is happening with memory, and my knowledge is kind of blurry in this area.
Hi,
Do you have a link to the original bug case ? It might contain some more context for me.
We did fix a bug a few months ago where sometimes CPU texture memory wasn’t freed after uploading to the GPU.
But that was only possible in edge cases AFAIK.
This was case 1344987.
Just as an FYI for future issues: The Memory Profiler Package has a Memory Map view that shows where the allocations sit in Virtual Address space that might make this blackbox a bit lighter. A high churn (allocate object to full region → new region is asked for from OS, free object, release memory region, rinse & repeat) of managed (or, less likely but similarly possible, native) memory can lead to ever higher virtual memory addresses being used, until you run out of them.
Version 0.4.0 of that package, to be released hopefully this month, comes with a set of improvements and fixes to that memory map.