VulkanMemoryAllocator

Creates Allocator object.

A convenience wrapper to make a compatible pair of calls to createAllocator and destroyAllocator

To ensure that destroyAllocator is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Destroys allocator object.

Returns information about existing Allocator object - handle to Vulkan device etc.

It might be useful if you want to keep just the Allocator handle and fetch other required handles to VkPhysicalDevice, VkDevice etc. every time using this function.

PhysicalDeviceProperties are fetched from physicalDevice by the allocator. You can access it here, without fetching it again on your own.

PhysicalDeviceMemoryProperties are fetched from physicalDevice by the allocator. You can access it here, without fetching it again on your own.

Given Memory Type Index, returns Property Flags of this memory type.

This is just a convenience function. Same information can be obtained using getMemoryProperties.

Sets index of the current frame.

Retrieves statistics from current state of the Allocator.

This function is called "calculate" not "get" because it has to traverse all internal data structures, so it may be quite slow. Use it for debugging purposes. For faster but more brief statistics suitable to be called every frame or every allocation, use getHeapBudgets.

Note that when using allocator from multiple threads, returned information may immediately become outdated.

Retrieves information about current memory usage and budget for all memory heaps.

Parameters

This function is called "get" not "calculate" because it is very fast, suitable to be called every frame or every allocation. For more detailed statistics use calculateStatistics.

Note that when using allocator from multiple threads, returned information may immediately become outdated.

Helps to find memoryTypeIndex, given memoryTypeBits and AllocationCreateInfo.

This algorithm tries to find a memory type that:

• Is allowed by memoryTypeBits.

• Contains all the flags from pAllocationCreateInfo->requiredFlags.

• Matches intended usage.

• Has as many flags from pAllocationCreateInfo->preferredFlags as possible.

Returns

Returns VK_ERROR_FEATURE_NOT_PRESENT if not found. Receiving such result from this function or any other allocating function probably means that your device doesn't support any memory type with requested features for the specific type of resource you want to use it for. Please check parameters of your resource, like image layout (OPTIMAL versus LINEAR) or mip level count.

Helps to find memoryTypeIndex, given VkBufferCreateInfo and AllocationCreateInfo.

It can be useful e.g. to determine value to be used as VmaPoolCreateInfo::memoryTypeIndex. It internally creates a temporary, dummy buffer that never has memory bound.

Helps to find memoryTypeIndex, given VkImageCreateInfo and AllocationCreateInfo.

It can be useful e.g. to determine value to be used as VmaPoolCreateInfo::memoryTypeIndex. It internally creates a temporary, dummy image that never has memory bound.

Allocates Vulkan device memory and creates Pool object.

Parameters

A convenience wrapper to make a compatible pair of calls to createPool and destroyPool

To ensure that destroyPool is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Destroys Pool object and frees Vulkan device memory.

Retrieves statistics of existing Pool object.

Parameters

Retrieves detailed statistics of existing Pool object.

Parameters

Checks magic number in margins around all allocations in given memory pool in search for corruptions.

Corruption detection is enabled only when VMA_DEBUG_DETECT_CORRUPTION macro is defined to nonzero, VMA_DEBUG_MARGIN is defined to nonzero and the pool is created in memory type that is HOST_VISIBLE and HOST_COHERENT. For more information, see Corruption detection.

Possible return values:

• VK_ERROR_FEATURE_NOT_PRESENT - corruption detection is not enabled for specified pool.

• VK_SUCCESS - corruption detection has been performed and succeeded.

• VK_ERROR_UNKNOWN - corruption detection has been performed and found memory corruptions around one of the allocations. VMA_ASSERT is also fired in that case.

• Other value: Error returned by Vulkan, e.g. memory mapping failure.

Retrieves name of a custom pool.

After the call ppName is either null or points to an internally-owned null-terminated string containing name of the pool that was previously set. The pointer becomes invalid when the pool is destroyed or its name is changed using setPoolName.

Sets name of a custom pool.

pName can be either null or pointer to a null-terminated string with new name for the pool. Function makes internal copy of the string, so it can be changed or freed immediately after this call.

General purpose memory allocation.

Parameters

You should free the memory using freeMemory or freeMemoryPages.

It is recommended to use allocateMemoryForBuffer, allocateMemoryForImage, createBuffer, createImage instead whenever possible.

A convenience wrapper to make a compatible pair of calls to allocateMemory and freeMemory

To ensure that freeMemory is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

General purpose memory allocation for multiple allocation objects at once.

Parameters

You should free the memory using freeMemory or freeMemoryPages.

Word "pages" is just a suggestion to use this function to allocate pieces of memory needed for sparse binding. It is just a general purpose allocation function able to make multiple allocations at once. It may be internally optimized to be more efficient than calling allocateMemory allocationCount times.

All allocations are made using same parameters. All of them are created out of the same memory pool and type. If any allocation fails, all allocations already made within this function call are also freed, so that when returned result is not VK_SUCCESS, pAllocation array is always entirely filled with VK_NULL_HANDLE.

