LibretroAdmin 5274546c9d vulkan: memory a smaller render size no longer needs goes back to the driver ...

The heap takes device memory in 64 MB blocks and gave an empty block
back only when an allocation found no room anywhere. Turn the internal
resolution up and down again and the blocks the large images were in
stayed with the core for the rest of the session, empty.

Thirty-two frames after the renderer changes size - by when the frames
that used the old images are long done with, and the images freed (two
frames, with Mesa's software Vulkan) - the blocks that are empty are
given back, all but the last of each kind (memory type; linear or not),
so that the next allocation of every kind is still an offset and not a
trip to the driver. vk_heap_trim_spare() is the new call; once, not every
frame: a block that comes empty in ordinary running is left alone.

Run in RetroArch on Mesa's software Vulkan with the test disc, the render
size taken 1x, 4x, 1x, 4x, 1x, 2x by a line of test code since removed:

  per-triangle  192 MB reserved at 4x; back at 1x, 14 MB in use and 192
                reserved before, "64 MB given back, 128 MB reserved" now,
                both times
  per-pixel     384 MB at 4x; back at 1x 320 MB, both times (its pixel
                buffer stays at the size it grew to)

and the picture at the end is the same file with the trim and without, in
both renderers.

tools/vkheap: the three empty blocks beside one in use go back; with
none in use one of each kind stays, and the next allocation does not ask
the driver.

(Throughput item 4 of the audit, the part of it that can be seen here.
Its budgets per memory heap and a smaller first reservation - 128 MB are
taken at the start for the 14 to 22 MB this disc uses - are not in this.)

2026-10-09 07:16:39 +02:00

..

main.c

vulkan: memory a smaller render size no longer needs goes back to the driver

2026-10-09 07:16:39 +02:00

run.sh

vulkan: device memory allocated in blocks, in C, to replace VMA

2026-10-05 17:32:08 +02:00