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

vmaDestroyBuffer() destroy everything but VkDeviceMemory #401

Open
ghost opened this issue Jan 24, 2024 · 4 comments
Open

vmaDestroyBuffer() destroy everything but VkDeviceMemory #401

ghost opened this issue Jan 24, 2024 · 4 comments
Labels
question Further information is requested

Comments

@ghost
Copy link

ghost commented Jan 24, 2024

When I vmaDestroyBuffer(), at object destruction, it doesn't destroy VkDeviceMemory hMemory, resulting in error:

Validation Error: [ VUID-vkDestroyDevice-device-05137 ] Object 0: handle = 0x2e2941000000001f, type = VK_OBJECT_TYPE_DEVICE_MEMORY; | MessageID = 0x4872eaa0 | vkCreateDevice(): OBJ ERROR : For VkDevice 0x156f8145c70[], VkDeviceMemory 0x2e2941000000001f[] has not been destroyed. The Vulkan spec states: All child objects created on device must have been destroyed prior to destroying device (https://vulkan.lunarg.com/doc/view/1.3.268.0/windows/1.3-extensions/vkspec.html#VUID-vkDestroyDevice-device-05137)
ERROR: vkFreeMemory: Invalid device [VUID-vkFreeMemory-device-parameter]

after i destroy my device.

@adam-sawicki-a adam-sawicki-a added the quality Code quality improvement e.g. refactoring label Jan 25, 2024
@adam-sawicki-a
Copy link
Contributor

Function vmaCreateBuffer creates two objects: VkBuffer and VmaAllocation. When the buffer is no longer needed, you should destroy them both by passing them to vmaDestroyBuffer. Do you pass them both, the buffer and the allocation object?

An allocation represents a piece of device memory.

  • If VMA decided or was explicitly asked (using VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT flag) to create a dedicated memory block for the allocation, it would represent a separate VkDeviceMemory object. It will get destroyed when you pass the allocation to vmaDestroyBuffer.
  • If VMA decided to assign a piece of a larger memory block for the allocation, that memory block may stay after you destroy the buffer and the allocation object.

You don't need to think about it as long as you respect the correct order of deinitialization, which is:

for each buffer:
    vmaDestroyBuffer(g_Allocator, buffer[i], bufferAllocation[i]);
vmaDestroyAllocator(g_Allocator);
vkDestroyDevice(...);

So, my main question is: Did you call vmaDestroyAllocator?

@adam-sawicki-a adam-sawicki-a added question Further information is requested and removed quality Code quality improvement e.g. refactoring labels Jan 25, 2024
@xbz-24
Copy link

xbz-24 commented Mar 29, 2024

I have the same question and calling the vmaDestroyAllocator didnt do the trick

@xbz-24
Copy link

xbz-24 commented Mar 29, 2024

I managed to do a very brief MRE, minimal reproducible example.

    vmaDestroyBuffer(m_allocator, m_vertex_buffer.buffer, m_vertex_buffer.allocation);
    vmaDestroyAllocator(m_allocator);

e.g.

[2024-03-29 17:47:02.921] [info] validation layer: Validation Error: [ VUID-vkDestroyDevice-device-05137 ] Object 0: handle = 0x908683000000001d, type = VK_OBJECT_TYPE_DEVICE_MEMORY; | MessageID = 0x4872eaa0 | vkCreateDevice(): OBJ ERROR : For VkDevice 0x11729a118[], VkDeviceMemory 0x908683000000001d[] has not been destroyed. The Vulkan spec states: All child objects created on device must have been destroyed prior to destroying device

@M2-TE
Copy link

M2-TE commented Apr 15, 2024

Do make sure to destroy the allocator prior to the device according to deinitialization order as mentioned by @adam-sawicki-a ; not doing so is only case where I seem to be able to reproduce that error

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

No branches or pull requests

3 participants