A convenience wrapper to make a compatible pair of calls to allocateMemoryPages and freeMemoryPages

To ensure that freeMemoryPages is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Allocates memory suitable for given VkBuffer.

Parameters

It only creates Allocation. To bind the memory to the buffer, use bindBufferMemory.

This is a special-purpose function. In most cases you should use createBuffer.

You must free the allocation using freeMemory when no longer needed.

A convenience wrapper to make a compatible pair of calls to allocateMemoryForBuffer and freeMemory

To ensure that freeMemory is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Allocates memory suitable for given VkImage.

Parameters

It only creates Allocation. To bind the memory to the buffer, use bindImageMemory.

This is a special-purpose function. In most cases you should use createImage.

You must free the allocation using freeMemory when no longer needed.

A convenience wrapper to make a compatible pair of calls to allocateMemoryForImage and freeMemory

To ensure that freeMemory is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Frees memory previously allocated using allocateMemory, allocateMemoryForBuffer, or allocateMemoryForImage.

Passing VK_NULL_HANDLE as allocation is valid. Such function call is just skipped.

Frees memory and destroys multiple allocations.

Word "pages" is just a suggestion to use this function to free pieces of memory used for sparse binding. It is just a general purpose function to free memory and destroy allocations made using e.g. allocateMemory, allocateMemoryPages and other functions. It may be internally optimized to be more efficient than calling freeMemory allocationCount times.

Allocations in pAllocations array can come from any memory pools and types. Passing VK_NULL_HANDLE as elements of pAllocations array is valid. Such entries are just skipped.

Returns current information about specified allocation.

Current parameters of given allocation are returned in pAllocationInfo.

Although this function doesn't lock any mutex, so it should be quite efficient, you should avoid calling it too often. You can retrieve same AllocationInfo structure while creating your resource, from function createBuffer, createImage. You can remember it if you are sure parameters don't change (e.g. due to defragmentation).

Sets pUserData in given allocation to new value.

The value of pointer pUserData is copied to allocation's pUserData. It is opaque, so you can use it however you want - e.g. as a pointer, ordinal number or some handle to you own data.

Sets pName in given allocation to new value.

pName must be either null, or pointer to a null-terminated string. The function makes local copy of the string and sets it as allocation's pName. String passed as pName doesn't need to be valid for whole lifetime of the allocation - you can free it after this call. String previously pointed by allocation's pName is freed from memory.

Given an allocation, returns Property Flags of its memory type.

This is just a convenience function. Same information can be obtained using getAllocationInfo + getMemoryProperties.

Maps memory represented by given allocation and returns pointer to it.

Maps memory represented by given allocation to make it accessible to CPU code. When succeeded, *ppData contains pointer to first byte of this memory.

Warning

If the allocation is part of a bigger VkDeviceMemory block, returned pointer is correctly offsetted to the beginning of region assigned to this particular allocation. Unlike the result of vkMapMemory, it points to the allocation, not to the beginning of the whole block. You should not add VmaAllocationInfo::offset to it!

Mapping is internally reference-counted and synchronized, so despite raw Vulkan function vkMapMemory() cannot be used to map same block of VkDeviceMemory multiple times simultaneously, it is safe to call this function on allocations assigned to the same memory block. Actual Vulkan memory will be mapped on first mapping and unmapped on last unmapping.

If the function succeeded, you must call unmapMemory to unmap the allocation when mapping is no longer needed or before freeing the allocation, at the latest.

It also safe to call this function multiple times on the same allocation. You must call unmapMemory same number of times as you called mapMemory.

It is also safe to call this function on allocation created with ALLOCATION_CREATE_MAPPED_BIT flag. Its memory stays mapped all the time. You must still call unmapMemory same number of times as you called mapMemory. You must not call unmapMemory additional time to free the "0-th" mapping made automatically due to ALLOCATION_CREATE_MAPPED_BIT flag.

This function fails when used on allocation made in memory type that is not HOST_VISIBLE.

This function doesn't automatically flush or invalidate caches. If the allocation is made from a memory types that is not HOST_COHERENT, you also need to use invalidateAllocation / flushAllocation, as required by Vulkan specification.

A convenience wrapper to make a compatible pair of calls to mapMemory and unmapMemory

To ensure that unmapMemory is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Unmaps memory represented by given allocation, mapped previously using mapMemory.

For details, see description of mapMemory.

This function doesn't automatically flush or invalidate caches. If the allocation is made from a memory types that is not HOST_COHERENT, you also need to use invalidateAllocation / flushAllocation, as required by Vulkan specification.

Flushes memory of given allocation.

Calls vkFlushMappedMemoryRanges() for memory associated with given range of given allocation. It needs to be called after writing to a mapped memory for memory types that are not HOST_COHERENT. Unmap operation doesn't do that automatically.

