texture_set_shrink_all_x2_on_set_data and/or VRAM counting in editor doesn't work

[mnn]

Godot version: 3.2.1

OS/device including version: Linux 64b, NVidia 2080ti (440.82), GLES3

Issue description:

I have a following setup: App loads Main which loads a specific level. In case of low_res the texture_set_shrink_all_x2_on_set_data is called in App._ready before loading starts (App uses ResourceLoader.load_interactive, Main uses resource_queue script from docs).

Mode	low_res	VRAM from nvtop**	VRAM from editor*	biggest asset in VRAM from editor
exported	yes	3502MB	-	-
editor	yes	4083MB	16.00 EiB	35.61 MiB
exported	no	6514MB	-	-
editor	no	6514MB	450.2 MiB	35.61 MiB

*: Debugger -> Video RAM -> Total
**: VRAM per game process

Total VRAM in editor seems to be completely broken (EiB? 450MiB vs 6514MB from nvtop?), so I will ignore it.

If hi res version occupies ~6.5GB, why isn't low res version occupying quarter of that value (half size in two dimensions)? 53% vs expected 25% is a big difference. Maybe it's related to a VRAM compression (which we use)? Why is biggest asset (it's from a level) in both cases of same VRAM size? It seems to me that either "VRAM usage by resource" is broken in editor as well or texture_set_shrink_all_x2_on_set_data isn't working for all assets. I don't know how to proceed further in troubleshooting this.

Unfortunately I cannot share the project.

[mnn]

Just updated to 3.2.3, issue persists. Now is 16.00EiB incorrectly reported as used in editor even without low_res.

[clayjohn]

Im seeing 2 distinct issues here:

1. You think your textures should be taking less VRAM
2. The editor isn't properly reflecting how much VRAM it is using.

Regarding 1) I am not convinced that shrinking your textures should result in 1/4 the VRAM usage because of the way that VRAM compression works. It is very likely that the larger textures achieve a better compression ratio which offsets the benefit of reducing the size of your texture. Further, textures are not the only resources that occupy VRAM. So while 6514 mb seems to be your max VRAM usage, there is no indication of what part of that is used by your textures and what part is used by meshes, objects, and Godot internal data.

Regarding 2), I don't know how Godot gathers VRAM usage, but it is clearly off. Further, as far as I know, it is impossible for an OpenGL app to capture VRAM usage as accurately as your hardware vendor's tools, so if you are really concerned about VRAM usage, its probably best to continue relying on NVTop anyway

[mnn]

1. Yes, it's possible because of compression I don't see too big benefit. But I find it rather suspicious that 2x times smaller texture hits exact compression ratio to perfectly balance out downscaling (35.61 MiB with low_res on and off). Our game is 2D, we don't use any meshes, skinned animation nor lights (not sure what everything else can use VRAM).

2. Overall there is something strange with assets tracking in Godot. I just tried a completly empty scene to run with Play Scene (so nothing else from our game should be loaded except a cursor), but I see a lot of items in Video RAM tab - 128. So minus the cursor, from where are coming that 127 textures? And majority of those items has missing resource path, how am I supposed to troubleshoot that...

Empty scene VRAM resources:

[Calinou]

@mnn Can you (or anyone else) still reproduce this bug in Godot 3.5.1 or any later release?

If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

[mnn]

Yes, VRAM use and reporting is still weird. Tested with 3.5.1 and GLES3. It's a different project than in OP, but still uses VRAM compression at 0.7. Those textures are most likely uncompressable, since it's just a noise.

shrink (low_res)	VRAM from editor	VRAM from nvtop
false	36.6MiB	797MiB
true	35.1MiB	791MiB

I have to say, the texture_set_shrink_all_x2_on_set_data is pretty much useless, since it looks like it ignores compression. On our main project we aren't using it, because it doesn't lower VRAM usage, only makes things look worse. We had to implement a custom solution - swapping frames in AnimatedSprites (four levels - animated sprites group, part [1 animated sprite], animation and quality) and a bunch of scripts to prepare lower resolution assets (raku + imagemagick), so we can use compression on them and actually lower VRAM usage, not just make everything blurry without any benefit (maybe it's lighter on GPU, but that was never our issue).

MRP is minimal in code, but probably not in size. It has half a gig, you have been warned.
I put it on mega, since GitHub only allows 25MB: https://mega.nz/file/5RonQK7b#13XzPEwcC9SFTHanwJS8ApxEQSoJE_TZm4mwOEuZlmk

Edit: The unhelpful nameless textures are still present (this is from MRP)