(Case 1339307) Profiler: ASTC texture memory cost not correct

EDIT: Turns out this seems to be a bug, so here is the report:
(Case 1339307) 2019.4: Profiler: ASTC texture memory cost not correct

I’m using Unity 2019.4.20f1 and I’m testing on an Android Samsung Galaxy S6. I’m using the texture format ASTC 8x8 which SystemInfo.SupportsTextureFormat returns true for.

Looking at the Profiler, I find memory costs for those textures that don’t make sense to me. Perhaps you can tell me why some are 5.3 MB and others are 356 Bytes where all of them should be 1.3 MB according to the editor.

Here are two screenshots showing two different textures, both have the same size and format, but somehow a different memory footprint:

Please note the editor displays 1.3 MB.

  • Why is it showing 5.3 MB when running on a device?

  • Why is it showing 356 Bytes when running on a device?

  • Which cost is correct, 5.3 MB or 1.3 MB?

Both, but the inspector only gives you the file size right now, not the size it will have in memory on the currently targeted platform.

Are the Advanced settings also exactly the same? And is the smaller one of them maybe mipmapped and only loaded in as a smaller version or is there any atlassing going on, that could break the compression on the bigger one? Or is the bigger one Read Write enabled?

1 Like

Thank you for the quick reply, that makes sense with the 1.3 MB vs 5.3 MB I guess. The 356 Bytes is still odd, I hope I have time to investigate this further in the next days. I’ll keep you updated :wink:

1 Like

No it doesn’t…? It makes zero sense.

1.3MB sounds about right for ASTC 8x8, and that should be the same for storage and memory. Why does it quadruple in size when loaded onto the device’s memory?

But assuming that’s somehow correct, then the question becomes:

Why does a 2k ASTC 8x8 take x4 times more memory (5.3MB) on a device that supports ASTC?

2 Likes

I just glanced over an ASTC guide and I think you’re right. If I understand the documentation correctly, it should be this:

  • Each block has a fixed cost of 128bits or 16bytes.

  • A 2048x2048 texture with 8x8 blocksize therefore has 256 blocks in each direction, making a total of 65536 blocks.

  • 65536 blocks * 16bytes = 1048576 bytes or 1MB

  • Adding 33% for mipmaps, we get 1398101bytes or 1.33MB, this is what the inspector displays

If the device doesn’t support ASTC, I think Unity would output the typical “Texture format ASTC not supported, uncompressing” warning. I don’t see any of this.

An uncompressed 2048x2048 texture with mipmaps should cost 21.3MB and not 5.3MB, I guess. 5.3MB makes sense for a 2048x2048 texture in 8bpp with mipmaps.

1 Like

So I remembered the following from a few years back:

I wanted to see if RenderTexture memoryless was working on iOS, and ram usage was being weird on Unity’s profiler (and different than XCode).

After submitting a bug report and a bit of back and forth, I got the following reply:

This seems to indicate that the profiler ram usage numbers are estimates and not hard actual numbers.

So my personal conclusion is that Unity does not account for block size and assumes it’s ASTC 4x4.

(not sure why the memory profiler numbers are all estimates… it kinda makes the memory profiler to be of very limited usefulness, but I guess there are reasons it’s like that)

1 Like

This would explain the 5.3 MB actually. I’m trying to reproduce this in a new project later today and submit a bug-report for that.

1 Like

Estimate is kinda the wrong word for it. Native UnityEngine.Objects each implement a method used by Profiler.GetRuntimeSizeLong() and the memory Profiler. That method calculates the size in memory based on all it’s settings and buffers but sometimes someone changes the way they behave in memory without adjusting that calculation or the calculation is plain wrong. The memory profiler doesn’t have the same access as a hardware/platform specific profiler has and therefore relies on that calculation for the native sizes. We have plans to build tests that validate the memory size calculation is and stays accurate per object type but given that access problem, it’s not a trivial test suite to write and other issues have taken precedence so far.

1 Like

It would be nice to have this explanation included in the docs somewhere. Over the years I’ve had a variety of issues with Unity and different tools reporting different things for ram usage which made the whole thing confusing.

2 Likes

I reported the following bug:
(Case 1339307) Profiler: ASTC texture memory cost not correct

1 Like

The 356 Bytes textures still remain a mystery to me. I can’t seem to reproduce it in a new project. Perhaps it’s related to asset bundles. I guess I’ve to dig deeper :frowning:

The same issue
Any profiling method say that Textures take 0.5KB and all textures in player take 11 MB
This is on last Unity 2020.3.11f1 before that on Unity 2020.3.8f1 textures was fine (I guess). May be the was wrong but no one can see it :slight_smile:
Before 2020.3.11f1 incorrect memory consumption was only for Shaders and this is from 2091.x.x
Unity see shaders consuming about 50MB while they actually consume around 600MB but on Android all 550MB go under Private Other section in android logcat memory panel.

On iOS every thing work fine for shaders and textures, so second year we can use only iOS builds to see memory consumption of unity.

@MartinTilo can you say something about when case 1339307 planned to be addressed, may be link to public issue tracker for this bug and may be fixes for other profiler failures like unable to connect to player, unable to see sheder memory consumption… What we can expect in Unity 2021.2f1 and what we can expect to be backported on 2020, 2019?

Thanks :slight_smile:

1 Like

https://issuetracker.unity3d.com/issues/memory-profiler-different-sizes-are-shown-for-astc-textures-between-the-texture-importer-window-and-the-memory-profiler-window-1

1 Like