• offset must be relative to the beginning of allocation.

• size can be VK_WHOLE_SIZE. It means all memory from offset the the end of given allocation.

• offset and size don't have to be aligned. They are internally rounded down/up to multiply of nonCoherentAtomSize.

• If size is 0, this call is ignored.

• If memory type that the allocation belongs to is not HOST_VISIBLE or it is HOST_COHERENT, this call is ignored.

Warning! offset and size are relative to the contents of given allocation. If you mean whole allocation, you can pass 0 and VK_WHOLE_SIZE, respectively. Do not pass allocation's offset as offset!!!

This function returns the VkResult from vkFlushMappedMemoryRanges if it is called, otherwise VK_SUCCESS.

Invalidates memory of given allocation.

Calls vkInvalidateMappedMemoryRanges() for memory associated with given range of given allocation. It needs to be called before reading from a mapped memory for memory types that are not HOST_COHERENT. Map operation doesn't do that automatically.

• offset must be relative to the beginning of allocation.

• size can be VK_WHOLE_SIZE. It means all memory from offset the the end of given allocation.

• offset and size don't have to be aligned. They are internally rounded down/up to multiply of nonCoherentAtomSize.

• If size is 0, this call is ignored.

• If memory type that the allocation belongs to is not HOST_VISIBLE or it is HOST_COHERENT, this call is ignored.

Warning! offset and size are relative to the contents of given allocation. If you mean whole allocation, you can pass 0 and VK_WHOLE_SIZE, respectively. Do not pass allocation's offset as offset!!!

This function returns the VkResult from vkInvalidateMappedMemoryRanges if it is called, otherwise VK_SUCCESS.

Flushes memory of given set of allocations.

Calls vkFlushMappedMemoryRanges() for memory associated with given ranges of given allocations. For more information, see documentation of flushAllocation.

Parameters

This function returns the VkResult from vkFlushMappedMemoryRanges if it is called, otherwise VK_SUCCESS.

Invalidates memory of given set of allocations.

Calls vkInvalidateMappedMemoryRanges() for memory associated with given ranges of given allocations. For more information, see documentation of invalidateAllocation.

Parameters

This function returns the VkResult from vkInvalidateMappedMemoryRanges if it is called, otherwise VK_SUCCESS.

Checks magic number in margins around all allocations in given memory types (in both default and custom pools) in search for corruptions.

Parameters

Corruption detection is enabled only when VMA_DEBUG_DETECT_CORRUPTION macro is defined to nonzero, VMA_DEBUG_MARGIN is defined to nonzero and only for memory types that are HOST_VISIBLE and HOST_COHERENT. For more information, see Corruption detection.

Possible return values:

• VK_ERROR_FEATURE_NOT_PRESENT - corruption detection is not enabled for any of specified memory types.

• VK_SUCCESS - corruption detection has been performed and succeeded.

• VK_ERROR_UNKNOWN - corruption detection has been performed and found memory corruptions around one of the allocations. VMA_ASSERT is also fired in that case.

• Other value: Error returned by Vulkan, e.g. memory mapping failure.

Begins defragmentation process.

Parameters

Returns

• VK_SUCCESS if defragmentation can begin.

• VK_ERROR_FEATURE_NOT_PRESENT if defragmentation is not supported.

For more information about defragmentation, see documentation chapter: Defragmentation.

A convenience wrapper to make a compatible pair of calls to beginDefragmentation and endDefragmentation

To ensure that endDefragmentation is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Ends defragmentation process.

Parameters

Use this function to finish defragmentation started by beginDefragmentation.

Starts single defragmentation pass.

Parameters

Returns

• VK_SUCCESS if no more moves are possible. Then you can omit call to endDefragmentationPass and simply end whole defragmentation.

• VK_INCOMPLETE if there are pending moves returned in pPassInfo. You need to perform them, call endDefragmentationPass, and then preferably try another pass with beginDefragmentationPass.

This function will call the supplied action between calls to beginDefragmentationPass and endDefragmentationPass

Note that endDefragmentationPass is *not* called if an exception is thrown by the inner action.

Ends single defragmentation pass.

Parameters

Returns VK_SUCCESS if no more moves are possible or VK_INCOMPLETE if more defragmentations are possible.

Ends incremental defragmentation pass and commits all defragmentation moves from pPassInfo. After this call:

• Allocations at pPassInfo[i].srcAllocation that had pPassInfo[i].operation == DEFRAGMENTATION_MOVE_OPERATION_COPY (which is the default) will be pointing to the new destination place.

• Allocation at pPassInfo[i].srcAllocation that had pPassInfo[i].operation == DEFRAGMENTATION_MOVE_OPERATION_DESTROY will be freed.

If no more moves are possible you can end whole defragmentation.

Binds buffer to allocation.

