GPUOpen-LibrariesAndSDKs / VulkanMemoryAllocator

Easy to integrate Vulkan memory allocation library
MIT License
2.63k stars 358 forks source link

VMA (pool) slower than a custom cache of buffers #453

Open jzubizarreta opened 3 days ago

jzubizarreta commented 3 days ago

I noticed than allocating and deallocating the same buffer in each of my compute iterations is very slow. I was expecting VMA to handle this efficiently because it has a pool internally. My intuition is that when a buffer is deallocated, it goes back to the pool, and if the same type of buffer is allocated again, the one in the pool will be reused. However, in my system that behaviour is very slow and I'm sure that the same type/size of buffers are allocated every iteration. I tried with a custom map of buffers and that's way faster. Any idea way? Thanks in advance

adam-sawicki-a commented 2 days ago

VMA doesn't keep a pool of VkBuffer or VkImage objects. If you call vmaDestroyBuffer, the buffer gets destroyed. Creating and destroying buffers can have some performance overhead.

What VMA can help with is allocating large VkDeviceMemory blocks and assigning parts of them to the buffers and images you create. Thus, if you repeatedly create and destroy buffers, chances are that an existing Vulkan memory block is reused and no allocations or deallocations are made. Allocating Vulkan memory could have even bigger performance overhead. Still, this is based on internal heuristics and there are no guarantess.

It is not recommended to create and destroy buffers or images on every rendering frame or compute iteration. I recommend you implementing your own pool of buffers to reuse.