2

Say I run into a situation where I would like to change a vulkan buffer's (VkBuffer) size. For example, if I wanted to add more vertices to an existing vertex buffer. How would I grow/shrink a VkBuffer? Would I be forced to just create a new buffer and abandon the old one, or is there functionality similar to C's realloc? Does it exist in the form of a vulkan extension?

In addition, I'm using the Vulkan Memory Allocator (VMA). I would like both solutions using VMA and raw vulkan if there is such realloc functionality.

Rotartsi
  • 527
  • 5
  • 19

1 Answers1

5

There is no realloc in VMA nor Vulkan extensions.

Historically, there was vmaResizeAllocation(), but it was deprecated and is now defunct.

For grow you need to anticipate and preallocate some extra size, or get a new allocation. For shrink you can use the memory you already have, or get a new one.

If you get a new allocation you must do an explicit copy, which might also have consequences for synchronization. So it is kinda out of scope of VMA, and also perhaps not that great for many allocator algorithms.

krOoze
  • 12,301
  • 1
  • 20
  • 34
  • How exactly would a copy cause problems? – Rotartsi Aug 07 '20 at 00:45
  • 2
    @Rotartsi Well, VMA is allocator, not a data manager. It is outside its scope. Nowhere does it get a Queue to do a copy. And it does not know the optimal sync it needs to do before the copy. – krOoze Aug 07 '20 at 01:30
  • Isn't this very similar to the existing defragmentation functionality in VMA? – Rotartsi Aug 07 '20 at 03:58
  • 1
    @Rotartsi I suppose it is. But as you can see from docs the defrag is messy. It is not a simple matter of calling `vma.defrag()`; it is more like mostly DIY. Given `realloc` in 90 % cases is just new alloc, it is probably too impractical to be useful. And growing containers are best avoided in GPU programming generally (you need to then change bunch of other stuff; Descriptors, rerecord cmdbuffs, etc). At some point if you really have some special niche need, you might want to create your own alocator, and perhaps use the Vulkan sparse feature for advanced stuff. – krOoze Aug 07 '20 at 10:38