Binds specified buffer to region of memory represented by specified allocation. Gets VkDeviceMemory handle and offset from the allocation. If you want to create a buffer, allocate memory for it and bind them together separately, you should use this function for binding instead of standard vkBindBufferMemory(), because it ensures proper synchronization so that when a VkDeviceMemory object is used by multiple allocations, calls to vkBind*Memory() or vkMapMemory() won't happen from multiple threads simultaneously (which is illegal in Vulkan).

It is recommended to use function createBuffer instead of this one.

Binds buffer to allocation with additional parameters.

Parameters

This function is similar to bindBufferMemory, but it provides additional parameters.

If pNext is not null, Allocator object must have been created with ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT flag or with VmaAllocatorCreateInfo::vulkanApiVersion >= VK_API_VERSION_1_1. Otherwise the call fails.

Binds image to allocation.

Binds specified image to region of memory represented by specified allocation. Gets VkDeviceMemory handle and offset from the allocation. If you want to create an image, allocate memory for it and bind them together separately, you should use this function for binding instead of standard vkBindImageMemory(), because it ensures proper synchronization so that when a VkDeviceMemory object is used by multiple allocations, calls to vkBind*Memory() or vkMapMemory() won't happen from multiple threads simultaneously (which is illegal in Vulkan).

It is recommended to use function createImage instead of this one.

Binds image to allocation with additional parameters.

Parameters

This function is similar to bindImageMemory, but it provides additional parameters.

If pNext is not null, Allocator object must have been created with ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT flag or with VmaAllocatorCreateInfo::vulkanApiVersion >= VK_API_VERSION_1_1. Otherwise the call fails.

Creates a new VkBuffer, allocates and binds memory for it.

Parameters

This function automatically:

1. Creates buffer.

2. Allocates appropriate memory for it.

3. Binds the buffer with the memory.

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 destroyBuffer or separately, using vkDestroyBuffer() and freeMemory.

If ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT flag was used, VK_KHR_dedicated_allocation extension is used internally to query driver whether it requires or prefers the new buffer to have dedicated allocation. If yes, and if dedicated allocation is possible (ALLOCATION_CREATE_NEVER_ALLOCATE_BIT is not used), it creates dedicated allocation for this buffer, just like when using ALLOCATION_CREATE_DEDICATED_MEMORY_BIT.

Note

This function creates a new VkBuffer. Sub-allocation of parts of one large buffer, although recommended as a good practice, is out of scope of this library and could be implemented by the user as a higher-level logic on top of VMA.

A convenience wrapper to make a compatible pair of calls to createBuffer and destroyBuffer

To ensure that destroyBuffer is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Creates a buffer with additional minimum alignment.

Similar to createBuffer but provides additional parameter minAlignment which allows to specify custom, minimum alignment to be used when placing the buffer inside a larger memory block, which may be needed e.g. for interop with OpenGL.

Creates a new VkBuffer, binds already created memory for it.

Parameters

This function automatically:

1. Creates buffer.

2. Binds the buffer with the supplied memory.

If any of these operations fail, buffer is not created, returned value is negative error code and *pBuffer is null.

If the function succeeded, you must destroy the buffer when you no longer need it using vkDestroyBuffer(). If you want to also destroy the corresponding allocation you can use convenience function destroyBuffer.

Note

There is a new version of this function augmented with parameter allocationLocalOffset - see createAliasingBuffer2.

Creates a new VkBuffer, binds already created memory for it.

Parameters

This function automatically:

1. Creates buffer.

2. Binds the buffer with the supplied memory.

If any of these operations fail, buffer is not created, returned value is negative error code and *pBuffer is null.

If the function succeeded, you must destroy the buffer when you no longer need it using vkDestroyBuffer(). If you want to also destroy the corresponding allocation you can use convenience function destroyBuffer.

Note

This is a new version of the function augmented with parameter allocationLocalOffset.

Destroys Vulkan buffer and frees allocated memory.

This is just a convenience function equivalent to:

vkDestroyBuffer(device, buffer, allocationCallbacks);
vmaFreeMemory(allocator, allocation);

It is safe to pass null as buffer and/or allocation.

Function similar to createBuffer.

A convenience wrapper to make a compatible pair of calls to createImage and destroyImage

To ensure that destroyImage is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Function similar to createAliasingBuffer but for images.

Function similar to createAliasingBuffer2 but for images.

Destroys Vulkan image and frees allocated memory.

This is just a convenience function equivalent to:

vkDestroyImage(device, image, allocationCallbacks);
vmaFreeMemory(allocator, allocation);

It is safe to pass null as image and/or allocation.

Creates new VirtualBlock object.

Parameters

A convenience wrapper to make a compatible pair of calls to createVirtualBlock and destroyVirtualBlock

To ensure that destroyVirtualBlock is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Destroys VirtualBlock object.

Please note that you should consciously handle virtual allocations that could remain unfreed in the block. You should either free them individually using virtualFree or call clearVirtualBlock if you are sure this is what you want. If you do neither, an assert is called.

If you keep pointers to some additional metadata associated with your virtual allocations in their pUserData, don't forget to free them.

