Fix pool DeviceMemory allocations and rek

[rolandhill]

Pool DeviceMemory allocations in MemoryBufferPools

Problem

MemoryBufferPools::reserveMemory() computes a pool-sized deviceSize (floored at
minimumDeviceMemorySize, 16 MB) but never uses it — DeviceMemory::create() receives the
original memRequirements, so every image gets an exact-fit dedicated vkAllocateMemory.
In applications that page resources continuously (paged terrain databases), memoryPools
accumulates one entry per image and is never pruned. In our application (Spatial Integration)
a scene reached 23,000+ DeviceMemory entries averaging ~57 KB:

• The linear memoryPools scan under the per-device mutex became the dominant cost of resource
  compilation: per-tile compile time grew from 156 ms at ~400 resident tiles to 2.5 s at ~1600,
  while data preparation stayed flat.
• The allocation count far exceeds maxMemoryAllocationCount (spec minimum 4096).
• Freed memory was never returned to the driver — footprint pinned at high-water mark.

Changes

Commit 1 — use deviceSize as intended (src/vsg/vk/MemoryBufferPools.cpp):

• New DeviceMemory blocks are allocated at deviceSize, so subsequent resources suballocate
  from shared pools. Explicit dedicated allocations (pNextAllocInfo) keep their exact size.
• Since buffers and optimal-tiling images can now share a pool, every slot is aligned to
  bufferImageGranularity.
• Pool matching uses equality of memoryTypeBits and property flags — the previous superset
  test could select a pool whose chosen memory type index is invalid for the new resource.
• reserveBuffer() skips pool buffers whose maximumAvailableSpace() cannot fit the request,
  avoiding a futile walk of each fragmented buffer's slot map.

Commit 2 — MemoryBufferPools::releaseUnusedPools(): releases pool entries with no
reserved slots back to the driver and returns the bytes freed. Opt-in for applications to call
under memory pressure; no behavioral change otherwise.

Results

Same scripted camera path, same resident tile count (~500), 6 DatabasePager threads:

	before	after
DeviceMemory allocations	23,285	96
per-tile compile median / p90 / max	27 / 49 / 205 ms	2.7 / 5.4 / 6.0 ms
tiles compiled in same test time	12,966	17,996 (+39%)

Compile cost is now flat in residency instead of growing linearly.

targetMaxNumPagedLODWithHighResSubgraphs can now be set much higher without degradation (I'm defaulting to 4000).

Tested on Kubuntu 26.04 and Windows 11.

[rolandhill]

Hold off on this. There is a possible regression on one hardware/driver combination.

[robertosfield]

What hardware/driver combination is causing a regression? What are the symptoms?

FYI, I've done a lot of work over the last few months refactoring DatabasePager/MemoryBufferPools/CompileManager etc. to handle very large paged databases that quickly blow the device memory limit without these changes. Part of this work is to dynamic change targetMaxNumPagedLODWithHighResSubgraphs to make it possible to claw back memory/resources. This work has been a bit of case of 2 steps forwards, one step back. I addressed one of the steps back in commits in July so I'm no looking at making a dev release to wrap these fixes up.

From your description, your issues are different, but touch upon the same code base. For my own testing, what's the best way to spot the issue?

[rolandhill]

Hi Robert, The combination causing a problem is an AMD GPU on windows 11. All my other combinations of NVIDIA/AMD with Linux/windows work. I've done a bit more work on it and it might be something in my application code on that platform rather than this PR. I'll follow up more tomorrow. In all the other combinations it makes a drastic improvement. I'll get back to you with more. Regards, Roland Roland Hill Founder & Principal Four Winds Technology Pty Ltd Spatial Integration <https://www.spatialintegration.com/>

…

On Fri, 14 Aug 2026, 18:36 Robert Osfield, ***@***.***> wrote: *robertosfield* left a comment (vsg-dev/VulkanSceneGraph#1732) <#1732 (comment)> What hardware/driver combination is causing a regression? What are the symptoms? FYI, I've done a lot of work over the last few months refactoring DatabasePager/MemoryBufferPools/CompileManager etc. to handle very large paged databases that quickly blow the device memory limit without these changes. Part of this work is to dynamic change targetMaxNumPagedLODWithHighResSubgraphs to make it possible to claw back memory/resources. This work has been a bit of case of 2 steps forwards, one step back. I addressed one of the steps back in commits in July so I'm no looking at making a dev release to wrap these fixes up. From your description, your issues are different, but touch upon the same code base. For my own testing, what's the best way to spot the issue? — Reply to this email directly, view it on GitHub <#1732?email_source=notifications&email_token=AAPOEQ72XLPTGJPEUNCCKOL5J3FRJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZGEZDOMZUGAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5291273403>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPOEQ3U6IS4GMNDWCIV7NL5J3FRJAVCNFSNUABFKJSXA33TNF2G64TZHMYTIOBWGA4TAMBUHNEXG43VMU5TKMJUHA2DQOBZGQ4KC5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rolandhill]

It was a false alarm. The possible regression was in my application and had nothing to do with this PR. Please go ahead and assess this.

[robertosfield]

This in essence just commenting back in the original if (!device->full()) line. This original usage is clearer in intent than the new if (..) check.

I commented out this check to make sure the MemoryBufferPools full keeps track of all DeviceMemory objects, as I found it useful to take memory usage etc. I think if we want to re-enable check before adding it to track memory then having an option in MemoryBufferPools to control this would be appropriate rather than having dualling commits.

[robertosfield]

I merge now merged the rolandhill-devmem branch associated with this PR with VSG master, minus the change to // if (!deviceMemory->full()) discussed above. We can discuss that separately.