To amortize allocation cost and prevent lag spikes (as seen in #294), it was necessary to grow the buffers used for storing chunk geometry rather aggressively, like Sodium 0.5.8 tends to do due to a bug. However, this leads to the buffer potentially growing significantly larger than the actual amount of data it contains when chunk meshing finishes. This can be seen by comparing the images at the top of #294 (the behavior of Embeddium 0.3.12 is the same as Sodium 0.5.8).
Since lazily growing the buffers is not viable, the best alternative solution I see is to periodically "garbage collect" the pools and trim the buffers to a more reasonable size. A reasonable choice would likely be the current used capacity, plus some margin to accommodate small increases in data size as sections are updated by block placements/fluid flowing/etc. The margin will still offer substantial improvement over the current status quo where the pool is frequently double the size it should be.
To be eligible for garbage collection, a region must be "idle" for some time (no geometry updates). Collection should be distributed across many frames to minimize any lag spikes generated from the memory transfers. GC can likely be done on a single region per frame.
On a related note, it would be ideal to find out exactly how overcommitting of VRAM in OpenGL works, because if it behaves like virtual memory does on the host, the overprovisioning of the buffer will not be a problem in and of itself, only fragmentation over time. However, I have not been able to find much information on that nor do I have a lot of time to dedicate to that research.
Request Description
To amortize allocation cost and prevent lag spikes (as seen in #294), it was necessary to grow the buffers used for storing chunk geometry rather aggressively, like Sodium 0.5.8 tends to do due to a bug. However, this leads to the buffer potentially growing significantly larger than the actual amount of data it contains when chunk meshing finishes. This can be seen by comparing the images at the top of #294 (the behavior of Embeddium 0.3.12 is the same as Sodium 0.5.8).
Since lazily growing the buffers is not viable, the best alternative solution I see is to periodically "garbage collect" the pools and trim the buffers to a more reasonable size. A reasonable choice would likely be the current used capacity, plus some margin to accommodate small increases in data size as sections are updated by block placements/fluid flowing/etc. The margin will still offer substantial improvement over the current status quo where the pool is frequently double the size it should be.
To be eligible for garbage collection, a region must be "idle" for some time (no geometry updates). Collection should be distributed across many frames to minimize any lag spikes generated from the memory transfers. GC can likely be done on a single region per frame.
On a related note, it would be ideal to find out exactly how overcommitting of VRAM in OpenGL works, because if it behaves like virtual memory does on the host, the overprovisioning of the buffer will not be a problem in and of itself, only fragmentation over time. However, I have not been able to find much information on that nor do I have a lot of time to dedicate to that research.