Returns true of the VirtualBlock is empty - contains 0 virtual allocations and has all its space available for new allocations.

Returns information about a specific virtual allocation within a virtual block, like its size and pUserData pointer.

Allocates new virtual allocation inside given VirtualBlock.

If the allocation fails due to not enough free space available, VK_ERROR_OUT_OF_DEVICE_MEMORY is returned (despite the function doesn't ever allocate actual GPU memory). pAllocation is then set to VK_NULL_HANDLE and pOffset, if not null, it set to UINT64_MAX.

Parameters

A convenience wrapper to make a compatible pair of calls to virtualAllocate and virtualFree

To ensure that virtualFree is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

Frees virtual allocation inside given VirtualBlock.

It is correct to call this function with allocation == VK_NULL_HANDLE - it does nothing.

Frees all virtual allocations inside given VirtualBlock.

You must either call this function or free each virtual allocation individually with virtualFree before destroying a virtual block. Otherwise, an assert is called.

If you keep pointer to some additional metadata associated with your virtual allocation in its pUserData, don't forget to free it as well.

Changes custom pointer associated with given virtual allocation.

Calculates and returns statistics about virtual allocations and memory usage in given VirtualBlock.

This function is fast to call. For more detailed statistics, see calculateVirtualBlockStatistics.

Calculates and returns detailed statistics about virtual allocations and memory usage in given VirtualBlock.

This function is slow to call. Use for debugging purposes. For less detailed statistics, see getVirtualBlockStatistics.

Builds and returns a null-terminated string in JSON format with information about given VirtualBlock.

Parameters

Returned string must be freed using freeVirtualBlockStatsString.

Frees a string returned by buildVirtualBlockStatsString.

Builds and returns statistics as a null-terminated string in JSON format.

Parameters

Flags for created Allocator.

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.

Enables usage of VK_KHR_dedicated_allocation extension.

The flag works only if VmaAllocatorCreateInfo::vulkanApiVersion == VK_API_VERSION_1_0. When it is VK_API_VERSION_1_1, the flag is ignored because the extension has been promoted to Vulkan 1.1.

Using this extension 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 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:

• VK_KHR_get_memory_requirements2 (device extension)

• VK_KHR_dedicated_allocation (device extension)

When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them.

‍vkBindBufferMemory(): Binding memory to buffer 0x2d but vkGetBufferMemoryRequirements() has not been called on that buffer.

Enables usage of VK_KHR_bind_memory2 extension.

The flag works only if VmaAllocatorCreateInfo::vulkanApiVersion == VK_API_VERSION_1_0. When it is VK_API_VERSION_1_1, the flag is ignored because the extension has been promoted to Vulkan 1.1.

You may set this flag only if you found out that this device extension is supported, you enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device, and you want it to be used internally by this library.

The extension provides functions vkBindBufferMemory2KHR and vkBindImageMemory2KHR, which allow to pass a chain of pNext structures while binding. This flag is required if you use pNext parameter in bindBufferMemory2 or bindImageMemory2.

Enables usage of VK_EXT_memory_budget extension.

You may set this flag only if you found out that this device extension is supported, you enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device, and you want it to be used internally by this library, along with another instance extension VK_KHR_get_physical_device_properties2, which is required by it (or Vulkan 1.1, where this extension is promoted).

The extension provides query for current memory usage and budget, which will probably be more accurate than an estimation used by the library otherwise.

Enables usage of VK_AMD_device_coherent_memory extension.

You may set this flag only if you:

• found out that this device extension is supported and enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,

• checked that VkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory is true and set it while creating the Vulkan device,

• want it to be used internally by this library.

The extension and accompanying device feature provide access to memory types with VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD and VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD flags. They are useful mostly for writing breadcrumb markers - a common method for debugging GPU crash/hang/TDR.

When the extension is not enabled, such memory types are still enumerated, but their usage is illegal. To protect from this error, if you don't create the allocator with this flag, it will refuse to allocate any memory or create a custom pool in such memory type, returning VK_ERROR_FEATURE_NOT_PRESENT.

Enables usage of "buffer device address" feature, which allows you to use function vkGetBufferDeviceAddress* to get raw GPU pointer to a buffer and pass it for usage inside a shader.

You may set this flag only if you:

1. (For Vulkan version < 1.2) Found as available and enabled device extension VK_KHR_buffer_device_address. This extension is promoted to core Vulkan 1.2.

2. Found as available and enabled device feature VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress.

When this flag is set, you can create buffers with VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT using VMA. The library automatically adds VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT to allocated memory blocks wherever it might be needed.

For more information, see documentation chapter /Enabling buffer device address/.

Enables usage of VK_EXT_memory_priority extension in the library.

You may set this flag only if you found available and enabled this device extension, along with VkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority == VK_TRUE, while creating Vulkan device passed as VmaAllocatorCreateInfo::device.

When this flag is used, VmaAllocationCreateInfo::priority and VmaPoolCreateInfo::priority are used to set priorities of allocated Vulkan memory. Without it, these variables are ignored.

A priority must be a floating-point value between 0 and 1, indicating the priority of the allocation relative to other memory allocations. Larger values are higher priority. The granularity of the priorities is implementation-dependent. It is automatically passed to every call to vkAllocateMemory done by the library using structure VkMemoryPriorityAllocateInfoEXT. The value to be used for default priority is 0.5. For more details, see the documentation of the VK_EXT_memory_priority extension.

Intended usage of the allocated memory.

No intended memory usage specified. Use other members of AllocationCreateInfo to specify your requirements.

Deprecated

Obsolete, preserved for backward compatibility. Prefers VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT.

Deprecated

Obsolete, preserved for backward compatibility. Guarantees VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT and VK_MEMORY_PROPERTY_HOST_COHERENT_BIT.

Deprecated

Obsolete, preserved for backward compatibility. Guarantees VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT, prefers VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT.

Deprecated

Obsolete, preserved for backward compatibility. Guarantees VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT, prefers VK_MEMORY_PROPERTY_HOST_CACHED_BIT.

Deprecated

Obsolete, preserved for backward compatibility. Prefers not VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT.

Lazily allocated GPU memory having VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT. Exists mostly on mobile platforms. Using it on desktop PC or other GPUs with no such memory type present will fail the allocation.

Usage: Memory for transient attachment images (color attachments, depth attachments etc.), created with VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT.

Allocations with this usage are always created as dedicated - it implies ALLOCATION_CREATE_DEDICATED_MEMORY_BIT.

Selects best memory type automatically. This flag is recommended for most common use cases.

When using this flag, if you want to map the allocation (using mapMemory or ALLOCATION_CREATE_MAPPED_BIT), you must pass one of the flags: ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT or ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT in VmaAllocationCreateInfo::flags.

It can be used only with functions that let the library know VkBufferCreateInfo or VkImageCreateInfo, e.g. createBuffer, createImage, findMemoryTypeIndexForBufferInfo, findMemoryTypeIndexForImageInfo and not with generic memory allocation functions.

Selects best memory type automatically with preference for GPU (device) memory.

When using this flag, if you want to map the allocation (using mapMemory or ALLOCATION_CREATE_MAPPED_BIT), you must pass one of the flags: ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT or ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT in VmaAllocationCreateInfo::flags.

It can be used only with functions that let the library know VkBufferCreateInfo or VkImageCreateInfo, e.g. createBuffer, createImage, findMemoryTypeIndexForBufferInfo, findMemoryTypeIndexForImageInfo and not with generic memory allocation functions.

Selects best memory type automatically with preference for CPU (host) memory.

When using this flag, if you want to map the allocation (using mapMemory or ALLOCATION_CREATE_MAPPED_BIT), you must pass one of the flags: ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT or ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT in VmaAllocationCreateInfo::flags.

It can be used only with functions that let the library know VkBufferCreateInfo or VkImageCreateInfo, e.g. createBuffer, createImage, findMemoryTypeIndexForBufferInfo, findMemoryTypeIndexForImageInfo and not with generic memory allocation functions.

Flags to be passed as VmaAllocationCreateInfo::flags.

Set this flag if the allocation should have its own memory block.

Use it for special, big resources, like fullscreen images used as attachments.

Set this flag to only try to allocate from existing VkDeviceMemory blocks and never create new such block.

If new allocation cannot be placed in any of the existing blocks, allocation fails with VK_ERROR_OUT_OF_DEVICE_MEMORY error.

You should not use ALLOCATION_CREATE_DEDICATED_MEMORY_BIT and ALLOCATION_CREATE_NEVER_ALLOCATE_BIT at the same time. It makes no sense.

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.

It is valid to use this flag for allocation made from memory type that is not HOST_VISIBLE. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).

