Sparse resources helped my GPU-driven renderer memory usage

This explains how using D3D12 sparse (tiled/reserved) resources solved peak-memory and fragmentation problems in a GPU-driven renderer. Instead of grow-or-shrink buffers or monolithic static buffers, reserved resources provide a virtual GPU address space broken into tiles that are mapped to heaps on demand. The workflow is to CreateReservedResource for a buffer (no initial backing memory) and then call UpdateTileMappings on a command queue to map or unmap tile ranges to ID3D12Heap allocations; unmapping uses D3D12_TILE_RANGE_FLAG_NULL. This preserves a contiguous virtual address space (so shaders and pointers continue to work) while allowing physical memory to be committed only where data exists, similar to committing pages with VirtualAlloc on the CPU.

The practical findings: on modern Windows 11 drivers the UpdateTileMappings cost is microseconds and reliable on multiple NVIDIA/AMD GPUs, making sparse buffers viable for persistent GPU-side structures and eliminating frequent reallocations and complex defragmentation. Important caveats are synchronization (page-table updates are queue ops so you must not be touching those pages on the GPU), only the CPU can issue mappings, and tile granularity (D3D12 tiles are 64 KiB, which can waste space for very small allocations; NVIDIA prefers larger 2 MiB pages). A compelling use case is streamed meshlets or Nanite-like pipelines, where fixed virtual addresses let streamed pages be mapped without pointer relocation.