diff --git a/docs/html/annotated.html b/docs/html/annotated.html index f898f5a..ed46442 100644 --- a/docs/html/annotated.html +++ b/docs/html/annotated.html @@ -65,10 +65,10 @@ $(function() {
CVmaAllocationCreateInfo | |
CVmaAllocationInfo | Parameters of VmaAllocation objects, that can be retrieved using function vmaGetAllocationInfo() |
CVmaAllocationInfo | Parameters of VmaAllocation objects, that can be retrieved using function vmaGetAllocationInfo() |
CVmaAllocatorCreateInfo | Description of a Allocator to be created |
CVmaDefragmentationInfo | Optional configuration parameters to be passed to function vmaDefragment() |
CVmaDefragmentationStats | Statistics returned by function vmaDefragment() |
CVmaDefragmentationInfo | Optional configuration parameters to be passed to function vmaDefragment() |
CVmaDefragmentationStats | Statistics returned by function vmaDefragment() |
CVmaDeviceMemoryCallbacks | Set of callbacks that the library will call for vkAllocateMemory and vkFreeMemory |
CVmaPoolCreateInfo | Describes parameter of created VmaPool |
CVmaPoolStats | Describes parameter of existing VmaPool |
+ Vulkan Memory Allocator
+
+ |
+
Please check "CONFIGURATION SECTION" in the code to find macros that you can define before each include of this file or change directly in this file to provide your own implementation of basic facilities like assert, min()
and max()
functions, mutex etc. C++ STL is used by default, but changing these allows you to get rid of any STL usage if you want, as many game developers tend to do.
The library uses Vulkan functions straight from the vulkan.h
header by default. If you want to provide your own pointers to these functions, e.g. fetched using vkGetInstanceProcAddr()
and vkGetDeviceProcAddr()
:
VMA_STATIC_VULKAN_FUNCTIONS 0
.If you use custom allocator for CPU memory rather than default operator new
and delete
from C++, you can make this library using your allocator as well by filling optional member VmaAllocatorCreateInfo::pAllocationCallbacks. These functions will be passed to Vulkan, as well as used by the library itself to make any CPU-side allocations.
The library makes calls to vkAllocateMemory()
and vkFreeMemory()
internally. You can setup callbacks to be informed about these calls, e.g. for the purpose of gathering some statistics. To do it, fill optional member VmaAllocatorCreateInfo::pDeviceMemoryCallbacks.
If you want to test how your program behaves with limited amount of Vulkan device memory available without switching your graphics card to one that really has smaller VRAM, you can use a feature of this library intended for this purpose. To do it, fill optional member VmaAllocatorCreateInfo::pHeapSizeLimit.
+
+ Vulkan Memory Allocator
+
+ |
+
The library automatically creates and manages default memory pool for each memory type available on the device. A pool contains a number of VkDeviceMemory
blocks. You can create custom pool and allocate memory out of it. It can be useful if you want to:
To use custom memory pools:
+VmaPool
handle.Example:
+.// Create a pool that could have at most 2 blocks, 128 MB each. +VmaPoolCreateInfo poolCreateInfo = {}; +poolCreateInfo.memoryTypeIndex = ... +poolCreateInfo.blockSize = 128ull * 1024 * 1024; +poolCreateInfo.maxBlockCount = 2; + +VmaPool pool; +vmaCreatePool(allocator, &poolCreateInfo, &pool); + +.// Allocate a buffer out of it. +VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; +bufCreateInfo.size = 1024; +bufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; + +VmaAllocationCreateInfo allocCreateInfo = {}; +allocCreateInfo.pool = pool; + +VkBuffer buf; +VmaAllocation alloc; +VmaAllocationInfo allocInfo; +vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo); +
You have to free all allocations made from this pool before destroying it.
+vmaDestroyBuffer(allocator, buf, alloc); +vmaDestroyPool(allocator, pool);
+ Vulkan Memory Allocator
+
+ |
+
Interleaved allocations and deallocations of many objects of varying size can cause fragmentation, which can lead to a situation where the library is unable to find a continuous range of free memory for a new allocation despite there is enough free space, just scattered across many small free ranges between existing allocations.
+To mitigate this problem, you can use vmaDefragment(). Given set of allocations, this function can move them to compact used memory, ensure more continuous free space and possibly also free some VkDeviceMemory
. It can work only on allocations made from memory type that is HOST_VISIBLE
. Allocations are modified to point to the new VkDeviceMemory
and offset. Data in this memory is also memmove
-ed to the new place. However, if you have images or buffers bound to these allocations (and you certainly do), you need to destroy, recreate, and bind them to the new place in memory.
For further details and example code, see documentation of function vmaDefragment().
+vkAllocateMemory
and vkFreeMemory
. More...Enumerations | |
enum | VmaAllocatorFlagBits { VMA_ALLOCATOR_EXTERNALLY_SYNCHRONIZED_BIT = 0x00000001, -VMA_ALLOCATOR_KHR_DEDICATED_ALLOCATION_BIT = 0x00000002, -VMA_ALLOCATOR_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF - } |
Flags for created VmaAllocator. More... | |
enum | VmaAllocatorCreateFlagBits { VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT = 0x00000001, +VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT = 0x00000002, +VMA_ALLOCATOR_CREATE_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF + } |
Flags for created VmaAllocator. More... | |
Functions |
typedef enum VmaAllocatorCreateFlagBits VmaAllocatorCreateFlagBits | +
Flags for created VmaAllocator.
+ +typedef VkFlags VmaAllocatorCreateFlags | +
Description of a Allocator to be created.
- - - -typedef enum VmaAllocatorFlagBits VmaAllocatorFlagBits | -
Flags for created VmaAllocator.
- -typedef VkFlags VmaAllocatorFlags | -
enum VmaAllocatorFlagBits | +enum VmaAllocatorCreateFlagBits |
Flags for created VmaAllocator.
Enumerator | |
---|---|
VMA_ALLOCATOR_EXTERNALLY_SYNCHRONIZED_BIT | Allocator and all objects created from it will not be synchronized internally, so you must guarantee they are used from only one thread at a time or synchronized externally by you. + |
Enumerator | |
VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT | Allocator and all objects created from it will not be synchronized internally, so you must guarantee they are used from only one thread at a time or synchronized externally by you. Using this flag may increase performance because internal mutexes are not used. |
VMA_ALLOCATOR_KHR_DEDICATED_ALLOCATION_BIT | Enables usage of VK_KHR_dedicated_allocation extension. + |
VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT | Enables usage of VK_KHR_dedicated_allocation extension. Using this extenion will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT flag) when it is recommended by the driver. It may improve performance on some GPUs. You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as VmaAllocatorCreateInfo::device, and you want them to be used internally by this library:
|
VMA_ALLOCATOR_FLAG_BITS_MAX_ENUM | |
VMA_ALLOCATOR_CREATE_FLAG_BITS_MAX_ENUM |
Version 2.0.0-alpha.4 (2017-10-02)
+Copyright (c) 2017 Advanced Micro Devices, Inc. All rights reserved.
+License: MIT
Documentation of all members: vk_mem_alloc.h
+Table of contents:
+ -Version 2.0.0-alpha.3 (2017-09-12)
-Source repository: VulkanMemoryAllocator project on GitHub
-Product page: Vulkan Memory Allocator on GPUOpen
Documentation of members grouped: Modules
-Documentation of all members: vk_mem_alloc.h
In your project code:
-#define VMA_IMPLEMENTATION -#include "vk_mem_alloc.h" -
At program startup:
-VkPhysicalDevice
and VkDevice
object.VmaAllocator
object by calling vmaCreateAllocator().VmaAllocatorCreateInfo allocatorInfo = {}; -allocatorInfo.physicalDevice = physicalDevice; -allocatorInfo.device = device; - -VmaAllocator allocator; -vmaCreateAllocator(&allocatorInfo, &allocator); -
When you want to create a buffer or image:
-VkBufferCreateInfo
/ VkImageCreateInfo
structure.VkBuffer
/VkImage
with memory already allocated and bound to it.VkBufferCreateInfo bufferInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; -bufferInfo.size = 65536; -bufferInfo.usage = VK_BUFFER_USAGE_VERTEX_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; - -VmaAllocationCreateInfo allocInfo = {}; -allocInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY; - -VkBuffer buffer; -VmaAllocation allocation; -vmaCreateBuffer(allocator, &bufferInfo, &allocInfo, &buffer, &allocation, nullptr); -
Don't forget to destroy your objects when no longer needed:
-vmaDestroyBuffer(allocator, buffer, allocation); -vmaDestroyAllocator(allocator); -
If you need to map memory on host, it may happen that two allocations are assigned to the same VkDeviceMemory
block, so if you map them both at the same time, it will cause error because mapping single memory block multiple times is illegal in Vulkan.
It is safer, more convenient and more efficient to use special feature designed for that: persistently mapped memory. Allocations made with VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT
flag set in VmaAllocationCreateInfo::flags are returned from device memory blocks that stay mapped all the time, so you can just access CPU pointer to it. VmaAllocationInfo::pMappedData pointer is already offseted to the beginning of particular allocation. Example:
VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; -bufCreateInfo.size = 1024; -bufCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT; - -VmaAllocationCreateInfo allocCreateInfo = {}; -allocCreateInfo.usage = VMA_MEMORY_USAGE_CPU_ONLY; -allocCreateInfo.flags = VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT; - -VkBuffer buf; -VmaAllocation alloc; -VmaAllocationInfo allocInfo; -vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo); - -.// Buffer is immediately mapped. You can access its memory. -memcpy(allocInfo.pMappedData, myData, 1024); -
Memory in Vulkan doesn't need to be unmapped before using it e.g. for transfers, but if you are not sure whether it's HOST_COHERENT
(here is surely is because it's created with VMA_MEMORY_USAGE_CPU_ONLY
), you should check it. If it's not, you should call vkInvalidateMappedMemoryRanges()
before reading and vkFlushMappedMemoryRanges()
after writing to mapped memory on CPU. Example:
VkMemoryPropertyFlags memFlags; -vmaGetMemoryTypeProperties(allocator, allocInfo.memoryType, &memFlags); -if((memFlags & VK_MEMORY_PROPERTY_HOST_COHERENT_BIT) == 0) -{ - VkMappedMemoryRange memRange = { VK_STRUCTURE_TYPE_MAPPED_MEMORY_RANGE }; - memRange.memory = allocInfo.deviceMemory; - memRange.offset = allocInfo.offset; - memRange.size = allocInfo.size; - vkFlushMappedMemoryRanges(device, 1, &memRange); -} -
On AMD GPUs on Windows, Vulkan memory from the type that has both DEVICE_LOCAL
and HOST_VISIBLE
flags should not be mapped for the time of any call to vkQueueSubmit()
or vkQueuePresent()
. Although legal, that would cause performance degradation because WDDM migrates such memory to system RAM. To ensure this, you can unmap all persistently mapped memory using just one function call. For details, see function vmaUnmapPersistentlyMappedMemory(), vmaMapPersistentlyMappedMemory().
The library automatically creates and manages default memory pool for each memory type available on the device. A pool contains a number of VkDeviceMemory
blocks. You can create custom pool and allocate memory out of it. It can be useful if you want to:
See also:
To use custom memory pools:
-VmaPool
handle.Example:
-.// Create a pool that could have at most 2 blocks, 128 MB each. -VmaPoolCreateInfo poolCreateInfo = {}; -poolCreateInfo.memoryTypeIndex = ... -poolCreateInfo.blockSize = 128ull * 1024 * 1024; -poolCreateInfo.maxBlockCount = 2; - -VmaPool pool; -vmaCreatePool(allocator, &poolCreateInfo, &pool); - -.// Allocate a buffer out of it. -VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; -bufCreateInfo.size = 1024; -bufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; - -VmaAllocationCreateInfo allocCreateInfo = {}; -allocCreateInfo.pool = pool; - -VkBuffer buf; -VmaAllocation alloc; -VmaAllocationInfo allocInfo; -vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo); -
You have to free all allocations made from this pool before destroying it.
-vmaDestroyBuffer(allocator, buf, alloc); -vmaDestroyPool(allocator, pool); -
Interleaved allocations and deallocations of many objects of varying size can cause fragmentation, which can lead to a situation where the library is unable to find a continuous range of free memory for a new allocation despite there is enough free space, just scattered across many small free ranges between existing allocations.
-To mitigate this problem, you can use vmaDefragment(). Given set of allocations, this function can move them to compact used memory, ensure more continuous free space and possibly also free some VkDeviceMemory
. It can work only on allocations made from memory type that is HOST_VISIBLE
. Allocations are modified to point to the new VkDeviceMemory
and offset. Data in this memory is also memmove
-ed to the new place. However, if you have images or buffers bound to these allocations (and you certainly do), you need to destroy, recreate, and bind them to the new place in memory.
For further details and example code, see documentation of function vmaDefragment().
-If your game oversubscribes video memory, if may work OK in previous-generation graphics APIs (DirectX 9, 10, 11, OpenGL) because resources are automatically paged to system RAM. In Vulkan you can't do it because when you run out of memory, an allocation just fails. If you have more data (e.g. textures) that can fit into VRAM and you don't need it all at once, you may want to upload them to GPU on demand and "push out" ones that are not used for a long time to make room for the new ones, effectively using VRAM (or a cartain memory pool) as a form of cache. Vulkan Memory Allocator can help you with that by supporting a concept of "lost allocations".
-To create an allocation that can become lost, include VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT
flag in VmaAllocationCreateInfo::flags. Before using a buffer or image bound to such allocation in every new frame, you need to query it if it's not lost. To check it: call vmaGetAllocationInfo() and see if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE
. If the allocation is lost, you should not use it or buffer/image bound to it. You mustn't forget to destroy this allocation and this buffer/image.
To create an allocation that can make some other allocations lost to make room for it, use VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag. You will usually use both flags VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
and VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT
at the same time.
Warning! Current implementation uses quite naive, brute force algorithm, which can make allocation calls that use VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag quite slow. A new, more optimal algorithm and data structure to speed this up is planned for the future.
When interleaving creation of new allocations with usage of existing ones, how do you make sure that an allocation won't become lost while it's used in the current frame?
-It is ensured because vmaGetAllocationInfo() not only returns allocation parameters and checks whether it's not lost, but when it's not, it also atomically marks it as used in the current frame, which makes it impossible to become lost in that frame. It uses lockless algorithm, so it works fast and doesn't involve locking any internal mutex.
-What if my allocation may still be in use by the GPU when it's rendering a previous frame while I already submit new frame on the CPU?
-You can make sure that allocations "touched" by vmaGetAllocationInfo() will not become lost for a number of additional frames back from the current one by specifying this number as VmaAllocatorCreateInfo::frameInUseCount (for default memory pool) and VmaPoolCreateInfo::frameInUseCount (for custom pool).
-How do you inform the library when new frame starts?
-You need to call function vmaSetCurrentFrameIndex().
-Example code:
-struct MyBuffer -{ - VkBuffer m_Buf = nullptr; - VmaAllocation m_Alloc = nullptr; - - .// Called when the buffer is really needed in the current frame. - void EnsureBuffer(); -}; - -void MyBuffer::EnsureBuffer() -{ - .// Buffer has been created. - if(m_Buf != VK_NULL_HANDLE) - { - .// Check if its allocation is not lost + mark it as used in current frame. - VmaAllocationInfo allocInfo; - vmaGetAllocationInfo(allocator, m_Alloc, &allocInfo); - if(allocInfo.deviceMemory != VK_NULL_HANDLE) - { - .// It's all OK - safe to use m_Buf. - return; - } - } - - .// Buffer not yet exists or lost - destroy and recreate it. - - vmaDestroyBuffer(allocator, m_Buf, m_Alloc); - - VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; - bufCreateInfo.size = 1024; - bufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; - - VmaAllocationCreateInfo allocCreateInfo = {}; - allocCreateInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY; - allocCreateInfo.flags = VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT | - VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT; - - vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &m_Buf, &m_Alloc, nullptr); -} -
When using lost allocations, you may see some Vulkan validation layer warnings about overlapping regions of memory bound to different kinds of buffers and images. This is still valid as long as you implement proper handling of lost allocations (like in the example above) and don't use them.
-The library uses following algorithm for allocation, in order:
-VkDeviceMemory
, with preferred block size.VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag was specified, try to find space in existing blocks, possilby making some other allocations lost.VkDeviceMemory
for this allocation, just like when you use VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
.VK_ERROR_OUT_OF_DEVICE_MEMORY
.Please check "CONFIGURATION SECTION" in the code to find macros that you can define before each include of this file or change directly in this file to provide your own implementation of basic facilities like assert, min()
and max()
functions, mutex etc. C++ STL is used by default, but changing these allows you to get rid of any STL usage if you want, as many game developers tend to do.
The library uses Vulkan functions straight from the vulkan.h
header by default. If you want to provide your own pointers to these functions, e.g. fetched using vkGetInstanceProcAddr()
and vkGetDeviceProcAddr()
:
VMA_STATIC_VULKAN_FUNCTIONS 0
.If you use custom allocator for CPU memory rather than default operator new
and delete
from C++, you can make this library using your allocator as well by filling optional member VmaAllocatorCreateInfo::pAllocationCallbacks. These functions will be passed to Vulkan, as well as used by the library itself to make any CPU-side allocations.
The library makes calls to vkAllocateMemory()
and vkFreeMemory()
internally. You can setup callbacks to be informed about these calls, e.g. for the purpose of gathering some statistics. To do it, fill optional member VmaAllocatorCreateInfo::pDeviceMemoryCallbacks.
If you want to test how your program behaves with limited amount of Vulkan device memory available (without switching your graphics card to one that really has smaller VRAM), you can use a feature of this library intended for this purpose. To do it, fill optional member VmaAllocatorCreateInfo::pHeapSizeLimit.
-VmaAllocator
objects can be used independently.VmaAllocator
as first parameter are safe to call from multiple threads simultaneously because they are synchronized internally when needed.VMA_ALLOCATOR_EXTERNALLY_SYNCHRONIZED_BIT
flag, calls to functions that take such VmaAllocator
object must be synchronized externally.VmaAllocation
object must be externally synchronized. For example, you must not call vmaGetAllocationInfo() and vmaDefragment() from different threads at the same time if you pass the same VmaAllocation
object to these functions.
+ Vulkan Memory Allocator
+
+ |
+
If your game oversubscribes video memory, if may work OK in previous-generation graphics APIs (DirectX 9, 10, 11, OpenGL) because resources are automatically paged to system RAM. In Vulkan you can't do it because when you run out of memory, an allocation just fails. If you have more data (e.g. textures) that can fit into VRAM and you don't need it all at once, you may want to upload them to GPU on demand and "push out" ones that are not used for a long time to make room for the new ones, effectively using VRAM (or a cartain memory pool) as a form of cache. Vulkan Memory Allocator can help you with that by supporting a concept of "lost allocations".
+To create an allocation that can become lost, include VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT
flag in VmaAllocationCreateInfo::flags. Before using a buffer or image bound to such allocation in every new frame, you need to query it if it's not lost. To check it: call vmaGetAllocationInfo() and see if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE
. If the allocation is lost, you should not use it or buffer/image bound to it. You mustn't forget to destroy this allocation and this buffer/image.
To create an allocation that can make some other allocations lost to make room for it, use VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag. You will usually use both flags VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
and VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT
at the same time.
Warning! Current implementation uses quite naive, brute force algorithm, which can make allocation calls that use VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag quite slow. A new, more optimal algorithm and data structure to speed this up is planned for the future.
When interleaving creation of new allocations with usage of existing ones, how do you make sure that an allocation won't become lost while it's used in the current frame?
+It is ensured because vmaGetAllocationInfo() not only returns allocation parameters and checks whether it's not lost, but when it's not, it also atomically marks it as used in the current frame, which makes it impossible to become lost in that frame. It uses lockless algorithm, so it works fast and doesn't involve locking any internal mutex.
+What if my allocation may still be in use by the GPU when it's rendering a previous frame while I already submit new frame on the CPU?
+You can make sure that allocations "touched" by vmaGetAllocationInfo() will not become lost for a number of additional frames back from the current one by specifying this number as VmaAllocatorCreateInfo::frameInUseCount (for default memory pool) and VmaPoolCreateInfo::frameInUseCount (for custom pool).
+How do you inform the library when new frame starts?
+You need to call function vmaSetCurrentFrameIndex().
+Example code:
+struct MyBuffer +{ + VkBuffer m_Buf = nullptr; + VmaAllocation m_Alloc = nullptr; + + .// Called when the buffer is really needed in the current frame. + void EnsureBuffer(); +}; + +void MyBuffer::EnsureBuffer() +{ + .// Buffer has been created. + if(m_Buf != VK_NULL_HANDLE) + { + .// Check if its allocation is not lost + mark it as used in current frame. + VmaAllocationInfo allocInfo; + vmaGetAllocationInfo(allocator, m_Alloc, &allocInfo); + if(allocInfo.deviceMemory != VK_NULL_HANDLE) + { + .// It's all OK - safe to use m_Buf. + return; + } + } + + .// Buffer not yet exists or lost - destroy and recreate it. + + vmaDestroyBuffer(allocator, m_Buf, m_Alloc); + + VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; + bufCreateInfo.size = 1024; + bufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; + + VmaAllocationCreateInfo allocCreateInfo = {}; + allocCreateInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY; + allocCreateInfo.flags = VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT | + VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT; + + vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &m_Buf, &m_Alloc, nullptr); +} +
When using lost allocations, you may see some Vulkan validation layer warnings about overlapping regions of memory bound to different kinds of buffers and images. This is still valid as long as you implement proper handling of lost allocations (like in the example above) and don't use them.
+The library uses following algorithm for allocation, in order:
+VkDeviceMemory
, with preferred block size.VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag was specified, try to find space in existing blocks, possilby making some other allocations lost.VkDeviceMemory
for this allocation, just like when you use VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
.VK_ERROR_OUT_OF_DEVICE_MEMORY
.
+ Vulkan Memory Allocator
+
+ |
+
+ Vulkan Memory Allocator
+
+ |
+
If you need to map memory on host, it may happen that two allocations are assigned to the same VkDeviceMemory
block, so if you map them both at the same time, it will cause error because mapping single memory block multiple times is illegal in Vulkan.
It is safer, more convenient and more efficient to use special feature designed for that: persistently mapped memory. Allocations made with VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT
flag set in VmaAllocationCreateInfo::flags are returned from device memory blocks that stay mapped all the time, so you can just access CPU pointer to it. VmaAllocationInfo::pMappedData pointer is already offseted to the beginning of particular allocation. Example:
VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; +bufCreateInfo.size = 1024; +bufCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT; + +VmaAllocationCreateInfo allocCreateInfo = {}; +allocCreateInfo.usage = VMA_MEMORY_USAGE_CPU_ONLY; +allocCreateInfo.flags = VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT; + +VkBuffer buf; +VmaAllocation alloc; +VmaAllocationInfo allocInfo; +vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo); + +.// Buffer is immediately mapped. You can access its memory. +memcpy(allocInfo.pMappedData, myData, 1024); +
Memory in Vulkan doesn't need to be unmapped before using it e.g. for transfers, but if you are not sure whether it's HOST_COHERENT
(here is surely is because it's created with VMA_MEMORY_USAGE_CPU_ONLY
), you should check it. If it's not, you should call vkInvalidateMappedMemoryRanges()
before reading and vkFlushMappedMemoryRanges()
after writing to mapped memory on CPU. Example:
VkMemoryPropertyFlags memFlags; +vmaGetMemoryTypeProperties(allocator, allocInfo.memoryType, &memFlags); +if((memFlags & VK_MEMORY_PROPERTY_HOST_COHERENT_BIT) == 0) +{ + VkMappedMemoryRange memRange = { VK_STRUCTURE_TYPE_MAPPED_MEMORY_RANGE }; + memRange.memory = allocInfo.deviceMemory; + memRange.offset = allocInfo.offset; + memRange.size = allocInfo.size; + vkFlushMappedMemoryRanges(device, 1, &memRange); +} +
On AMD GPUs on Windows, Vulkan memory from the type that has both DEVICE_LOCAL
and HOST_VISIBLE
flags should not be mapped for the time of any call to vkQueueSubmit()
or vkQueuePresent()
. Although legal, that would cause performance degradation because WDDM migrates such memory to system RAM. To ensure this, you can unmap all persistently mapped memory using just one function call. For details, see function vmaUnmapPersistentlyMappedMemory(), vmaMapPersistentlyMappedMemory().
+ Vulkan Memory Allocator
+
+ |
+
In your project code:
+#define VMA_IMPLEMENTATION +#include "vk_mem_alloc.h" +
At program startup:
+VkPhysicalDevice
and VkDevice
object.VmaAllocator
object by calling vmaCreateAllocator().VmaAllocatorCreateInfo allocatorInfo = {}; +allocatorInfo.physicalDevice = physicalDevice; +allocatorInfo.device = device; + +VmaAllocator allocator; +vmaCreateAllocator(&allocatorInfo, &allocator); +
When you want to create a buffer or image:
+VkBufferCreateInfo
/ VkImageCreateInfo
structure.VkBuffer
/VkImage
with memory already allocated and bound to it.VkBufferCreateInfo bufferInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; +bufferInfo.size = 65536; +bufferInfo.usage = VK_BUFFER_USAGE_VERTEX_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; + +VmaAllocationCreateInfo allocInfo = {}; +allocInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY; + +VkBuffer buffer; +VmaAllocation allocation; +vmaCreateBuffer(allocator, &bufferInfo, &allocInfo, &buffer, &allocation, nullptr); +
Don't forget to destroy your objects when no longer needed:
+vmaDestroyBuffer(allocator, buffer, allocation); +vmaDestroyAllocator(allocator);
Public Attributes | |
VmaAllocationCreateFlags | flags |
VmaAllocationCreateFlags | flags |
Use VmaAllocationCreateFlagBits enum. More... | |
VmaMemoryUsage | usage |
VmaMemoryUsage | usage |
Intended usage of memory. More... | |
VkMemoryPropertyFlags | requiredFlags |
Flags that preferably should be set in a Memory Type chosen for an allocation. More... | |
void * | pUserData |
Custom general-purpose pointer that will be stored in VmaAllocation, can be read as VmaAllocationInfo::pUserData and changed using vmaSetAllocationUserData(). More... | |
Custom general-purpose pointer that will be stored in VmaAllocation, can be read as VmaAllocationInfo::pUserData and changed using vmaSetAllocationUserData(). More... | |
VmaPool | pool |
Pool that this allocation should be created in. More... |
VmaAllocationCreateFlags VmaAllocationCreateInfo::flags | +VmaAllocationCreateFlags VmaAllocationCreateInfo::flags |
pool
is not null, this member is ignored.
Custom general-purpose pointer that will be stored in VmaAllocation, can be read as VmaAllocationInfo::pUserData and changed using vmaSetAllocationUserData().
+Custom general-purpose pointer that will be stored in VmaAllocation, can be read as VmaAllocationInfo::pUserData and changed using vmaSetAllocationUserData().
pool
is not null, this member is ignored.
VmaMemoryUsage VmaAllocationCreateInfo::usage | +VmaMemoryUsage VmaAllocationCreateInfo::usage |
Parameters of VmaAllocation
objects, that can be retrieved using function vmaGetAllocationInfo().
+
Parameters of VmaAllocation
objects, that can be retrieved using function vmaGetAllocationInfo().
More...
#include <vk_mem_alloc.h>
Parameters of VmaAllocation
objects, that can be retrieved using function vmaGetAllocationInfo().
Parameters of VmaAllocation
objects, that can be retrieved using function vmaGetAllocationInfo().
Handle to Vulkan memory object.
Same memory object can be shared by multiple allocations.
-It can change after call to vmaDefragment() if this allocation is passed to the function, or if allocation is lost.
+It can change after call to vmaDefragment() if this allocation is passed to the function, or if allocation is lost.
If the allocation is lost, it is equal to VK_NULL_HANDLE
.
Offset into deviceMemory object to the beginning of this allocation, in bytes. (deviceMemory, offset) pair is unique to this allocation.
-It can change after call to vmaDefragment() if this allocation is passed to the function, or if allocation is lost.
+It can change after call to vmaDefragment() if this allocation is passed to the function, or if allocation is lost.
Pointer to the beginning of this allocation as mapped data. Null if this alloaction is not persistently mapped.
-It can change after call to vmaUnmapPersistentlyMappedMemory(), vmaMapPersistentlyMappedMemory(). It can also change after call to vmaDefragment() if this allocation is passed to the function.
+It can change after call to vmaUnmapPersistentlyMappedMemory(), vmaMapPersistentlyMappedMemory(). It can also change after call to vmaDefragment() if this allocation is passed to the function.
Custom general-purpose pointer that was passed as VmaAllocationCreateInfo::pUserData or set using vmaSetAllocationUserData().
-It can change after call to vmaSetAllocationUserData() for this allocation.
+Custom general-purpose pointer that was passed as VmaAllocationCreateInfo::pUserData or set using vmaSetAllocationUserData().
+It can change after call to vmaSetAllocationUserData() for this allocation.
This is the complete list of members for VmaAllocatorCreateInfo, including all inherited members.
device | VmaAllocatorCreateInfo | |
flags | VmaAllocatorCreateInfo | |
flags | VmaAllocatorCreateInfo | |
frameInUseCount | VmaAllocatorCreateInfo | |
pAllocationCallbacks | VmaAllocatorCreateInfo | |
pDeviceMemoryCallbacks | VmaAllocatorCreateInfo |
Public Attributes | |
VmaAllocatorFlags | flags |
Flags for created allocator. Use VmaAllocatorFlagBits enum. More... | |
VmaAllocatorCreateFlags | flags |
Flags for created allocator. Use VmaAllocatorCreateFlagBits enum. More... | |
VkPhysicalDevice | physicalDevice |
Vulkan physical device. More... | |
VmaAllocatorFlags VmaAllocatorCreateInfo::flags | +VmaAllocatorCreateFlags VmaAllocatorCreateInfo::flags |
Flags for created allocator. Use VmaAllocatorFlagBits enum.
+Flags for created allocator. Use VmaAllocatorCreateFlagBits enum.
If there is a limit defined for a heap:
VK_ERROR_OUT_OF_DEVICE_MEMORY
.VkMemoryHeap::size
, the value of this limit will be reported instead when using vmaGetMemoryProperties(). VkMemoryHeap::size
, the value of this limit will be reported instead when using vmaGetMemoryProperties(). Optional configuration parameters to be passed to function vmaDefragment(). +
Optional configuration parameters to be passed to function vmaDefragment(). More...
#include <vk_mem_alloc.h>
Optional configuration parameters to be passed to function vmaDefragment().
+Optional configuration parameters to be passed to function vmaDefragment().
Statistics returned by function vmaDefragment(). +
Statistics returned by function vmaDefragment(). More...
#include <vk_mem_alloc.h>
Statistics returned by function vmaDefragment().
+Statistics returned by function vmaDefragment().
Public Attributes | |
PFN_vmaAllocateDeviceMemoryFunction | pfnAllocate |
PFN_vmaAllocateDeviceMemoryFunction | pfnAllocate |
Optional, can be null. More... | |
PFN_vmaFreeDeviceMemoryFunction | pfnFree |
PFN_vmaFreeDeviceMemoryFunction | pfnFree |
Optional, can be null. More... | |
PFN_vmaAllocateDeviceMemoryFunction VmaDeviceMemoryCallbacks::pfnAllocate | +PFN_vmaAllocateDeviceMemoryFunction VmaDeviceMemoryCallbacks::pfnAllocate |
PFN_vmaFreeDeviceMemoryFunction VmaDeviceMemoryCallbacks::pfnFree | +PFN_vmaFreeDeviceMemoryFunction VmaDeviceMemoryCallbacks::pfnFree |
VmaPoolCreateFlagBits
. More...VmaPoolCreateFlags VmaPoolCreateInfo::flags | +VmaPoolCreateFlags VmaPoolCreateInfo::flags |
+ Vulkan Memory Allocator
+
+ |
+
VmaAllocator
objects can be used independently.VmaAllocator
as first parameter are safe to call from multiple threads simultaneously because they are synchronized internally when needed.VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT
flag, calls to functions that take such VmaAllocator
object must be synchronized externally.VmaAllocation
object must be externally synchronized. For example, you must not call vmaGetAllocationInfo() and vmaDefragment() from different threads at the same time if you pass the same VmaAllocation
object to these functions.
+ Vulkan Memory Allocator
+
+ |
+
In your project code:
+#define VMA_IMPLEMENTATION +#include "vk_mem_alloc.h" +
At program startup:
+VkPhysicalDevice
and VkDevice
object.VmaAllocator
object by calling vmaCreateAllocator().VmaAllocatorCreateInfo allocatorInfo = {}; +allocatorInfo.physicalDevice = physicalDevice; +allocatorInfo.device = device; + +VmaAllocator allocator; +vmaCreateAllocator(&allocatorInfo, &allocator); +
When you want to create a buffer or image:
+VkBufferCreateInfo
/ VkImageCreateInfo
structure.VkBuffer
/VkImage
with memory already allocated and bound to it.VkBufferCreateInfo bufferInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; +bufferInfo.size = 65536; +bufferInfo.usage = VK_BUFFER_USAGE_VERTEX_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; + +VmaAllocationCreateInfo allocInfo = {}; +allocInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY; + +VkBuffer buffer; +VmaAllocation allocation; +vmaCreateBuffer(allocator, &bufferInfo, &allocInfo, &buffer, &allocation, nullptr); +
Don't forget to destroy your objects when no longer needed:
+vmaDestroyBuffer(allocator, buffer, allocation); +vmaDestroyAllocator(allocator); +
If you need to map memory on host, it may happen that two allocations are assigned to the same VkDeviceMemory
block, so if you map them both at the same time, it will cause error because mapping single memory block multiple times is illegal in Vulkan.
It is safer, more convenient and more efficient to use special feature designed for that: persistently mapped memory. Allocations made with VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT
flag set in VmaAllocationCreateInfo::flags are returned from device memory blocks that stay mapped all the time, so you can just access CPU pointer to it. VmaAllocationInfo::pMappedData pointer is already offseted to the beginning of particular allocation. Example:
VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; +bufCreateInfo.size = 1024; +bufCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT; + +VmaAllocationCreateInfo allocCreateInfo = {}; +allocCreateInfo.usage = VMA_MEMORY_USAGE_CPU_ONLY; +allocCreateInfo.flags = VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT; + +VkBuffer buf; +VmaAllocation alloc; +VmaAllocationInfo allocInfo; +vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo); + +.// Buffer is immediately mapped. You can access its memory. +memcpy(allocInfo.pMappedData, myData, 1024); +
Memory in Vulkan doesn't need to be unmapped before using it e.g. for transfers, but if you are not sure whether it's HOST_COHERENT
(here is surely is because it's created with VMA_MEMORY_USAGE_CPU_ONLY
), you should check it. If it's not, you should call vkInvalidateMappedMemoryRanges()
before reading and vkFlushMappedMemoryRanges()
after writing to mapped memory on CPU. Example:
VkMemoryPropertyFlags memFlags; +vmaGetMemoryTypeProperties(allocator, allocInfo.memoryType, &memFlags); +if((memFlags & VK_MEMORY_PROPERTY_HOST_COHERENT_BIT) == 0) +{ + VkMappedMemoryRange memRange = { VK_STRUCTURE_TYPE_MAPPED_MEMORY_RANGE }; + memRange.memory = allocInfo.deviceMemory; + memRange.offset = allocInfo.offset; + memRange.size = allocInfo.size; + vkFlushMappedMemoryRanges(device, 1, &memRange); +} +
On AMD GPUs on Windows, Vulkan memory from the type that has both DEVICE_LOCAL
and HOST_VISIBLE
flags should not be mapped for the time of any call to vkQueueSubmit()
or vkQueuePresent()
. Although legal, that would cause performance degradation because WDDM migrates such memory to system RAM. To ensure this, you can unmap all persistently mapped memory using just one function call. For details, see function vmaUnmapPersistentlyMappedMemory(), vmaMapPersistentlyMappedMemory().
The library automatically creates and manages default memory pool for each memory type available on the device. A pool contains a number of VkDeviceMemory
blocks. You can create custom pool and allocate memory out of it. It can be useful if you want to:
To use custom memory pools:
+VmaPool
handle.Example:
+.// Create a pool that could have at most 2 blocks, 128 MB each. +VmaPoolCreateInfo poolCreateInfo = {}; +poolCreateInfo.memoryTypeIndex = ... +poolCreateInfo.blockSize = 128ull * 1024 * 1024; +poolCreateInfo.maxBlockCount = 2; + +VmaPool pool; +vmaCreatePool(allocator, &poolCreateInfo, &pool); + +.// Allocate a buffer out of it. +VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; +bufCreateInfo.size = 1024; +bufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; + +VmaAllocationCreateInfo allocCreateInfo = {}; +allocCreateInfo.pool = pool; + +VkBuffer buf; +VmaAllocation alloc; +VmaAllocationInfo allocInfo; +vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo); +
You have to free all allocations made from this pool before destroying it.
+vmaDestroyBuffer(allocator, buf, alloc); +vmaDestroyPool(allocator, pool); +
Interleaved allocations and deallocations of many objects of varying size can cause fragmentation, which can lead to a situation where the library is unable to find a continuous range of free memory for a new allocation despite there is enough free space, just scattered across many small free ranges between existing allocations.
+To mitigate this problem, you can use vmaDefragment(). Given set of allocations, this function can move them to compact used memory, ensure more continuous free space and possibly also free some VkDeviceMemory
. It can work only on allocations made from memory type that is HOST_VISIBLE
. Allocations are modified to point to the new VkDeviceMemory
and offset. Data in this memory is also memmove
-ed to the new place. However, if you have images or buffers bound to these allocations (and you certainly do), you need to destroy, recreate, and bind them to the new place in memory.
For further details and example code, see documentation of function vmaDefragment().
+If your game oversubscribes video memory, if may work OK in previous-generation graphics APIs (DirectX 9, 10, 11, OpenGL) because resources are automatically paged to system RAM. In Vulkan you can't do it because when you run out of memory, an allocation just fails. If you have more data (e.g. textures) that can fit into VRAM and you don't need it all at once, you may want to upload them to GPU on demand and "push out" ones that are not used for a long time to make room for the new ones, effectively using VRAM (or a cartain memory pool) as a form of cache. Vulkan Memory Allocator can help you with that by supporting a concept of "lost allocations".
+To create an allocation that can become lost, include VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT
flag in VmaAllocationCreateInfo::flags. Before using a buffer or image bound to such allocation in every new frame, you need to query it if it's not lost. To check it: call vmaGetAllocationInfo() and see if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE
. If the allocation is lost, you should not use it or buffer/image bound to it. You mustn't forget to destroy this allocation and this buffer/image.
To create an allocation that can make some other allocations lost to make room for it, use VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag. You will usually use both flags VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
and VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT
at the same time.
Warning! Current implementation uses quite naive, brute force algorithm, which can make allocation calls that use VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag quite slow. A new, more optimal algorithm and data structure to speed this up is planned for the future.
When interleaving creation of new allocations with usage of existing ones, how do you make sure that an allocation won't become lost while it's used in the current frame?
+It is ensured because vmaGetAllocationInfo() not only returns allocation parameters and checks whether it's not lost, but when it's not, it also atomically marks it as used in the current frame, which makes it impossible to become lost in that frame. It uses lockless algorithm, so it works fast and doesn't involve locking any internal mutex.
+What if my allocation may still be in use by the GPU when it's rendering a previous frame while I already submit new frame on the CPU?
+You can make sure that allocations "touched" by vmaGetAllocationInfo() will not become lost for a number of additional frames back from the current one by specifying this number as VmaAllocatorCreateInfo::frameInUseCount (for default memory pool) and VmaPoolCreateInfo::frameInUseCount (for custom pool).
+How do you inform the library when new frame starts?
+You need to call function vmaSetCurrentFrameIndex().
+Example code:
+struct MyBuffer +{ + VkBuffer m_Buf = nullptr; + VmaAllocation m_Alloc = nullptr; + + .// Called when the buffer is really needed in the current frame. + void EnsureBuffer(); +}; + +void MyBuffer::EnsureBuffer() +{ + .// Buffer has been created. + if(m_Buf != VK_NULL_HANDLE) + { + .// Check if its allocation is not lost + mark it as used in current frame. + VmaAllocationInfo allocInfo; + vmaGetAllocationInfo(allocator, m_Alloc, &allocInfo); + if(allocInfo.deviceMemory != VK_NULL_HANDLE) + { + .// It's all OK - safe to use m_Buf. + return; + } + } + + .// Buffer not yet exists or lost - destroy and recreate it. + + vmaDestroyBuffer(allocator, m_Buf, m_Alloc); + + VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO }; + bufCreateInfo.size = 1024; + bufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; + + VmaAllocationCreateInfo allocCreateInfo = {}; + allocCreateInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY; + allocCreateInfo.flags = VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT | + VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT; + + vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &m_Buf, &m_Alloc, nullptr); +} +
When using lost allocations, you may see some Vulkan validation layer warnings about overlapping regions of memory bound to different kinds of buffers and images. This is still valid as long as you implement proper handling of lost allocations (like in the example above) and don't use them.
+The library uses following algorithm for allocation, in order:
+VkDeviceMemory
, with preferred block size.VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flag was specified, try to find space in existing blocks, possilby making some other allocations lost.VkDeviceMemory
for this allocation, just like when you use VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
.VK_ERROR_OUT_OF_DEVICE_MEMORY
. VmaPool
. More...VmaAllocation
objects, that can be retrieved using function vmaGetAllocationInfo(). More...VmaAllocation
objects, that can be retrieved using function vmaGetAllocationInfo(). More...Macros | |
#define | VMA_STATS_STRING_ENABLED 1 |
#define | VMA_STATS_STRING_ENABLED 1 |
Typedefs | |
typedef void(VKAPI_PTR * | PFN_vmaAllocateDeviceMemoryFunction) (VmaAllocator allocator, uint32_t memoryType, VkDeviceMemory memory, VkDeviceSize size) |
Callback function called after successful vkAllocateMemory. More... | |
typedef void(VKAPI_PTR * | PFN_vmaFreeDeviceMemoryFunction) (VmaAllocator allocator, uint32_t memoryType, VkDeviceMemory memory, VkDeviceSize size) |
Callback function called before vkFreeMemory. More... | |
typedef struct VmaDeviceMemoryCallbacks | VmaDeviceMemoryCallbacks |
Set of callbacks that the library will call for vkAllocateMemory and vkFreeMemory . More... | |
typedef enum VmaAllocatorFlagBits | VmaAllocatorFlagBits |
Flags for created VmaAllocator. More... | |
typedef VkFlags | VmaAllocatorFlags |
typedef struct VmaVulkanFunctions | VmaVulkanFunctions |
Pointers to some Vulkan functions - a subset used by the library. More... | |
typedef struct VmaAllocatorCreateInfo | VmaAllocatorCreateInfo |
Description of a Allocator to be created. More... | |
typedef struct VmaStatInfo | VmaStatInfo |
Calculated statistics of memory usage in entire allocator. More... | |
typedef struct VmaStats | VmaStats |
General statistics from current state of Allocator. More... | |
typedef enum VmaMemoryUsage | VmaMemoryUsage |
typedef enum VmaAllocationCreateFlagBits | VmaAllocationCreateFlagBits |
Flags to be passed as VmaAllocationCreateInfo::flags. More... | |
typedef VkFlags | VmaAllocationCreateFlags |
typedef struct VmaAllocationCreateInfo | VmaAllocationCreateInfo |
typedef enum VmaPoolCreateFlagBits | VmaPoolCreateFlagBits |
Flags to be passed as VmaPoolCreateInfo::flags. More... | |
typedef VkFlags | VmaPoolCreateFlags |
typedef struct VmaPoolCreateInfo | VmaPoolCreateInfo |
Describes parameter of created VmaPool . More... | |
typedef struct VmaPoolStats | VmaPoolStats |
Describes parameter of existing VmaPool . More... | |
typedef struct VmaAllocationInfo | VmaAllocationInfo |
Parameters of VmaAllocation objects, that can be retrieved using function vmaGetAllocationInfo(). More... | |
typedef struct VmaDefragmentationInfo | VmaDefragmentationInfo |
Optional configuration parameters to be passed to function vmaDefragment(). More... | |
typedef struct VmaDefragmentationStats | VmaDefragmentationStats |
Statistics returned by function vmaDefragment(). More... | |
typedef void(VKAPI_PTR * | PFN_vmaAllocateDeviceMemoryFunction) (VmaAllocator allocator, uint32_t memoryType, VkDeviceMemory memory, VkDeviceSize size) |
Callback function called after successful vkAllocateMemory. More... | |
typedef void(VKAPI_PTR * | PFN_vmaFreeDeviceMemoryFunction) (VmaAllocator allocator, uint32_t memoryType, VkDeviceMemory memory, VkDeviceSize size) |
Callback function called before vkFreeMemory. More... | |
typedef struct VmaDeviceMemoryCallbacks | VmaDeviceMemoryCallbacks |
Set of callbacks that the library will call for vkAllocateMemory and vkFreeMemory . More... | |
typedef enum VmaAllocatorCreateFlagBits | VmaAllocatorCreateFlagBits |
Flags for created VmaAllocator. More... | |
typedef VkFlags | VmaAllocatorCreateFlags |
typedef struct VmaVulkanFunctions | VmaVulkanFunctions |
Pointers to some Vulkan functions - a subset used by the library. More... | |
typedef struct VmaAllocatorCreateInfo | VmaAllocatorCreateInfo |
Description of a Allocator to be created. More... | |
typedef struct VmaStatInfo | VmaStatInfo |
Calculated statistics of memory usage in entire allocator. More... | |
typedef struct VmaStats | VmaStats |
General statistics from current state of Allocator. More... | |
typedef enum VmaMemoryUsage | VmaMemoryUsage |
typedef enum VmaAllocationCreateFlagBits | VmaAllocationCreateFlagBits |
Flags to be passed as VmaAllocationCreateInfo::flags. More... | |
typedef VkFlags | VmaAllocationCreateFlags |
typedef struct VmaAllocationCreateInfo | VmaAllocationCreateInfo |
typedef enum VmaPoolCreateFlagBits | VmaPoolCreateFlagBits |
Flags to be passed as VmaPoolCreateInfo::flags. More... | |
typedef VkFlags | VmaPoolCreateFlags |
typedef struct VmaPoolCreateInfo | VmaPoolCreateInfo |
Describes parameter of created VmaPool . More... | |
typedef struct VmaPoolStats | VmaPoolStats |
Describes parameter of existing VmaPool . More... | |
typedef struct VmaAllocationInfo | VmaAllocationInfo |
Parameters of VmaAllocation objects, that can be retrieved using function vmaGetAllocationInfo(). More... | |
typedef struct VmaDefragmentationInfo | VmaDefragmentationInfo |
Optional configuration parameters to be passed to function vmaDefragment(). More... | |
typedef struct VmaDefragmentationStats | VmaDefragmentationStats |
Statistics returned by function vmaDefragment(). More... | |
Functions | |
VkResult | vmaCreateAllocator (const VmaAllocatorCreateInfo *pCreateInfo, VmaAllocator *pAllocator) |
Creates Allocator object. More... | |
void | vmaDestroyAllocator (VmaAllocator allocator) |
Destroys allocator object. More... | |
void | vmaGetPhysicalDeviceProperties (VmaAllocator allocator, const VkPhysicalDeviceProperties **ppPhysicalDeviceProperties) |
void | vmaGetMemoryProperties (VmaAllocator allocator, const VkPhysicalDeviceMemoryProperties **ppPhysicalDeviceMemoryProperties) |
void | vmaGetMemoryTypeProperties (VmaAllocator allocator, uint32_t memoryTypeIndex, VkMemoryPropertyFlags *pFlags) |
Given Memory Type Index, returns Property Flags of this memory type. More... | |
void | vmaSetCurrentFrameIndex (VmaAllocator allocator, uint32_t frameIndex) |
Sets index of the current frame. More... | |
void | vmaCalculateStats (VmaAllocator allocator, VmaStats *pStats) |
Retrieves statistics from current state of the Allocator. More... | |
void | vmaBuildStatsString (VmaAllocator allocator, char **ppStatsString, VkBool32 detailedMap) |
Builds and returns statistics as string in JSON format. More... | |
void | vmaFreeStatsString (VmaAllocator allocator, char *pStatsString) |
VkResult | vmaFindMemoryTypeIndex (VmaAllocator allocator, uint32_t memoryTypeBits, const VmaAllocationCreateInfo *pAllocationCreateInfo, uint32_t *pMemoryTypeIndex) |
VkResult | vmaCreatePool (VmaAllocator allocator, const VmaPoolCreateInfo *pCreateInfo, VmaPool *pPool) |
Allocates Vulkan device memory and creates VmaPool object. More... | |
void | vmaDestroyPool (VmaAllocator allocator, VmaPool pool) |
Destroys VmaPool object and frees Vulkan device memory. More... | |
void | vmaGetPoolStats (VmaAllocator allocator, VmaPool pool, VmaPoolStats *pPoolStats) |
Retrieves statistics of existing VmaPool object. More... | |
void | vmaMakePoolAllocationsLost (VmaAllocator allocator, VmaPool pool, size_t *pLostAllocationCount) |
Marks all allocations in given pool as lost if they are not used in current frame or VmaPoolCreateInfo::frameInUseCount back from now. More... | |
VkResult | vmaAllocateMemory (VmaAllocator allocator, const VkMemoryRequirements *pVkMemoryRequirements, const VmaAllocationCreateInfo *pCreateInfo, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
General purpose memory allocation. More... | |
VkResult | vmaAllocateMemoryForBuffer (VmaAllocator allocator, VkBuffer buffer, const VmaAllocationCreateInfo *pCreateInfo, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
VkResult | vmaAllocateMemoryForImage (VmaAllocator allocator, VkImage image, const VmaAllocationCreateInfo *pCreateInfo, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
Function similar to vmaAllocateMemoryForBuffer(). More... | |
void | vmaFreeMemory (VmaAllocator allocator, VmaAllocation allocation) |
Frees memory previously allocated using vmaAllocateMemory(), vmaAllocateMemoryForBuffer(), or vmaAllocateMemoryForImage(). More... | |
void | vmaGetAllocationInfo (VmaAllocator allocator, VmaAllocation allocation, VmaAllocationInfo *pAllocationInfo) |
Returns current information about specified allocation. More... | |
void | vmaSetAllocationUserData (VmaAllocator allocator, VmaAllocation allocation, void *pUserData) |
Sets pUserData in given allocation to new value. More... | |
void | vmaCreateLostAllocation (VmaAllocator allocator, VmaAllocation *pAllocation) |
Creates new allocation that is in lost state from the beginning. More... | |
VkResult | vmaMapMemory (VmaAllocator allocator, VmaAllocation allocation, void **ppData) |
void | vmaUnmapMemory (VmaAllocator allocator, VmaAllocation allocation) |
void | vmaUnmapPersistentlyMappedMemory (VmaAllocator allocator) |
Unmaps persistently mapped memory of types that are HOST_COHERENT and DEVICE_LOCAL . More... | |
VkResult | vmaMapPersistentlyMappedMemory (VmaAllocator allocator) |
Maps back persistently mapped memory of types that are HOST_COHERENT and DEVICE_LOCAL . More... | |
VkResult | vmaDefragment (VmaAllocator allocator, VmaAllocation *pAllocations, size_t allocationCount, VkBool32 *pAllocationsChanged, const VmaDefragmentationInfo *pDefragmentationInfo, VmaDefragmentationStats *pDefragmentationStats) |
Compacts memory by moving allocations. More... | |
VkResult | vmaCreateBuffer (VmaAllocator allocator, const VkBufferCreateInfo *pBufferCreateInfo, const VmaAllocationCreateInfo *pAllocationCreateInfo, VkBuffer *pBuffer, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
void | vmaDestroyBuffer (VmaAllocator allocator, VkBuffer buffer, VmaAllocation allocation) |
Destroys Vulkan buffer and frees allocated memory. More... | |
VkResult | vmaCreateImage (VmaAllocator allocator, const VkImageCreateInfo *pImageCreateInfo, const VmaAllocationCreateInfo *pAllocationCreateInfo, VkImage *pImage, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
Function similar to vmaCreateBuffer(). More... | |
void | vmaDestroyImage (VmaAllocator allocator, VkImage image, VmaAllocation allocation) |
Destroys Vulkan image and frees allocated memory. More... | |
VkResult | vmaCreateAllocator (const VmaAllocatorCreateInfo *pCreateInfo, VmaAllocator *pAllocator) |
Creates Allocator object. More... | |
void | vmaDestroyAllocator (VmaAllocator allocator) |
Destroys allocator object. More... | |
void | vmaGetPhysicalDeviceProperties (VmaAllocator allocator, const VkPhysicalDeviceProperties **ppPhysicalDeviceProperties) |
void | vmaGetMemoryProperties (VmaAllocator allocator, const VkPhysicalDeviceMemoryProperties **ppPhysicalDeviceMemoryProperties) |
void | vmaGetMemoryTypeProperties (VmaAllocator allocator, uint32_t memoryTypeIndex, VkMemoryPropertyFlags *pFlags) |
Given Memory Type Index, returns Property Flags of this memory type. More... | |
void | vmaSetCurrentFrameIndex (VmaAllocator allocator, uint32_t frameIndex) |
Sets index of the current frame. More... | |
void | vmaCalculateStats (VmaAllocator allocator, VmaStats *pStats) |
Retrieves statistics from current state of the Allocator. More... | |
void | vmaBuildStatsString (VmaAllocator allocator, char **ppStatsString, VkBool32 detailedMap) |
Builds and returns statistics as string in JSON format. More... | |
void | vmaFreeStatsString (VmaAllocator allocator, char *pStatsString) |
VkResult | vmaFindMemoryTypeIndex (VmaAllocator allocator, uint32_t memoryTypeBits, const VmaAllocationCreateInfo *pAllocationCreateInfo, uint32_t *pMemoryTypeIndex) |
VkResult | vmaCreatePool (VmaAllocator allocator, const VmaPoolCreateInfo *pCreateInfo, VmaPool *pPool) |
Allocates Vulkan device memory and creates VmaPool object. More... | |
void | vmaDestroyPool (VmaAllocator allocator, VmaPool pool) |
Destroys VmaPool object and frees Vulkan device memory. More... | |
void | vmaGetPoolStats (VmaAllocator allocator, VmaPool pool, VmaPoolStats *pPoolStats) |
Retrieves statistics of existing VmaPool object. More... | |
void | vmaMakePoolAllocationsLost (VmaAllocator allocator, VmaPool pool, size_t *pLostAllocationCount) |
Marks all allocations in given pool as lost if they are not used in current frame or VmaPoolCreateInfo::frameInUseCount back from now. More... | |
VkResult | vmaAllocateMemory (VmaAllocator allocator, const VkMemoryRequirements *pVkMemoryRequirements, const VmaAllocationCreateInfo *pCreateInfo, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
General purpose memory allocation. More... | |
VkResult | vmaAllocateMemoryForBuffer (VmaAllocator allocator, VkBuffer buffer, const VmaAllocationCreateInfo *pCreateInfo, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
VkResult | vmaAllocateMemoryForImage (VmaAllocator allocator, VkImage image, const VmaAllocationCreateInfo *pCreateInfo, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
Function similar to vmaAllocateMemoryForBuffer(). More... | |
void | vmaFreeMemory (VmaAllocator allocator, VmaAllocation allocation) |
Frees memory previously allocated using vmaAllocateMemory(), vmaAllocateMemoryForBuffer(), or vmaAllocateMemoryForImage(). More... | |
void | vmaGetAllocationInfo (VmaAllocator allocator, VmaAllocation allocation, VmaAllocationInfo *pAllocationInfo) |
Returns current information about specified allocation. More... | |
void | vmaSetAllocationUserData (VmaAllocator allocator, VmaAllocation allocation, void *pUserData) |
Sets pUserData in given allocation to new value. More... | |
void | vmaCreateLostAllocation (VmaAllocator allocator, VmaAllocation *pAllocation) |
Creates new allocation that is in lost state from the beginning. More... | |
VkResult | vmaMapMemory (VmaAllocator allocator, VmaAllocation allocation, void **ppData) |
void | vmaUnmapMemory (VmaAllocator allocator, VmaAllocation allocation) |
void | vmaUnmapPersistentlyMappedMemory (VmaAllocator allocator) |
Unmaps persistently mapped memory of types that are HOST_COHERENT and DEVICE_LOCAL . More... | |
VkResult | vmaMapPersistentlyMappedMemory (VmaAllocator allocator) |
Maps back persistently mapped memory of types that are HOST_COHERENT and DEVICE_LOCAL . More... | |
VkResult | vmaDefragment (VmaAllocator allocator, VmaAllocation *pAllocations, size_t allocationCount, VkBool32 *pAllocationsChanged, const VmaDefragmentationInfo *pDefragmentationInfo, VmaDefragmentationStats *pDefragmentationStats) |
Compacts memory by moving allocations. More... | |
VkResult | vmaCreateBuffer (VmaAllocator allocator, const VkBufferCreateInfo *pBufferCreateInfo, const VmaAllocationCreateInfo *pAllocationCreateInfo, VkBuffer *pBuffer, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
void | vmaDestroyBuffer (VmaAllocator allocator, VkBuffer buffer, VmaAllocation allocation) |
Destroys Vulkan buffer and frees allocated memory. More... | |
VkResult | vmaCreateImage (VmaAllocator allocator, const VkImageCreateInfo *pImageCreateInfo, const VmaAllocationCreateInfo *pAllocationCreateInfo, VkImage *pImage, VmaAllocation *pAllocation, VmaAllocationInfo *pAllocationInfo) |
Function similar to vmaCreateBuffer(). More... | |
void | vmaDestroyImage (VmaAllocator allocator, VkImage image, VmaAllocation allocation) |
Destroys Vulkan image and frees allocated memory. More... | |
#define VMA_STATS_STRING_ENABLED 1 | +
typedef void(VKAPI_PTR * PFN_vmaAllocateDeviceMemoryFunction) (VmaAllocator allocator, uint32_t memoryType, VkDeviceMemory memory, VkDeviceSize size) | +
Callback function called after successful vkAllocateMemory.
+ +typedef void(VKAPI_PTR * PFN_vmaFreeDeviceMemoryFunction) (VmaAllocator allocator, uint32_t memoryType, VkDeviceMemory memory, VkDeviceSize size) | +
Callback function called before vkFreeMemory.
+ +typedef enum VmaAllocationCreateFlagBits VmaAllocationCreateFlagBits | +
Flags to be passed as VmaAllocationCreateInfo::flags.
+ +typedef VkFlags VmaAllocationCreateFlags | +
typedef struct VmaAllocationCreateInfo VmaAllocationCreateInfo | +
typedef struct VmaAllocationInfo VmaAllocationInfo | +
Parameters of VmaAllocation
objects, that can be retrieved using function vmaGetAllocationInfo().
typedef enum VmaAllocatorCreateFlagBits VmaAllocatorCreateFlagBits | +
Flags for created VmaAllocator.
+ +typedef VkFlags VmaAllocatorCreateFlags | +
typedef struct VmaAllocatorCreateInfo VmaAllocatorCreateInfo | +
Description of a Allocator to be created.
+ +typedef struct VmaDefragmentationInfo VmaDefragmentationInfo | +
Optional configuration parameters to be passed to function vmaDefragment().
+ +typedef struct VmaDefragmentationStats VmaDefragmentationStats | +
Statistics returned by function vmaDefragment().
+ +typedef struct VmaDeviceMemoryCallbacks VmaDeviceMemoryCallbacks | +
Set of callbacks that the library will call for vkAllocateMemory
and vkFreeMemory
.
Provided for informative purpose, e.g. to gather statistics about number of allocations or total amount of memory allocated in Vulkan.
+ + +typedef enum VmaMemoryUsage VmaMemoryUsage | +
typedef enum VmaPoolCreateFlagBits VmaPoolCreateFlagBits | +
Flags to be passed as VmaPoolCreateInfo::flags.
+ +typedef VkFlags VmaPoolCreateFlags | +
typedef struct VmaPoolCreateInfo VmaPoolCreateInfo | +
Describes parameter of created VmaPool
.
typedef struct VmaPoolStats VmaPoolStats | +
Describes parameter of existing VmaPool
.
typedef struct VmaStatInfo VmaStatInfo | +
Calculated statistics of memory usage in entire allocator.
+ +General statistics from current state of Allocator.
+ +typedef struct VmaVulkanFunctions VmaVulkanFunctions | +
Pointers to some Vulkan functions - a subset used by the library.
+ + +enum VmaAllocationCreateFlagBits | +
Flags to be passed as VmaAllocationCreateInfo::flags.
+Enumerator | |
---|---|
VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT | Set this flag if the allocation should have its own memory block. +Use it for special, big resources, like fullscreen images used as attachments. +This flag must also be used for host visible resources that you want to map simultaneously because otherwise they might end up as regions of the same You should not use this flag if VmaAllocationCreateInfo::pool is not null. + |
VMA_ALLOCATION_CREATE_NEVER_ALLOCATE_BIT | Set this flag to only try to allocate from existing If new allocation cannot be placed in any of the existing blocks, allocation fails with You should not use If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored. + |
VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT | Set this flag to use a memory that will be persistently mapped and retrieve pointer to it. +Pointer to mapped memory will be returned through VmaAllocationInfo::pMappedData. You cannot map the memory on your own as multiple mappings of a single If VmaAllocationCreateInfo::pool is not null, usage of this flag must match usage of flag Is it valid to use this flag for allocation made from memory type that is not |
VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT | Allocation created with this flag can become lost as a result of another allocation with To check if allocation is not lost, call vmaGetAllocationInfo() and check if VmaAllocationInfo::deviceMemory is not For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page. + |
VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT | While creating allocation using this flag, other allocations that were created with flag For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page. + |
VMA_ALLOCATION_CREATE_FLAG_BITS_MAX_ENUM |
enum VmaAllocatorCreateFlagBits | +
Flags for created VmaAllocator.
+Enumerator | |
---|---|
VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT | Allocator and all objects created from it will not be synchronized internally, so you must guarantee they are used from only one thread at a time or synchronized externally by you. +Using this flag may increase performance because internal mutexes are not used. + |
VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT | Enables usage of VK_KHR_dedicated_allocation extension. +Using this extenion will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT flag) when it is recommended by the driver. It may improve performance on some GPUs. +You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as VmaAllocatorCreateInfo::device, and you want them to be used internally by this library: +
If this flag is enabled, you must also provide VmaAllocatorCreateInfo::pVulkanFunctions and fill at least members: VmaVulkanFunctions::vkGetBufferMemoryRequirements2KHR, VmaVulkanFunctions::vkGetImageMemoryRequirements2KHR, because they are never imported statically. +When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them. +++ |
VMA_ALLOCATOR_CREATE_FLAG_BITS_MAX_ENUM |
enum VmaMemoryUsage | +
Enumerator | |
---|---|
VMA_MEMORY_USAGE_UNKNOWN | No intended memory usage specified. Use other members of VmaAllocationCreateInfo to specify your requirements. + |
VMA_MEMORY_USAGE_GPU_ONLY | Memory will be used on device only, so faster access from the device is preferred. No need to be mappable on host. + |
VMA_MEMORY_USAGE_CPU_ONLY | Memory will be mapped on host. Could be used for transfer to/from device. +Guarantees to be |
VMA_MEMORY_USAGE_CPU_TO_GPU | Memory will be used for frequent (dynamic) updates from host and reads on device (upload). +Guarantees to be |
VMA_MEMORY_USAGE_GPU_TO_CPU | Memory will be used for frequent writing on device and readback on host (download). +Guarantees to be |
VMA_MEMORY_USAGE_MAX_ENUM |
enum VmaPoolCreateFlagBits | +
Flags to be passed as VmaPoolCreateInfo::flags.
+Enumerator | |
---|---|
VMA_POOL_CREATE_PERSISTENT_MAP_BIT | Set this flag to use a memory that will be persistently mapped. +Each allocation made from this pool will have VmaAllocationInfo::pMappedData available. +Usage of this flag must match usage of VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT flag for every allocation made from this pool. + |
VMA_POOL_CREATE_IGNORE_BUFFER_IMAGE_GRANULARITY_BIT | Use this flag if you always allocate only buffers and linear images or only optimal images out of this pool and so Buffer-Image Granularity can be ignored. +This is na optional optimization flag. +If you always allocate using vmaCreateBuffer(), vmaCreateImage(), vmaAllocateMemoryForBuffer(), then you don't need to use it because allocator knows exact type of your allocations so it can handle Buffer-Image Granularity in the optimal way. +If you also allocate using vmaAllocateMemoryForImage() or vmaAllocateMemory(), exact type of such allocations is not known, so allocator must be conservative in handling Buffer-Image Granularity, which can lead to suboptimal allocation (wasted memory). In that case, if you can make sure you always allocate only buffers and linear images or only optimal images out of this pool, use this flag to make allocator disregard Buffer-Image Granularity and so make allocations more optimal. + |
VMA_POOL_CREATE_FLAG_BITS_MAX_ENUM |
VkResult vmaAllocateMemory | +( | +VmaAllocator | +allocator, | +
+ | + | const VkMemoryRequirements * | +pVkMemoryRequirements, | +
+ | + | const VmaAllocationCreateInfo * | +pCreateInfo, | +
+ | + | VmaAllocation * | +pAllocation, | +
+ | + | VmaAllocationInfo * | +pAllocationInfo | +
+ | ) | ++ |
General purpose memory allocation.
+[out] | pAllocation | Handle to allocated memory. |
[out] | pAllocationInfo | Optional. Information about allocated memory. It can be later fetched using function vmaGetAllocationInfo(). |
You should free the memory using vmaFreeMemory().
+It is recommended to use vmaAllocateMemoryForBuffer(), vmaAllocateMemoryForImage(), vmaCreateBuffer(), vmaCreateImage() instead whenever possible.
+ +VkResult vmaAllocateMemoryForBuffer | +( | +VmaAllocator | +allocator, | +
+ | + | VkBuffer | +buffer, | +
+ | + | const VmaAllocationCreateInfo * | +pCreateInfo, | +
+ | + | VmaAllocation * | +pAllocation, | +
+ | + | VmaAllocationInfo * | +pAllocationInfo | +
+ | ) | ++ |
[out] | pAllocation | Handle to allocated memory. |
[out] | pAllocationInfo | Optional. Information about allocated memory. It can be later fetched using function vmaGetAllocationInfo(). |
You should free the memory using vmaFreeMemory().
+ +VkResult vmaAllocateMemoryForImage | +( | +VmaAllocator | +allocator, | +
+ | + | VkImage | +image, | +
+ | + | const VmaAllocationCreateInfo * | +pCreateInfo, | +
+ | + | VmaAllocation * | +pAllocation, | +
+ | + | VmaAllocationInfo * | +pAllocationInfo | +
+ | ) | ++ |
Function similar to vmaAllocateMemoryForBuffer().
+ +void vmaBuildStatsString | +( | +VmaAllocator | +allocator, | +
+ | + | char ** | +ppStatsString, | +
+ | + | VkBool32 | +detailedMap | +
+ | ) | ++ |
Builds and returns statistics as string in JSON format.
+[out] | ppStatsString | Must be freed using vmaFreeStatsString() function. |
void vmaCalculateStats | +( | +VmaAllocator | +allocator, | +
+ | + | VmaStats * | +pStats | +
+ | ) | ++ |
Retrieves statistics from current state of the Allocator.
+ +VkResult vmaCreateAllocator | +( | +const VmaAllocatorCreateInfo * | +pCreateInfo, | +
+ | + | VmaAllocator * | +pAllocator | +
+ | ) | ++ |
Creates Allocator object.
+ +VkResult vmaCreateBuffer | +( | +VmaAllocator | +allocator, | +
+ | + | const VkBufferCreateInfo * | +pBufferCreateInfo, | +
+ | + | const VmaAllocationCreateInfo * | +pAllocationCreateInfo, | +
+ | + | VkBuffer * | +pBuffer, | +
+ | + | VmaAllocation * | +pAllocation, | +
+ | + | VmaAllocationInfo * | +pAllocationInfo | +
+ | ) | ++ |
[out] | pBuffer | Buffer that was created. |
[out] | pAllocation | Allocation that was created. |
[out] | pAllocationInfo | Optional. Information about allocated memory. It can be later fetched using function vmaGetAllocationInfo(). |
This function automatically:
+If any of these operations fail, buffer and allocation are not created, returned value is negative error code, *pBuffer and *pAllocation are null.
+If the function succeeded, you must destroy both buffer and allocation when you no longer need them using either convenience function vmaDestroyBuffer() or separately, using vkDestroyBuffer() and vmaFreeMemory().
+ +VkResult vmaCreateImage | +( | +VmaAllocator | +allocator, | +
+ | + | const VkImageCreateInfo * | +pImageCreateInfo, | +
+ | + | const VmaAllocationCreateInfo * | +pAllocationCreateInfo, | +
+ | + | VkImage * | +pImage, | +
+ | + | VmaAllocation * | +pAllocation, | +
+ | + | VmaAllocationInfo * | +pAllocationInfo | +
+ | ) | ++ |
Function similar to vmaCreateBuffer().
+ +void vmaCreateLostAllocation | +( | +VmaAllocator | +allocator, | +
+ | + | VmaAllocation * | +pAllocation | +
+ | ) | ++ |
Creates new allocation that is in lost state from the beginning.
+It can be useful if you need a dummy, non-null allocation.
+You still need to destroy created object using vmaFreeMemory().
+Returned allocation is not tied to any specific memory pool or memory type and not bound to any image or buffer. It has size = 0. It cannot be turned into a real, non-empty allocation.
+ +VkResult vmaCreatePool | +( | +VmaAllocator | +allocator, | +
+ | + | const VmaPoolCreateInfo * | +pCreateInfo, | +
+ | + | VmaPool * | +pPool | +
+ | ) | ++ |
Allocates Vulkan device memory and creates VmaPool
object.
allocator | Allocator object. | |
pCreateInfo | Parameters of pool to create. | |
[out] | pPool | Handle to created pool. |
VkResult vmaDefragment | +( | +VmaAllocator | +allocator, | +
+ | + | VmaAllocation * | +pAllocations, | +
+ | + | size_t | +allocationCount, | +
+ | + | VkBool32 * | +pAllocationsChanged, | +
+ | + | const VmaDefragmentationInfo * | +pDefragmentationInfo, | +
+ | + | VmaDefragmentationStats * | +pDefragmentationStats | +
+ | ) | ++ |
Compacts memory by moving allocations.
+pAllocations | Array of allocations that can be moved during this compation. | |
allocationCount | Number of elements in pAllocations and pAllocationsChanged arrays. | |
[out] | pAllocationsChanged | Array of boolean values that will indicate whether matching allocation in pAllocations array has been moved. This parameter is optional. Pass null if you don't need this information. |
pDefragmentationInfo | Configuration parameters. Optional - pass null to use default values. | |
[out] | pDefragmentationStats | Statistics returned by the function. Optional - pass null if you don't need this information. |
This function works by moving allocations to different places (different VkDeviceMemory
objects and/or different offsets) in order to optimize memory usage. Only allocations that are in pAllocations array can be moved. All other allocations are considered nonmovable in this call. Basic rules:
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
flag can be compacted. You may pass other allocations but it makes no sense - these will never be moved.VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
but it makes no sense - they will never be moved.VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT
flag can be compacted. If not persistently mapped, memory will be mapped temporarily inside this function if needed, so it shouldn't be mapped by you for the time of this call.VmaAllocation
object multiple times in pAllocations array.The function also frees empty VkDeviceMemory
blocks.
After allocation has been moved, its VmaAllocationInfo::deviceMemory and/or VmaAllocationInfo::offset changes. You must query them again using vmaGetAllocationInfo() if you need them.
+If an allocation has been moved, data in memory is copied to new place automatically, but if it was bound to a buffer or an image, you must destroy that object yourself, create new one and bind it to the new memory pointed by the allocation. You must use vkDestroyBuffer()
, vkDestroyImage()
, vkCreateBuffer()
, vkCreateImage()
for that purpose and NOT vmaDestroyBuffer(), vmaDestroyImage(), vmaCreateBuffer(), vmaCreateImage()! Example:
VkDevice device = ...; +VmaAllocator allocator = ...; +std::vector<VkBuffer> buffers = ...; +std::vector<VmaAllocation> allocations = ...; + +std::vector<VkBool32> allocationsChanged(allocations.size()); +vmaDefragment(allocator, allocations.data(), allocations.size(), allocationsChanged.data(), nullptr, nullptr); + +for(size_t i = 0; i < allocations.size(); ++i) +{ + if(allocationsChanged[i]) + { + VmaAllocationInfo allocInfo; + vmaGetAllocationInfo(allocator, allocations[i], &allocInfo); + + vkDestroyBuffer(device, buffers[i], nullptr); + + VkBufferCreateInfo bufferInfo = ...; + vkCreateBuffer(device, &bufferInfo, nullptr, &buffers[i]); + + .// You can make dummy call to vkGetBufferMemoryRequirements here to silence validation layer warning. + + vkBindBufferMemory(device, buffers[i], allocInfo.deviceMemory, allocInfo.offset); + } +} +
This function may be time-consuming, so you shouldn't call it too often (like every frame or after every resource creation/destruction), but rater you can call it on special occasions (like when reloading a game level, when you just destroyed a lot of objects).
+ +void vmaDestroyAllocator | +( | +VmaAllocator | +allocator | ) | ++ |
Destroys allocator object.
+ +void vmaDestroyBuffer | +( | +VmaAllocator | +allocator, | +
+ | + | VkBuffer | +buffer, | +
+ | + | VmaAllocation | +allocation | +
+ | ) | ++ |
Destroys Vulkan buffer and frees allocated memory.
+This is just a convenience function equivalent to:
+vkDestroyBuffer(device, buffer, allocationCallbacks); +vmaFreeMemory(allocator, allocation);+
void vmaDestroyImage | +( | +VmaAllocator | +allocator, | +
+ | + | VkImage | +image, | +
+ | + | VmaAllocation | +allocation | +
+ | ) | ++ |
Destroys Vulkan image and frees allocated memory.
+This is just a convenience function equivalent to:
+vkDestroyImage(device, image, allocationCallbacks); +vmaFreeMemory(allocator, allocation);+
void vmaDestroyPool | +( | +VmaAllocator | +allocator, | +
+ | + | VmaPool | +pool | +
+ | ) | ++ |
Destroys VmaPool object and frees Vulkan device memory.
+ +VkResult vmaFindMemoryTypeIndex | +( | +VmaAllocator | +allocator, | +
+ | + | uint32_t | +memoryTypeBits, | +
+ | + | const VmaAllocationCreateInfo * | +pAllocationCreateInfo, | +
+ | + | uint32_t * | +pMemoryTypeIndex | +
+ | ) | ++ |
This algorithm tries to find a memory type that:
+void vmaFreeMemory | +( | +VmaAllocator | +allocator, | +
+ | + | VmaAllocation | +allocation | +
+ | ) | ++ |
Frees memory previously allocated using vmaAllocateMemory(), vmaAllocateMemoryForBuffer(), or vmaAllocateMemoryForImage().
+ +void vmaFreeStatsString | +( | +VmaAllocator | +allocator, | +
+ | + | char * | +pStatsString | +
+ | ) | ++ |
void vmaGetAllocationInfo | +( | +VmaAllocator | +allocator, | +
+ | + | VmaAllocation | +allocation, | +
+ | + | VmaAllocationInfo * | +pAllocationInfo | +
+ | ) | ++ |
Returns current information about specified allocation.
+ +void vmaGetMemoryProperties | +( | +VmaAllocator | +allocator, | +
+ | + | const VkPhysicalDeviceMemoryProperties ** | +ppPhysicalDeviceMemoryProperties | +
+ | ) | ++ |
PhysicalDeviceMemoryProperties are fetched from physicalDevice by the allocator. You can access it here, without fetching it again on your own.
+ +void vmaGetMemoryTypeProperties | +( | +VmaAllocator | +allocator, | +
+ | + | uint32_t | +memoryTypeIndex, | +
+ | + | VkMemoryPropertyFlags * | +pFlags | +
+ | ) | ++ |
Given Memory Type Index, returns Property Flags of this memory type.
+This is just a convenience function. Same information can be obtained using vmaGetMemoryProperties().
+ +void vmaGetPhysicalDeviceProperties | +( | +VmaAllocator | +allocator, | +
+ | + | const VkPhysicalDeviceProperties ** | +ppPhysicalDeviceProperties | +
+ | ) | ++ |
PhysicalDeviceProperties are fetched from physicalDevice by the allocator. You can access it here, without fetching it again on your own.
+ +void vmaGetPoolStats | +( | +VmaAllocator | +allocator, | +
+ | + | VmaPool | +pool, | +
+ | + | VmaPoolStats * | +pPoolStats | +
+ | ) | ++ |
Retrieves statistics of existing VmaPool object.
+allocator | Allocator object. | |
pool | Pool object. | |
[out] | pPoolStats | Statistics of specified pool. |
void vmaMakePoolAllocationsLost | +( | +VmaAllocator | +allocator, | +
+ | + | VmaPool | +pool, | +
+ | + | size_t * | +pLostAllocationCount | +
+ | ) | ++ |
Marks all allocations in given pool as lost if they are not used in current frame or VmaPoolCreateInfo::frameInUseCount back from now.
+allocator | Allocator object. | |
pool | Pool. | |
[out] | pLostAllocationCount | Number of allocations marked as lost. Optional - pass null if you don't need this information. |
VkResult vmaMapMemory | +( | +VmaAllocator | +allocator, | +
+ | + | VmaAllocation | +allocation, | +
+ | + | void ** | +ppData | +
+ | ) | ++ |
Feel free to use vkMapMemory on these memory blocks on you own if you want, but just for convenience and to make sure correct offset and size is always specified, usage of vmaMapMemory() / vmaUnmapMemory() is recommended.
+Do not use it on memory allocated with VMA_ALLOCATION_CREATE_PERSISTENT_MAP_BIT
as multiple maps to same VkDeviceMemory
is illegal.
VkResult vmaMapPersistentlyMappedMemory | +( | +VmaAllocator | +allocator | ) | ++ |
Maps back persistently mapped memory of types that are HOST_COHERENT
and DEVICE_LOCAL
.
See vmaUnmapPersistentlyMappedMemory().
+After this call VmaAllocationInfo::pMappedData of some allocation may have value different than before calling vmaUnmapPersistentlyMappedMemory().
+ +void vmaSetAllocationUserData | +( | +VmaAllocator | +allocator, | +
+ | + | VmaAllocation | +allocation, | +
+ | + | void * | +pUserData | +
+ | ) | ++ |
Sets pUserData in given allocation to new value.
+ +void vmaSetCurrentFrameIndex | +( | +VmaAllocator | +allocator, | +
+ | + | uint32_t | +frameIndex | +
+ | ) | ++ |
Sets index of the current frame.
+This function must be used if you make allocations with VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT
and VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT
flags to inform the allocator when a new frame begins. Allocations queried using vmaGetAllocationInfo() cannot become lost in the current frame.
void vmaUnmapMemory | +( | +VmaAllocator | +allocator, | +
+ | + | VmaAllocation | +allocation | +
+ | ) | ++ |
void vmaUnmapPersistentlyMappedMemory | +( | +VmaAllocator | +allocator | ) | ++ |
Unmaps persistently mapped memory of types that are HOST_COHERENT
and DEVICE_LOCAL
.
This is optional performance optimization. On AMD GPUs on Windows, Vulkan memory from the type that has both DEVICE_LOCAL
and HOST_VISIBLE
flags should not be mapped for the time of any call to vkQueueSubmit()
or vkQueuePresent()
. Although legal, that would cause performance degradation because WDDM migrates such memory to system RAM. To ensure this, you can unmap all persistently mapped memory using this function. Example:
vmaUnmapPersistentlyMappedMemory(allocator); +vkQueueSubmit(...) +vmaMapPersistentlyMappedMemory(allocator); +
After this call VmaAllocationInfo::pMappedData of some allocations may become null.
+This call is reference-counted. Memory is mapped again after you call vmaMapPersistentlyMappedMemory() same number of times that you called vmaUnmapPersistentlyMappedMemory().
+ +