Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
yaoyao-cn opened this issue Dec 30, 2021 · 7 comments
Closed

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

yaoyao-cn opened this issue Dec 30, 2021 · 7 comments

Comments

@yaoyao-cn
Copy link

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

@adam-sawicki-a thank you for your recommendation

@yaoyao-cn
Copy link
Author

consider use the latest version of vma
see GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator#217 (comment)

@yaoyao-cn yaoyao-cn reopened this Feb 23, 2022
@adam-sawicki-a
Copy link

adam-sawicki-a commented Feb 23, 2022

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
Copy link
Contributor

Should be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants