Dynamic GPU memory allocation for extracted surfaces #52
Labels
enhancement
New feature or request
performance
Something's slower than it should be
visuals
Something should be prettier
We currently allocate a hardcoded number (4096) of worst-case sized slots for extracted surfaces. This makes inefficient use of memory, putting us uncomfortably close to storage buffer range limits, and gets much worse as chunk size increases. If we hand off metadata to the CPU after surface extraction, we could maintain only a small temporary buffer for worst-case surface extraction results, and more efficiently pack the main buffer using an allocator data structure on the CPU. This would also simplify #51 as the CPU could track the number of vertices in each surface, allowing it to construct indirect draw commands itself.
The text was updated successfully, but these errors were encountered: