[Bug] Possible VRAM leak when using shaders

[Atirtra]

Description of Issue

When using shaders, GPU VRAM usage gradually increases until it runs out and starts to spill over into system RAM and induces stuttering. Happens faster in the nether and on higher render distances (~5 minutes on 32 chunks). Does not crash.

Steps to Reproduce

1. Enable shaders (Tested on Complementary Reimagined)
2. Turn render distance preferably to 32 or more chunks
3. Fly around and generate new chunks until system VRAM usage is maxed out and system RAM usage increases + likely stuttering.

OptiFine Version

1.20.1 OptiFine HD U I5

Installation Method

Installer

F3 Debug Screenshot

Additional Information

Sodium is immune to this problem, VRAM usage hovers around 3GB while on optifine it maxes out at 8GB before the problems start.

[sp614x]

This is a vanilla bug, not related to OF or shaders.
Testing vanilla 1.20.1 with render distance 16.
VRAM usage starts at 900MB, after flying around for 10min the VRAM usage increases to 3GB and continues to increase.
Reloading all chunks (F3+A) brings VRAM back to 900MB.
Going to another dimension (nether, end) also brings VRAM down to 900MB.

[Atirtra]

Ah, thanks for confirming. It seems that Sodium/Iris in some way fixes it probably by annoyingly rewriting some of vanilla. I would be a fan of OptiFine due to the performance otherwise being miles better but sadly Nvidia's drivers are a mess on Sodium.

[sp614x]

Looking at how it can be fixed in OF as it is a critical bug that severely limits world exploration.
Strange that it hasn't been reported on the MC bug tracker yet.

[sp614x]

Looks like the uploaded geometry is not released when the chunk renderer is reused for another chunk which doesn't have geometry. If the new chunk has geometry then the old geometry is deleted and the new one is uploaded.
This happens per layer (solid, translucent, etc.).
Not really a leak, more like delayed release, but still much more memory may be reserved as is really needed.
More noticeable with shaders as they use double the VRAM amount.

[Atirtra]

Yup, much more is definitely reserved than needed. 12GB usage compared to the actually needed ~3.5GB in my case is something that can't be left uncorrected. Preferably Mojang needs to be involved at some point if this is a vanilla issue so it could be fixed there too.

[sp614x]

There are two problems:

1. The rendering system is not deleting geometry, it only overwrites old geometry or adds new
2. When deleting unused geometry is added the leak still exists (in a smaller scale) due to the memory fragmentation

The constant deleting and adding of geometry fragments the VBO memory so that the total used memory increases even when the sum of allocated memory stays approximately the same.

[Atirtra]

Found it on the MC bug tracker: https://bugs.mojang.com/browse/MC-170134
Seems to be a much older problem than anticipated. 1.12.2 is the first version it happens in according to the report (who knows if it's every past MC version to a lesser extent). The fact that such an impactful bug/oversight has been done nothing to, is outrageous.

[Barteks2x]

It happened on every MC version that has ever existed that had infinite world afaik. MC just never actually deleted the underlying data. I just couldn't select eariler MC versions in the report (only latest are selectable). And I ran into it while developing a mod on 1.12.2. Also I have a feature request for an option to fix this: #3242. Interesting that it's only now getting some attention.

Not sure whether I said that anywhere but in my own tests, just setting setting the buffer data to null or resizing to smaller size doesn't actually free the memory on some GPU drivers - the only way to force it that I found was to actually delete the underlying VBOs and make new ones, which has a very noticeable performance impact when moving around.

And as I said in the linked feature request, the patch I tried would crash linux nvidia drivers at that time when using shaders.

[sp614x]

Added a fix by incrementally scanning for unused VBOs and clearing them. It takes about 30 sec to scan all the chunks, this is to minimize the effect on performance.
The cleanup in RenderChunk.stopCompileTask() is slower as it also clears VBOs which are about to be uploaded again.

[sp614x]

Fixed in I6_pre3 for 1.20.1