geometry pool grows 4x the size without shaders
I am looking at a scene with a large jungle, with a bushy-leaves resource pack (Fluff-1.8)
1. baseline is 1.20.4, Sodium 0.5.8, resource pack, render distance 32, this is a geometry heavy scene, but it runs at the frame limiter 90fps steady the whole time, even after loading the front and back of the scene (player stationary, do a 360 to load the chunks in the back).
2. calling f3+a, the geometry pool starts at 2GB, increases to 4-5GB when turning around, the number increases in proportion to the number of chunks that have been revealed
3. same test, but with Iris 1.6.17 with the VanillAA shader active, the geometry pool starts at 4GB (performance is great, 90fps frame limiter steady), and grows (proportionally again) to 12GB (which is the amount of VRAM I have on my 6700XT), after the pool reaches 12GB, it stops growing but performance becomes very bad (like 3fps) when looking at any loaded direction that was loaded after the pool was already 10GB or so (suspected, the pool is partly in host memory, not in vram, causes performance to drop like a stone when rendering this zone)
4. question: why is the geometry pool 3x to 4x larger when using Iris with a very simple shader compared to pure sodium (possibly an Iris problem)?
5. potential fixes: LRU policy for the geometry pool to evict the back of the scene when running out of VRAM (possibly that is more of a sodium problem), it looks like the geometry is never evicted until the chunk goes out of RD altogether, even if it is not currently visible
0 Replies