Deprecated

Preserved for backward compatibility. Consider using setAllocationName instead.

Set this flag to treat VmaAllocationCreateInfo::pUserData as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation's pName. The string is automatically freed together with the allocation. It is also used in buildStatsString.

Allocation will be created from upper stack in a double stack pool.

This flag is only allowed for custom pools created with POOL_CREATE_LINEAR_ALGORITHM_BIT flag.

Create both buffer/image and allocation, but don't bind them together. It is useful when you want to bind yourself to do some more advanced binding, e.g. using some extensions. The flag is meaningful only with functions that bind by default: createBuffer, createImage. Otherwise it is ignored.

If you want to make sure the new buffer/image is not tied to the new memory allocation through VkMemoryDedicatedAllocateInfoKHR structure in case the allocation ends up in its own memory block, use also flag ALLOCATION_CREATE_CAN_ALIAS_BIT.

Create allocation only if additional device memory required for it, if any, won't exceed memory budget. Otherwise return VK_ERROR_OUT_OF_DEVICE_MEMORY.

Set this flag if the allocated memory will have aliasing resources.

Usage of this flag prevents supplying VkMemoryDedicatedAllocateInfoKHR when ALLOCATION_CREATE_DEDICATED_MEMORY_BIT is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.

Requests possibility to map the allocation (using mapMemory or ALLOCATION_CREATE_MAPPED_BIT).

