ConfettiFX / The-Forge

The Forge Cross-Platform Rendering Framework PC Windows, Steamdeck (native), Ray Tracing, macOS / iOS, Android, XBOX, PS4, PS5, Switch, Quest 2
Apache License 2.0
4.65k stars 491 forks source link

vk_removeBuffer takes a lot of CPU time when exit application #243

Closed yaoyao-cn closed 2 years ago

yaoyao-cn commented 2 years ago

about 20k uniform buffers need to be removed, and vk_removeBuffer make application take serveral minutes to exit

cpu usage:

cpu_usage

adam-sawicki-a commented 2 years ago

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?

yaoyao-cn commented 2 years ago

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 ?

adam-sawicki-a commented 2 years ago

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.

yaoyao-cn commented 2 years ago

@adam-sawicki-a thank you for your recommendation

yaoyao-cn commented 2 years ago

consider use the latest version of vma see https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator/issues/217#issuecomment-1048458760

adam-sawicki-a commented 2 years ago

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.

wolfgangfengel commented 2 years ago

Should be resolved.