Search Unity

Xcode capture and Unity profiler reports different sizes for same texture.

Discussion in 'iOS and tvOS' started by tn0012, Jun 28, 2021.

  1. tn0012

    tn0012

    Joined:
    Aug 13, 2019
    Posts:
    5
    I have been researching texture memory sizes on iOS(iPhone SE)
    and I noticed that display sizes of textures are different on Xcode memory capture and unity memory profiler on same device.

    For more research, I created a simple project which contains 4 textures, each format are PVRTC RGBA or RGB.
    The first attached image is Xcode memory capture in which a texture `t4' is 128 KB,
    but the second attached image is unity memory profiler in which a texture `t4' is 11.0 KB.
    The `t4' difference does not look so small. What the causes of this difference?

    ios-texturesize-xcode-capture-gpu-frame-showmemory.png

    ios-texturesize-unity-memory-profiler.png

    Unity version is 2019.4.17f1. Xcode version is 12.5.

    There are many same cases in our production project, so it makes difficult to estimate total texture memory sizes.
     
  2. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    This is a "bug" in xcode. Several smallish textures/buffers can be packed into one "heap" (128 kb in this case) and then they will be reported to have this bigger size. I agree that this makes things more complicated (e.g. 171 kb texture seems to be "aligned" to 16kb memory pages, so it will indeed take more memory than we report), but there is nothing we can do about it (neither can apple to some extent)
     
  3. tn0012

    tn0012

    Joined:
    Aug 13, 2019
    Posts:
    5
    Thanks your rapidly answer.

    Is the Xcode bug only for the case that small textures that are able to pack into 128 KB?
    For my another analysis, a texture which is 512x512 pixels of ASTC 6x6 LDR format is reported 115.9 KB by Unity Profiler but 144 KB by Xcode, and it looks that the difference is not only from 128 KB packing of small textures.

    For our product, total memory consumption reported by Unity Profiler is far less than 1 GB (800 GB) but over 1.3 GB by Xcode (the application crashes by memory usage). so Xcode looks reporting more accurately than Unity Profiler about memory.
     
  4. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,457
    There is some memory that is not yet tracked by Unity's memory manager. IL2CPP internal memory is among these, that is, not the managed heap with all the C# objects on it, but the Type Metadata info, which is, among other things, a result of generics and just using a certain amount of types.
    Native plugins also currently have no way yet to report how much memory they used back to Unity, so their memory is also not tracked by Unity. The gap between what Unity's Memory Manager knows about, and what's actually used is something we want to close.

    So, I don't have any specific input on that texture, but I think the gap from 0.8 to 1.3 GB is likely to a bigger part formed by such gaps in the memory manager rather than individual texture sizes being considered or calculated differently between the OS/XCode and Unity's tools.
     
    tn0012 likes this.
  5. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    Yes, i was referring explicitly to the case of "look, you have several smallish textures we can pack into one heap/page", as driver tracks memory on virtual memory pages.The difference between total memory reported by xcode and unity can be due to a lot of things indeed

    That's a good point. We calculate the texture sizes "naively", in this case we directly calculate how many 6x6 blocks are needed for 512x512 texture and multiply by 16 bytes per block. Now, this is a perfect estimation for a binary data size we need to store in resources and then read when creating texture but, obviously, we can NOT know how many memory will driver use (and as you see have seen, it might be different, and for a LOT of reasons)
     
  6. tn0012

    tn0012

    Joined:
    Aug 13, 2019
    Posts:
    5
    Thanks for clear answers.

    I'll check another factors you mentions.

    I'll be careful if check individual texture sizes on iOS, thank you.
     
  7. tn0012

    tn0012

    Joined:
    Aug 13, 2019
    Posts:
    5
    1. Significant difference between Xcode and Unity Profiler on crash.

    For inspecting memory usage on crash timing, I created a simple application that creates 512x512 texture of 4 different formats every frame.
    On iPhoneSE(Memory 3 GB) Xcode and Unity Profiler reports as followings on crash:

    - Xcode (instruments): 2 GB
    - Uniry Profiler: 1.13 GB

    They are not small difference. Application creates textures and does no any other significant task, so this difference looks not to be from memory manager or packing size difference.
    All textures are created by code
    Code (CSharp):
    1. new Texture2D()
    so readable object looks to be one of causes of difference between Xcode and Unity Profiler.

    TextureMemoryCrash.png

    TextureMemoryCrashXCode.png



    2. Unity Profiler reporting inconsistently case.

    In the case that another test application which creates Meshes instead of textures, Unity profiler reports odd summary in which Used Total memory is 1.03 GB but Meshes is 1.86 GB (greater than Used Total).

    UnityProfilerInconsistentReport.png

    In both cases, Unity version is 2019.4.17f1 and Xcode version is 12.5.
     
  8. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,457
    You mean all the textures are Read/Write enabled, due to being created from code? That causes a copy of the texture memory to remain on the CPU side for access, and one on the GPU for displaying, if they are being used. That might explain the near perfect split 50:50 between "Unity" and "GfxDriver", but doesn't yet tell me that it is really wrong.

    That is really hard to judge from these high level numbers and would be more meaningful when filtering to just Textures. However, you could take a detailed snapshot on the Unity Profiler to at least see how much ExecutableAndDlls took up, to close some of the gap to the 1.36 GB of used Heap memory as reported by XCode.

    Because the All Anonymous VM Memory here isn't a Virtual Machine memory as in Mono/IL2CPP but Virtual Memory that the OS reserved for the app and that you have no direct control over and Unity no knowledge of.

    So, this looks to me to be very much in range without more details.

    Regarding the second case: we fixed a bug in the memory size calculations for meshes that was backported to 2019.4.21f1. Could you please update the test case to that version or the latest 2019.4 one and check again? And if the mesh size reporting and Used Total remain this much at odds, it's definitely a bug.
     
  9. tn0012

    tn0012

    Joined:
    Aug 13, 2019
    Posts:
    5
    Sorry for the delay.

    Using Unity 2019.4.28f1 and Xcode 12.5.1, I checked cases where a test program creates a large number of textures and meshes.
    • For textures, there was not much difference between Instruments and Unity Profiler.
    • For meshes, the difference between Instruments and Unity Profiler was large. Also, Unity Profiler's report was wrong in that the memory size of the mesh was larger than the overall memory size.
    The attached table shows the results.
    The first row is the result of the texture test and the second row is the result of the mesh test.
    The first three columns are the OSX Instruments results, and the remaining columns are the Unity Profiler results.
    For the mesh test, Unity Profiler may be wrong in the following ways
    • The total memory size of 349.7 MB is too far away from Instruments' 1.21 GiB.
    • The size of "Meshes" is larger than "Used Total" and "Reserved Total".

    compare-unityprofiler-instruments.png
     
  10. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,457
    Hi @TaketoshiNishimori,

    That looks indeed buggy to me, could you please file a bug report for this via Help > Report a Bug?