• If you use MEMORY_USAGE_AUTO or other VMA_MEMORY_USAGE_AUTO* value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect.

• If you use other value of MemoryUsage, this flag is ignored and mapping is always possible in memory types that are HOST_VISIBLE. This includes allocations created in Custom memory pools.

Declares that mapped memory will only be written sequentially, e.g. using memcpy() or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.

Warning

Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g. pMappedData[i] += x; Better prepare your data in a local variable and memcpy() it to the mapped pointer all at once.

Requests possibility to map the allocation (using mapMemory or ALLOCATION_CREATE_MAPPED_BIT).

• If you use MEMORY_USAGE_AUTO or other VMA_MEMORY_USAGE_AUTO* value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect.

• If you use other value of MemoryUsage, this flag is ignored and mapping is always possible in memory types that are HOST_VISIBLE. This includes allocations created in Custom memory pools.

Declares that mapped memory can be read, written, and accessed in random order, so a HOST_CACHED memory type is required.

Together with ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT or ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT, it says that despite request for host access, a not-HOST_VISIBLE memory type can be selected if it may improve performance.

By using this flag, you declare that you will check if the allocation ended up in a HOST_VISIBLE memory type (e.g. using getAllocationMemoryProperties) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags like VK_BUFFER_USAGE_TRANSFER_DST_BIT, VK_BUFFER_USAGE_TRANSFER_SRC_BIT to the parameters of created buffer or image.

Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.

Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.

Allocation strategy that chooses always the lowest offset in available space. This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.

Alias to ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT.

Alias to ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT.

A bit mask to extract only STRATEGY bits from entire set of flags.

Flags to be passed as VmaPoolCreateInfo::flags.

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 an optional optimization flag.

If you always allocate using createBuffer, createImage, allocateMemoryForBuffer, 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 allocateMemoryForImage or allocateMemory, 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 faster and more optimal.

Enables alternative, linear allocation algorithm in this pool.

Specify this flag to enable linear allocation algorithm, which always creates new allocations after last one and doesn't reuse space from allocations freed in between. It trades memory consumption for simplified algorithm and data structure, which has better performance and uses less memory for metadata.

By using this flag, you can achieve behavior of free-at-once, stack, ring buffer, and double stack. For details, see documentation chapter Linear allocation algorithm.

Bit mask to extract only ALGORITHM bits from entire set of flags.

Flags to be passed as VmaDefragmentationInfo::flags.

Use the most roboust algorithm at the cost of time to compute and number of copies to make. Only available when bufferImageGranularity is greater than 1, since it aims to reduce alignment issues between different types of resources. Otherwise falls back to same behavior as DEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT.

A bit mask to extract only ALGORITHM bits from entire set of flags.

Operation performed on single defragmentation move. See structure DefragmentationMove.

Buffer/image has been recreated at dstTmpAllocation, data has been copied, old buffer/image has been destroyed. srcAllocation should be changed to point to the new place. This is the default value set by beginDefragmentationPass.

Set this value if you cannot move the allocation. New place reserved at dstTmpAllocation will be freed. srcAllocation will remain unchanged.

Set this value if you decide to abandon the allocation and you destroyed the buffer/image. New place reserved at dstTmpAllocation will be freed, along with srcAllocation, which will be destroyed.

Flags to be passed as VmaVirtualBlockCreateInfo::flags.

Enables alternative, linear allocation algorithm in this virtual block.

Specify this flag to enable linear allocation algorithm, which always creates new allocations after last one and doesn't reuse space from allocations freed in between. It trades memory consumption for simplified algorithm and data structure, which has better performance and uses less memory for metadata.

By using this flag, you can achieve behavior of free-at-once, stack, ring buffer, and double stack. For details, see documentation chapter Linear allocation algorithm.

Bit mask to extract only ALGORITHM bits from entire set of flags.

Flags to be passed as VmaVirtualAllocationCreateInfo::flags.

Allocation will be created from upper stack in a double stack pool.

This flag is only allowed for virtual blocks created with VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT flag.

Allocation strategy that tries to minimize memory usage.

Allocation strategy that tries to minimize allocation time.

Allocation strategy that chooses always the lowest offset in available space. This is not the most efficient strategy but achieves highly packed data.

A bit mask to extract only STRATEGY bits from entire set of flags.

These strategy flags are binary compatible with equivalent flags in AllocationCreateFlagBits.

VmaAllocator

Represents main object of this library initialized.

Fill structure AllocatorCreateInfo and call function createAllocator to create it. Call function destroyAllocator to destroy it.

