Vulkan: WorldEnvironment node leaks 2.85GB of render target VRAM when used (due to high sky radiance size)

[Griefchief]

Godot version

master ( 29492f9 ) godot 4 alpha13

System information

Windows 10, RX 590 and probably 2080 TI confirmed, Vulkan, AMD Driver 22.5.1

Issue description

VRAM ussage of Render Targets balloons to 2.85GB VRAM in editor or in game until the scene is closed. Causes VRAM into Shared RAM into hard drive related stutters-blocking of framerate under ideal conditions. Might be related to procedural sky settings, does not seem related to SDFGI or other settings.

.

Steps to reproduce

1. Add WorldEnvironment Node to an empty scene
2. Create a parametric sky, and or other settings that might trigger this leak as in image. SSAO, SDFGI etc can be turned off.
3. Simply opening the scene in editor will cause the VRAM leak, closing it will resolve the leak. Can be monitored via Win 10s Task Manager Performance Tab/Graphics card.

Minimal reproduction project

WorldEnvVRAMIssue.zip

[Griefchief]

Directly related to radiance size 2048 in settings for the sky radiance... Any other setting reduces it significantly.

[Griefchief]

P.S. Maybe it's not a bug, but this setting is dangerous. This setting should be guarded somehow if possible.

Running the scene with editors "run_current_scene" button will double VRAM beyond 8GB, push it into shared RAM - choke ram on a 16GB machine and push into HDD paging... considering it randomly takes more memory when it runs off into RAM like that, from 2 to 6GB ram, i suspect it might be a leak of some kind.

[huisedenanhai]

It seems to be a configuration issue. The sky creates a giant texture cube array based on user supplied radiance size, which eats 2GB VRAM in your case (RGBA16F, 2048x2048x8x6, with full mipmap).

I don't think the sky radiance cache need such high resolution in practice. The content generally has very low frequency, and the aliasing closing to horizon can be fixed with smart uv remapping according to a newer paper, section 5.3. I'm not sure if godot supports such custom uv remapping for sky lut size optimization.

I haven't dig into godot's sky implementation, but the radiance cache looks unnecessarily large to me. I feel it's fine for most cases with one sky panorama for high quality background drawing, and a single layer cubemap with 5 mipmaps for IBL, each mip stores prefilterred irradiance with different roughness.

[Zireael07]

Whoa, why do you need 2048 radiance size? (And why isn't it capped lower, I seem to recall many discussions about IGPUs freezing even with 1024 or 512)

[Griefchief]

I was playing with Sky settings and set it randomly, for who knows what reason, maybe I saw low resolution in SDFGI or SSAO or whatever. Ah, right, building windows look slightly nicer with 2048, as they happen to be reflective in the original .gtlf/blender shader and it translates into .gtlf file.

[Griefchief]

It doesn't advertise eating 2.85 GB VRAM, 2048 feels like it should take 16mb or 64 at worst.

[Griefchief]

And yes, I saw the tooltip, and either ignored it, or never saw it when setting it. At least i did not see an issue when setting it...

[Griefchief]

We need to measure this differently, or with an additional number in the setting mentioning VRAM size, i feel.

[Calinou]

Radiance sizes above 512 should probably not be exposed, like in 3.x. These take a lot of time to generate, which can noticeably slow down loading on slower/mobile GPUs (or even cause crashes as mentioned above).¹

Also, it's very unlikely that radiance sizes above 512 will make any meaningful visual difference (outside of pixel peeping, that is). If you need very sharp reflections, chances are that you'll be using ReflectionProbes anyway.

(And why isn't it capped lower, I seem to recall many discussions about IGPUs freezing even with 1024 or 512)

It's already unexposed from the editor in 3.x, but not in master.

Footnotes

1. For the mobile situation, we could clamp the radiance size to 256 automatically. ↩

[clayjohn]

Duplicate of #64683 For clarity, a radiance size of 2048 is expected to take multiple GBs of VRAM, the future work here is to communicate that effectively to users and see if we can shrink the default memory usage to something more palatable.