vk_removeBuffer takes a lot of CPU time when exit application
yaoyao-cn opened this issue · 7 comments
You are right that freeing allocations in VMA library has O(n) time complexity due to traversal of the linked list of sub-allocations sorted by offset. This is an inefficiency that we are aware of and we will fix in the future.
I recommend to allocate bigger buffers and sub-allocate parts of them e.g. using VMA's Virtual Allocator feature instead of creating many small buffers.
Is this time of several minutes to exit observed in Release or Debug configuration? Is VMA_ASSERT or VMA_HEAVY_ASSERT not empty?
thanks for your reply
it’s observed in release configuration and defining VMA_ASSERT to empty give the same result.
now i replace false with VMA_POOL_CREATE_LINEAR_ALGORITHM_BIT or VMA_POOL_CREATE_BUDDY_ALGORITHM_BIT, everything looks fine and releasing becomes very fast.
is it safe to substitute ‘false’ with VMA_POOL_CREATE_LINEAR_ALGORITHM_BIT without other modifications ?
It is not safe to use linear allocator instead of the default one! Linear allocator cannot reuse free space in between allocations, so when you allocate and deallocate in random order, your memory consumption will grow. Buddy allocator is fine in this regard, but you can also observe bigger memory consumption comparing to the default one.
Instead of hacking VMA source I would recommend to create a custom pool with BUDDY algorithm and use it for these small buffers, leaving textures and other resources managed by default pool.
@adam-sawicki-a thank you for your recommendation
consider use the latest version of vma
see GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator#217 (comment)
We are now working towards releasing v3.0.0 final soon. You can pick the latest from master. Please note that in the last few weeks we did some compatibility-breaking changes. Commit messages are a good source of information about what has changed. Documentation is always kept up-to-date and browsable online: https://gpuopen-librariesandsdks.github.io/VulkanMemoryAllocator/html/
We implemented new TLSF algorithm and made it the default, so allocating everything out of default pools should be fast, even when allocating and freeing many small buffers or having large bufferImageGranularity on some platforms. Buddy algorithm has been removed as TLSF is better by all criteria.
Should be resolved.