It is recommended to create just one object of this type per VkDevice object, right after Vulkan is initialized and keep it alive until before Vulkan device is destroyed.

VmaPool

Represents custom memory pool.

Fill structure PoolCreateInfo and call function createPool to create it. Call function destroyPool to destroy it.

For more information see Custom memory pools.

VmaAllocation

Represents single memory allocation.

It may be either dedicated block of VkDeviceMemory or a specific region of a bigger block of this type plus unique offset.

There are multiple ways to create such object. You need to fill structure AllocationCreateInfo. For more information see /Choosing memory type/.

Although the library provides convenience functions that create Vulkan buffer or image, allocate memory for it and bind them together, binding of the allocation to a buffer or an image is out of scope of the allocation itself. Allocation object can exist without buffer/image bound, binding can be done manually by the user, and destruction of it can be done independently of destruction of the allocation.

The object also remembers its size and some other information. To retrieve this information, use function getAllocationInfo and inspect returned structure AllocationInfo.

VmaDefragmentationContext

An opaque object that represents started defragmentation process.

Fill structure DefragmentationInfo and call function beginDefragmentation to create it. Call function endDefragmentation to destroy it.

VmaVirtualAllocation

Represents single memory allocation done inside VirtualBlock.

Use it as a unique identifier to virtual allocation within the single block.

Use value VK_NULL_HANDLE to represent a null/invalid allocation.

VmaVirtualBlock

Handle to a virtual block object that allows to use core allocation algorithm without allocating any real GPU memory.

Fill in VirtualBlockCreateInfo structure and use createVirtualBlock to create it. Use destroyVirtualBlock to destroy it. For more information, see documentation chapter Virtual allocator.

This object is not thread-safe - should not be used from multiple threads simultaneously, must be synchronized externally.

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.

Used in VmaAllocatorCreateInfo::pDeviceMemoryCallbacks.

VmaVulkanFunctions

Pointers to some Vulkan functions - a subset used by the library.

Used in VmaAllocatorCreateInfo::pVulkanFunctions.

VmaAllocatorCreateInfo

Description of a Allocator to be created.

VmaAllocatorInfo

Information about existing Allocator object.

VmaStatistics

Calculated statistics of memory usage e.g. in a specific memory type, heap, custom pool, or total.

These are fast to calculate. See functions: getHeapBudgets, getPoolStatistics.

VmaDetailedStatistics

More detailed statistics than Statistics.

These are slower to calculate. Use for debugging purposes. See functions: calculateStatistics, calculatePoolStatistics.

Previous version of the statistics API provided averages, but they have been removed because they can be easily calculated as:

VkDeviceSize allocationSizeAvg = detailedStats.statistics.allocationBytes / detailedStats.statistics.allocationCount;
VkDeviceSize unusedBytes = detailedStats.statistics.blockBytes - detailedStats.statistics.allocationBytes;
VkDeviceSize unusedRangeSizeAvg = unusedBytes / detailedStats.unusedRangeCount;

VmaTotalStatistics

• DetailedStatistics memoryType [VK_MAX_MEMORY_TYPES]

• DetailedStatistics memoryHeap [VK_MAX_MEMORY_HEAPS]

• DetailedStatistics total

General statistics from current state of the Allocator - total memory usage across all memory heaps and types.

These are slower to calculate. Use for debugging purposes. See function calculateStatistics.

memoryHeap

memoryHeap VmaTotalStatistics VmaTotalStatistics memoryHeap VmaDetailedStatistics VmaTotalStatistics::memoryHeap[VK_MAX_MEMORY_HEAPS]

memoryType

memoryType VmaTotalStatistics VmaTotalStatistics memoryType VmaDetailedStatistics VmaTotalStatistics::memoryType[VK_MAX_MEMORY_TYPES]

VmaBudget

Statistics of current memory usage and available budget for a specific memory heap.

These are fast to calculate. See function getHeapBudgets.

VmaAllocationCreateInfo

Parameters of new Allocation.

To be used with functions like createBuffer, createImage, and many others.

VmaPoolCreateInfo

Describes parameter of created Pool.

VmaAllocationInfo

Parameters of Allocation objects, that can be retrieved using function getAllocationInfo.

VmaDefragmentationInfo

Parameters for defragmentation.

To be used with function beginDefragmentation.

VmaDefragmentationMove

Single move of an allocation to be done for defragmentation.

VmaDefragmentationPassMoveInfo

Parameters for incremental defragmentation steps.

To be used with function beginDefragmentationPass.

VmaDefragmentationStats

Statistics returned for defragmentation process in function endDefragmentation.

VmaVirtualBlockCreateInfo

Parameters of created VirtualBlock object to be passed to createVirtualBlock.

VmaVirtualAllocationCreateInfo

Parameters of created virtual allocation to be passed to virtualAllocate.

VmaVirtualAllocationInfo

Parameters of an existing virtual allocation, returned by getVirtualAllocationInfo.