Search Unity

Texture2D usage in the Memory Profiler uses significantly more memory on Mac

Discussion in 'Editor & General Support' started by NecroBroncoTech, Nov 26, 2020.

  1. NecroBroncoTech

    NecroBroncoTech

    Joined:
    Sep 6, 2019
    Posts:
    9



    In both snapshots I have opened the exact same project and the exact same scene in Unity. While there are minor differences in other things on the Mac the Texture2D usage skyrockets to 2.83GB from 455.2MB. Both projects build settings are set to IOS with the same quality settings but on my PC the usage is significantly lower.

    The big problem on the Mac is that some textures end up using way more memory than the file size. In one example a file is 2.7MB in the project folder when selected in the editor but uses 24MB in the profiler and another that is 0.7MB uses 6.0MB. On the PC the memory usage matches the file size, so clearly something is going wrong when I import the project into the Mac version of Unity despite the fact that when I select the file and view it in the inspector the file size is normal. It clearly has an effect on my builds too since the memory usage should be fine for an iPhone 7 but some scenes, including this one, crashes even though it should be using less that 1.4GB of memory.
     
  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    Hi there,
    Files can be compressed on disk but have a different size in memory. Have you had a look at the import settings on some of these textures that the memory Profiler is showing a size change for? Are they read write enabled? have you tried different compression settings? MipMaps enabled?
     
  3. NecroBroncoTech

    NecroBroncoTech

    Joined:
    Sep 6, 2019
    Posts:
    9
    It seems to do this for every single texture, it even does this for UI elements as well. I tried a few things on one texture:

    1. The compression was set to PVRTC 4 bits by default. In memory it was 24MB even though the actual size in the inspector is 2MB. Generate Mipmaps were left on.

    2. I turned off Generate Mipmaps, the file size in memory is now 18MB. Better, but still significantly higher.

    3. Then Override IOS checkbox is ticked with the default settings of PVRTC 4 bits, Mitchell resize algorithm and compressor quality on normal. Still 18MB.

    4. I changed the format to ASTC 8x8 and it is down to 17MB. The file in the inspector is now 1MB.

    That has improved things but the file size is still significantly higher, it's as if the textures are being read as uncompressed TIFF files (they are PNG files) and Unity is trying to compress them but is struggling.
     
  4. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    Well, once loaded into memory the textures need to be in a format that the GPU can process, which is an entirely different beast than how big a e.g. .png is on disk. Have you had a look at this manual page and the tables on it? Additionally this and this page might help to find the optimal settings. Given the bpp ratio you can calculate the approximated memory sizes that you can expect too, but confirm them with the Memory Profiler.

    One question you didn't answer yet is if these textures are Read/ Write enabled. Because that'd normally double their memory usage as the CPU needs to retain a copy for CPU access while the GPU has it's own copy. The memory Profiler doesn't yet differentiate between VRAM and RAM usage.
     
  5. NecroBroncoTech

    NecroBroncoTech

    Joined:
    Sep 6, 2019
    Posts:
    9
    I was using 8x8 with ASTC which has a bpp ratio of 2 according to this link you shared. I changed the ASTC setting to 12x12 with a lower bpp ratio of 0.89 but it only dropped the file size in the memory profiler down to 16.4MB.

    I just checked and I had Read/Write enabled turned off. Turning it on didn't increase memory usage though, it was still 17MB.

    I just did some investigation and I found out what is going on. The 17MB figure seems to be how big the file size is on disk but I changed the max size from 4096 to 2048 to lower it down since it was too big (it is for giant statue but I may need to lower it even more). The file size in the memory profiler seems to be interpreting the file size as if it is around double the resolution, for another file it was 1.7MB on disk but coming up as 6MB. But when I changed the quality setting so the textures were half resolution it was 2MB.
     
    Last edited: Dec 1, 2020
  6. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    The sizes the memory Profiler gives you for these are the sizes Profiler.GetRuntimeMemorySizeLong(myTexture) would give you. The result is indeed coming from a calculation in the native code instead of a "true" measurement so there can be bugs with it but 4096x4096 = 16MB at a 1bpp ratio in my calculations so depending on what other settings are playing into this, 17 MB seems reasonable to me.
    I'm not sure where you are seeing the doubling in size and no, the sizes in the memory Profiler are sizes in RAM, not on disk, those are two different sizes that have some correlation but can be quite different.
    Half the resolution means 4 times lower texture sizes because the resolution you are halving is the length of an edge, while the texture size is edgeLength x edgeLength.

    And a 4k Texture in mobile seems rather much indeed.
     
  7. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    Then gain, some UI textures or Sprite Atlases can reach hat size too so, it might be appropriate but you need to plan your memory budgets accordingly and might need to save elsewhere.
     
  8. NecroBroncoTech

    NecroBroncoTech

    Joined:
    Sep 6, 2019
    Posts:
    9
    Sorry I wasn't clear, the size is 17MB in the memory profiler when I changed the max size to 2048 from 4096. It was already set to that and I was getting 17MB despite the file size being that at full resolution on disk (hence the size of the file is as if it is double the resolution), so it should actually be just above 4MB. This is true for all of my textures, they are all around 4 times as large size wise as they should be for IOS. I understand the readings may be different due to how the GPU interprets the file but it shouldn't be increasing the file size by 4 for everything.
     
  9. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    I'm still not sure I can entirely follow along what files with what setting result in what file and memory sizes.

    Let's ignore the max resolution setting for a bit and just focus on the resulting resolution, because a 2k texture with a 4k max resolution setting still results in a 2k texture in memory so that's the relevant number and not the setting.

    So do I understand it correctly that you have a 2k resulting texture resolution that takes 17mb in memory? If so that sounds like the compression is at 4bpp ratio or one at 2bpp with Read/Write enabled or some other setting that causes doubling? Could you maybe share screenshot of your texture importer settings and the resulting sizes, in memory?
     
  10. NecroBroncoTech

    NecroBroncoTech

    Joined:
    Sep 6, 2019
    Posts:
    9


    Here is a screenshot of the texture. Originally 4k, it is set to 2k Max Size in Override for IOS with ASTC 8x8 compression. Generate Mipmaps is off, Read/Write enabled is off and it claims at the bottom it is only 1.0MB in size but when I use the memory profiler it comes up as 17MB in memory.
     
  11. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    That's the file size on disk. We had plans to show both the file size on disk and the size this has would result in, in memory but depending on the build you'll make, it would be a different result and it isn't always possible to calculate that ahead of times and questionable what the display should be based on: The current Editor OS, the selected override tab, the Project's currently selected build target?

    Are you seeing these 17MB in the Memory Profiler when taking the memory snapshot from the iOS device, or when taking the snapshot from a Mac Standalone build or the Mac Editor? If it is from an iOS device, what device is that? is it one with an A8 chip (2014) or above or an older one?

    My reason for these questions: 16MB would be the uncompressed size of a 2k 32 bit RGBA texture (i.e. 32bpp), with the additional 1MB possibly coming from the original compressed data. In other words, it looks as though the texture has been uncompressed on load, likely due to some compression format incompatibility.
     
  12. NecroBroncoTech

    NecroBroncoTech

    Joined:
    Sep 6, 2019
    Posts:
    9
    Mac Editor. The first screenshoot in the first post of this thread is the PC Editor.
     
  13. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,751
    That texture is using ASTC, which I'm not sure is natively supported on Mac. When that happens, the textures are decompressed via software in the editor so you can actually see them. This could explain the disparity in memory usage in iOS builds versus the Mac editor.
     
  14. NecroBroncoTech

    NecroBroncoTech

    Joined:
    Sep 6, 2019
    Posts:
    9
    When it is set to PVRTC it's actually higher, and the disparity is between the PC Editor and Mac Editor in the first post. I'm hoping this is just a Mac issue with the numbers being way off compared to running on IOS but the one time I made a build some scenes didn't even load due to using too much RAM even though they most used less than 1GB of memory on the PC Memory Profiler, with the first picture I posted being the worst scene at 1080MB (that has since been reduced to under 800MB at high settings). The phone I am testing on is an iPhone7 so around 1GB should be fine but at the high end.

    Obviously I have learned from this thread there will be a disparity which I have already been working on to compensate for but clearly the difference is massive and something strange is causing it.
     
    Last edited: Dec 10, 2020
  15. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    Well, that explains it. According to this list, ASTC is not supported on any desktop platform, so those textures would get uncompressed in memory. You always need to check your memory usage on the target device or everything could be off.

    And PVRTC is pretty much only supported on iOS or tvOS (and android devices with Imagination PowerVR GPUs), so that would also lead to decompression. If you chose a PVRTC option with alpha channel, or the textures are non-power of 2, that could also explain why it might end up worse, as it would uncompress to RGBA32, and not entirely sure what would happen to a non pov2 texture.


    What is causing it and explaining it is that if the compression format isn't supported, the texture will be loaded into memory uncompressed which results in mathematically logical sizes that we just aren't used to think in for image formats anymore because we're used to handling them in compressed formats most of he time.
     
    adamgolden likes this.
  16. NecroBroncoTech

    NecroBroncoTech

    Joined:
    Sep 6, 2019
    Posts:
    9
    Sorry for the extremely late reply but this was it, the numbers were way off but when I tested it on the target device the memory usage was close to what it should be. Thank you so much for your help, it really helped narrow down the problem so it's good to know that the memory profiler should be ignored if it does weird things like that and just test on the target device.
     
    MartinTilo likes this.
  17. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    Thank you or confirming, just a minor correction/clarification ;)
    ... in the Editor, while looking to optimize memory usage in build.

    It's not like the Memory Profiler is lying, it's telling it how it is. It's just that editor usage can differ from standalone usage and usage between platforms can differ wildly as well ;)