org.lwjgl.util.vma

Class Vma

java.lang.Object

org.lwjgl.util.vma.Vma

public class Vma
extends java.lang.Object

The Vulkan Memory Allocator.

Quick start

Initialization

At program startup:

1. Initialize Vulkan to have VkPhysicalDevice and VkDevice object.
2. Fill VmaAllocatorCreateInfo structure and create VmaAllocator object by calling CreateAllocator.

 VmaAllocatorCreateInfo allocatorInfo = {};
 allocatorInfo.physicalDevice = physicalDevice;
 allocatorInfo.device = device;
 
 VmaAllocator allocator;
 vmaCreateAllocator(&allocatorInfo, &allocator);

Resource allocation

When you want to create a buffer or image:

1. Fill VkBufferCreateInfo / VkImageCreateInfo structure.
2. Fill VmaAllocationCreateInfo structure.
3. Call CreateBuffer / CreateImage to get 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);

Choosing memory type

Physical devices in Vulkan support various combinations of memory heaps and types. Help with choosing correct and optimal memory type for your specific resource is one of the key features of this library. You can use it by filling appropriate members of VmaAllocationCreateInfo structure, as described below. You can also combine multiple methods.

1. If you just want to find memory type index that meets your requirements, you can use function: FindMemoryTypeIndex, FindMemoryTypeIndexForBufferInfo, FindMemoryTypeIndexForImageInfo.
2. If you want to allocate a region of device memory without association with any specific image or buffer, you can use function AllocateMemory. Usage of this function is not recommended and usually not needed. AllocateMemoryPages function is also provided for creating multiple allocations at once, which may be useful for sparse binding.
3. If you already have a buffer or an image created, you want to allocate memory for it and then you will bind it yourself, you can use function AllocateMemoryForBuffer, AllocateMemoryForImage. For binding you should use functions: BindBufferMemory, BindImageMemory or their extended versions: BindBufferMemory2, BindImageMemory2.
4. If you want to create a buffer or an image, allocate memory for it and bind them together, all in one call, you can use function CreateBuffer, CreateImage. This is the easiest and recommended way to use this library.

When using 3. or 4., the library internally queries Vulkan for memory types supported for that buffer or image (function vkGetBufferMemoryRequirements()) and uses only one of these types.

If no memory type can be found that meets all the requirements, these functions return VK_ERROR_FEATURE_NOT_PRESENT.

You can leave VmaAllocationCreateInfo structure completely filled with zeros. It means no requirements are specified for memory type. It is valid, although not very useful.

Usage

The easiest way to specify memory requirements is to fill member VmaAllocationCreateInfo::usage using one of the values of enum VmaMemoryUsage. It defines high level, common usage types. For more details, see description of this enum.

For example, if you want to create a uniform buffer that will be filled using transfer only once or infrequently and used for rendering every frame, you can do it using following code:

 VkBufferCreateInfo bufferInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
 bufferInfo.size = 65536;
 bufferInfo.usage = VK_BUFFER_USAGE_UNIFORM_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);

Required and preferred flags

You can specify more detailed requirements by filling members VmaAllocationCreateInfo::requiredFlags and VmaAllocationCreateInfo::preferredFlags with a combination of bits from enum VkMemoryPropertyFlags. For example, if you want to create a buffer that will be persistently mapped on host (so it must be HOST_VISIBLE) and preferably will also be HOST_COHERENT and HOST_CACHED, use following code:

 VmaAllocationCreateInfo allocInfo = {};
 allocInfo.requiredFlags = VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT;
 allocInfo.preferredFlags = VK_MEMORY_PROPERTY_HOST_COHERENT_BIT | VK_MEMORY_PROPERTY_HOST_CACHED_BIT;
 allocInfo.flags = VMA_ALLOCATION_CREATE_MAPPED_BIT;
 
 VkBuffer buffer;
 VmaAllocation allocation;
 vmaCreateBuffer(allocator, &bufferInfo, &allocInfo, &buffer, &allocation, nullptr);

A memory type is chosen that has all the required flags and as many preferred flags set as possible.

If you use VmaAllocationCreateInfo::usage, it is just internally converted to a set of required and preferred flags.

Explicit memory types

If you inspected memory types available on the physical device and you have a preference for memory types that you want to use, you can fill member VmaAllocationCreateInfo::memoryTypeBits. It is a bit mask, where each bit set means that a memory type with that index is allowed to be used for the allocation. Special value 0, just like UINT32_MAX, means there are no restrictions to memory type index.

Please note that this member is NOT just a memory type index. Still you can use it to choose just one, specific memory type. For example, if you already determined that your buffer should be created in memory type 2, use following code:

 uint32_t memoryTypeIndex = 2;
 
 VmaAllocationCreateInfo allocInfo = {};
 allocInfo.memoryTypeBits = 1u << memoryTypeIndex;
 
 VkBuffer buffer;
 VmaAllocation allocation;
 vmaCreateBuffer(allocator, &bufferInfo, &allocInfo, &buffer, &allocation, nullptr);

Custom memory pools

If you allocate from custom memory pool, all the ways of specifying memory requirements described above are not applicable and the aforementioned members of VmaAllocationCreateInfo structure are ignored. Memory type is selected explicitly when creating the pool and then used to make all the allocations from that pool. For further details, see Custom Memory Pools below.

Dedicated allocations

Memory for allocations is reserved out of larger block of VkDeviceMemory allocated from Vulkan internally. That's the main feature of this whole library. You can still request a separate memory block to be created for an allocation, just like you would do in a trivial solution without using any allocator. In that case, a buffer or image is always bound to that memory at offset 0. This is called a "dedicated allocation". You can explicitly request it by using flag ALLOCATION_CREATE_DEDICATED_MEMORY_BIT. The library can also internally decide to use dedicated allocation in some cases, e.g.:

• When the size of the allocation is large.
• When VK_KHR_dedicated_allocation extension is enabled and it reports that dedicated allocation is required or recommended for the resource.
• When allocation of next big memory block fails due to not enough device memory, but allocation with the exact requested size succeeds.

Memory mapping

To "map memory" in Vulkan means to obtain a CPU pointer to VkDeviceMemory, to be able to read from it or write to it in CPU code. Mapping is possible only of memory allocated from a memory type that has VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT flag. Functions vkMapMemory(), vkUnmapMemory() are designed for this purpose. You can use them directly with memory allocated by this library, but it is not recommended because of following issue: Mapping the same VkDeviceMemory block multiple times is illegal - only one mapping at a time is allowed. This includes mapping disjoint regions. Mapping is not reference-counted internally by Vulkan. Because of this, Vulkan Memory Allocator provides following facilities:

Mapping functions

The library provides following functions for mapping of a specific VmaAllocation: MapMemory, UnmapMemory. They are safer and more convenient to use than standard Vulkan functions. You can map an allocation multiple times simultaneously - mapping is reference-counted internally. You can also map different allocations simultaneously regardless of whether they use the same VkDeviceMemory block. The way it's implemented is that the library always maps entire memory block, not just region of the allocation. For further details, see description of MapMemory function. Example:

 // Having these objects initialized:
 
 struct ConstantBuffer
 {
     ...
 };
 ConstantBuffer constantBufferData;
 
 VmaAllocator allocator;
 VkBuffer constantBuffer;
 VmaAllocation constantBufferAllocation;
 
 // You can map and fill your buffer using following code:
 
 void* mappedData;
 vmaMapMemory(allocator, constantBufferAllocation, &mappedData);
 memcpy(mappedData, &constantBufferData, sizeof(constantBufferData));
 vmaUnmapMemory(allocator, constantBufferAllocation);

When mapping, you may see a warning from Vulkan validation layer similar to this one:

Mapping an image with layout VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL can result in undefined behavior if this memory is used by the device. Only GENERAL or PREINITIALIZED should be used.

It happens because the library maps entire VkDeviceMemory block, where different types of images and buffers may end up together, especially on GPUs with unified memory like Intel. You can safely ignore it if you are sure you access only memory of the intended object that you wanted to map.

Persistently mapped memory

Kepping your memory persistently mapped is generally OK in Vulkan. You don't need to unmap it before using its data on the GPU. The library provides a special feature designed for that: Allocations made with ALLOCATION_CREATE_MAPPED_BIT flag set in VmaAllocationCreateInfo::flags stay mapped all the time, so you can just access CPU pointer to it any time without a need to call any "map" or "unmap" function. Example:

 VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
 bufCreateInfo.size = sizeof(ConstantBuffer);
 bufCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT;
 
 VmaAllocationCreateInfo allocCreateInfo = {};
 allocCreateInfo.usage = VMA_MEMORY_USAGE_CPU_ONLY;
 allocCreateInfo.flags = VMA_ALLOCATION_CREATE_MAPPED_BIT;
 
 VkBuffer buf;
 VmaAllocation alloc;
 VmaAllocationInfo allocInfo;
 vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo);
 
 // Buffer is already mapped. You can access its memory.
 memcpy(allocInfo.pMappedData, &constantBufferData, sizeof(constantBufferData));

There are some exceptions though, when you should consider mapping memory only for a short period of time:

• When operating system is Windows 7 or 8.x (Windows 10 is not affected because it uses WDDM2), device is discrete AMD GPU, and memory type is the special 256 MiB pool of DEVICE_LOCAL + HOST_VISIBLE memory (selected when you use MEMORY_USAGE_CPU_TO_GPU), then whenever a memory block allocated from this memory type stays mapped for the time of any call to vkQueueSubmit() or vkQueuePresentKHR(), this block is migrated by WDDM to system RAM, which degrades performance. It doesn't matter if that particular memory block is actually used by the command buffer being submitted.
• On Mac/MoltenVK there is a known bug - Issue #175 which requires unmapping before GPU can see updated texture.
• Keeping many large memory blocks mapped may impact performance or stability of some debugging tools.

Cache flush and invalidate

Memory in Vulkan doesn't need to be unmapped before using it on GPU, but unless a memory types has VK_MEMORY_PROPERTY_HOST_COHERENT_BIT flag set, you need to manually invalidate cache before reading of mapped pointer and flush cache after writing to mapped pointer. Map/unmap operations don't do that automatically. Vulkan provides following functions for this purpose vkFlushMappedMemoryRangs(), vkInvalidateMappedMemoryRanges(), but this library provides more convenient functions that refer to given allocation object: FlushAllocation, InvalidateAllocation.

Regions of memory specified for flush/invalidate must be aligned to VkPhysicalDeviceLimits::nonCoherentAtomSize. This is automatically ensured by the library. In any memory type that is HOST_VISIBLE but not HOST_COHERENT, all allocations within blocks are aligned to this value, so their offsets are always multiply of nonCoherentAtomSize and two different allocations never share same "line" of this size.

Please note that memory allocated with MEMORY_USAGE_CPU_ONLY is guaranteed to be HOST_COHERENT.

Also, Windows drivers from all 3 PC GPU vendors (AMD, Intel, NVIDIA) currently provide HOST_COHERENT flag on all memory types that are HOST_VISIBLE, so on this platform you may not need to bother.

Finding out if memory is mappable

It may happen that your allocation ends up in memory that is HOST_VISIBLE (available for mapping) despite it wasn't explicitly requested. For example, application may work on integrated graphics with unified memory (like Intel) or allocation from video memory might have failed, so the library chose system memory as fallback.

You can detect this case and map such allocation to access its memory on CPU directly, instead of launching a transfer operation. In order to do that: inspect allocInfo.memoryType, call GetMemoryTypeProperties, and look for VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT flag in properties of that memory type.

 VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
 bufCreateInfo.size = sizeof(ConstantBuffer);
 bufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;
 
 VmaAllocationCreateInfo allocCreateInfo = {};
 allocCreateInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY;
 allocCreateInfo.preferredFlags = VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT;
 
 VkBuffer buf;
 VmaAllocation alloc;
 VmaAllocationInfo allocInfo;
 vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo);
 
 VkMemoryPropertyFlags memFlags;
 vmaGetMemoryTypeProperties(allocator, allocInfo.memoryType, &memFlags);
 if((memFlags & VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT) == 0)
 {
     // Allocation ended up in mappable memory. You can map it and access it directly.
     void* mappedData;
     vmaMapMemory(allocator, alloc, &mappedData);
     memcpy(mappedData, &constantBufferData, sizeof(constantBufferData));
     vmaUnmapMemory(allocator, alloc);
 }
 else
 {
     // Allocation ended up in non-mappable memory.
     // You need to create CPU-side buffer in VMA_MEMORY_USAGE_CPU_ONLY and make a transfer.
 }

You can even use ALLOCATION_CREATE_MAPPED_BIT flag while creating allocations that are not necessarily HOST_VISIBLE (e.g. using MEMORY_USAGE_GPU_ONLY). If the allocation ends up in memory type that is HOST_VISIBLE, it will be persistently mapped and you can use it directly. If not, the flag is just ignored. Example:

 VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
 bufCreateInfo.size = sizeof(ConstantBuffer);
 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_MAPPED_BIT;
 
 VkBuffer buf;
 VmaAllocation alloc;
 VmaAllocationInfo allocInfo;
 vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo);
 
 if(allocInfo.pUserData != nullptr)
 {
     // Allocation ended up in mappable memory.
     // It's persistently mapped. You can access it directly.
     memcpy(allocInfo.pMappedData, &constantBufferData, sizeof(constantBufferData));
 }
 else
 {
     // Allocation ended up in non-mappable memory.
     // You need to create CPU-side buffer in VMA_MEMORY_USAGE_CPU_ONLY and make a transfer.
 }

Staying within budget

When developing a graphics-intensive game or program, it is important to avoid allocating more GPU memory than it's physically available. When the memory is over-committed, various bad things can happen, depending on the specific GPU, graphics driver, and operating system:

• It may just work without any problems.
• The application may slow down because some memory blocks are moved to system RAM and the GPU has to access them through PCI Express bus.
• A new allocation may take very long time to complete, even few seconds, and possibly freeze entire system.
• The new allocation may fail with VK_ERROR_OUT_OF_DEVICE_MEMORY.
• It may even result in GPU crash (TDR), observed as VK_ERROR_DEVICE_LOST returned somewhere later.

Querying for budget

To query for current memory usage and available budget, use function GetBudget. Returned structure VmaBudget contains quantities expressed in bytes, per Vulkan memory heap.

Please note that this function returns different information and works faster than CalculateStats. vmaGetBudget() can be called every frame or even before every allocation, while vmaCalculateStats() is intended to be used rarely, only to obtain statistical information, e.g. for debugging purposes.

It is recommended to use VK_EXT_memory_budget device extension to obtain information about the budget from Vulkan device. VMA is able to use this extension automatically. When not enabled, the allocator behaves same way, but then it estimates current usage and available budget based on its internal information and Vulkan memory heap sizes, which may be less precise. In order to use this extension:

1. Make sure extensions VK_EXT_memory_budget and VK_KHR_get_physical_device_properties2 required by it are available and enable them. Please note that the first is a device extension and the second is instance extension!
2. Use flag ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT when creating VmaAllocator object.
3. Make sure to call SetCurrentFrameIndex every frame. Budget is queried from Vulkan inside of it to avoid overhead of querying it with every allocation.

Controlling memory usage

There are many ways in which you can try to stay within the budget.

First, when making new allocation requires allocating a new memory block, the library tries not to exceed the budget automatically. If a block with default recommended size (e.g. 256 MB) would go over budget, a smaller block is allocated, possibly even dedicated memory for just this resource.

If the size of the requested resource plus current memory usage is more than the budget, by default the library still tries to create it, leaving it to the Vulkan implementation whether the allocation succeeds or fails. You can change this behavior by using ALLOCATION_CREATE_WITHIN_BUDGET_BIT flag. With it, the allocation is not made if it would exceed the budget or if the budget is already exceeded. Some other allocations become lost instead to make room for it, if the mechanism of lost allocations is used. If that is not possible, the allocation fails with VK_ERROR_OUT_OF_DEVICE_MEMORY. Example usage pattern may be to pass the VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BIT flag when creating resources that are not essential for the application (e.g. the texture of a specific object) and not to pass it when creating critically important resources (e.g. render targets).

Finally, you can also use ALLOCATION_CREATE_NEVER_ALLOCATE_BIT flag to make sure a new allocation is created only when it fits inside one of the existing memory blocks. If it would require to allocate a new block, if fails instead with VK_ERROR_OUT_OF_DEVICE_MEMORY. This also ensures that the function call is very fast because it never goes to Vulkan to obtain a new block.

Please note that creating custom memory pools with VmaPoolCreateInfo::minBlockCount set to more than 0 will try to allocate memory blocks without checking whether they fit within budget.

Custom memory pools

A memory pool contains a number of VkDeviceMemory blocks. The library automatically creates and manages default pool for each memory type available on the device. Default memory pool automatically grows in size. Size of allocated blocks is also variable and managed automatically.

You can create custom pool and allocate memory out of it. It can be useful if you want to:

• Keep certain kind of allocations separate from others.
• Enforce particular, fixed size of Vulkan memory blocks.
• Limit maximum amount of Vulkan memory allocated for that pool.
• Reserve minimum or fixed amount of Vulkan memory always preallocated for that pool.

To use custom memory pools:

1. Fill VmaPoolCreateInfo structure.
2. Call CreatePool to obtain VmaPool handle.
3. When making an allocation, set VmaAllocationCreateInfo::pool to this handle. You don't need to specify any other parameters of this structure, like usage.

Example:

 // Create a pool that can have at most 2 blocks, 128 MiB 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);

Choosing memory type index

When creating a pool, you must explicitly specify memory type index. To find the one suitable for your buffers or images, you can use helper functions FindMemoryTypeIndexForBufferInfo, FindMemoryTypeIndexForImageInfo. You need to provide structures with example parameters of buffers or images that you are going to create in that pool.

 VkBufferCreateInfo exampleBufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
 exampleBufCreateInfo.size = 1024; // Whatever.
 exampleBufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT; // Change if needed.
 
 VmaAllocationCreateInfo allocCreateInfo = {};
 allocCreateInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY; // Change if needed.
 
 uint32_t memTypeIndex;
 vmaFindMemoryTypeIndexForBufferInfo(allocator, &exampleBufCreateInfo, &allocCreateInfo, &memTypeIndex);
 
 VmaPoolCreateInfo poolCreateInfo = {};
 poolCreateInfo.memoryTypeIndex = memTypeIndex;
 // ...

When creating buffers/images allocated in that pool, provide following parameters:

• VkBufferCreateInfo: Prefer to pass same parameters as above. Otherwise you risk creating resources in a memory type that is not suitable for them, which may result in undefined behavior. Using different VK_BUFFER_USAGE_ flags may work, but you shouldn't create images in a pool intended for buffers or the other way around.
• VmaAllocationCreateInfo: You don't need to pass same parameters. Fill only pool member. Other members are ignored anyway.

Linear allocation algorithm

Each Vulkan memory block managed by this library has accompanying metadata that keeps track of used and unused regions. By default, the metadata structure and algorithm tries to find best place for new allocations among free regions to optimize memory usage. This way you can allocate and free objects in any order.

Sometimes there is a need to use simpler, linear allocation algorithm. You can create custom pool that uses such algorithm by adding flag POOL_CREATE_LINEAR_ALGORITHM_BIT to VmaPoolCreateInfo::flags while creating VmaPool object. Then an alternative metadata management is used. It always creates new allocations after last one and doesn't reuse free regions after allocations freed in the middle. It results in better allocation performance and less memory consumed by metadata.

With this one flag, you can create a custom pool that can be used in many ways: free-at-once, stack, double stack, and ring buffer. See below for details.

Free-at-once

In a pool that uses linear algorithm, you still need to free all the allocations individually, e.g. by using FreeMemory or DestroyBuffer. You can free them in any order. New allocations are always made after last one - free space in the middle is not reused. However, when you release all the allocation and the pool becomes empty, allocation starts from the beginning again. This way you can use linear algorithm to speed up creation of allocations that you are going to release all at once.

This mode is also available for pools created with VmaPoolCreateInfo::maxBlockCount value that allows multiple memory blocks.

Stack

When you free an allocation that was created last, its space can be reused. Thanks to this, if you always release allocations in the order opposite to their creation (LIFO - Last In First Out), you can achieve behavior of a stack.

This mode is also available for pools created with VmaPoolCreateInfo::maxBlockCount value that allows multiple memory blocks.

Double stack

The space reserved by a custom pool with linear algorithm may be used by two stacks:

• First, default one, growing up from offset 0.
• Second, "upper" one, growing down from the end towards lower offsets.

To make allocation from upper stack, add flag ALLOCATION_CREATE_UPPER_ADDRESS_BIT to VmaAllocationCreateInfo::flags.

Double stack is available only in pools with one memory block - VmaPoolCreateInfo::maxBlockCount must be 1. Otherwise behavior is undefined.

When the two stacks' ends meet so there is not enough space between them for a new allocation, such allocation fails with usual VK_ERROR_OUT_OF_DEVICE_MEMORY error.

Ring buffer

When you free some allocations from the beginning and there is not enough free space for a new one at the end of a pool, allocator's "cursor" wraps around to the beginning and starts allocation there. Thanks to this, if you always release allocations in the same order as you created them (FIFO - First In First Out), you can achieve behavior of a ring buffer / queue.

Pools with linear algorithm support lost allocations when used as ring buffer. If there is not enough free space for a new allocation, but existing allocations from the front of the queue can become lost, they become lost and the allocation succeeds.

Ring buffer is available only in pools with one memory block - VmaPoolCreateInfo::maxBlockCount must be 1. Otherwise behavior is undefined.

Buddy allocation algorithm

There is another allocation algorithm that can be used with custom pools, called "buddy". Its internal data structure is based on a tree of blocks, each having size that is a power of two and a half of its parent's size. When you want to allocate memory of certain size, a free node in the tree is located. If it's too large, it is recursively split into two halves (called "buddies"). However, if requested allocation size is not a power of two, the size of a tree node is aligned up to the nearest power of two and the remaining space is wasted. When two buddy nodes become free, they are merged back into one larger node.

The advantage of buddy allocation algorithm over default algorithm is faster allocation and deallocation, as well as smaller external fragmentation. The disadvantage is more wasted space (internal fragmentation).

For more information, please read "Buddy memory allocation" on Wikipedia or other sources that describe this concept in general.

To use buddy allocation algorithm with a custom pool, add flag POOL_CREATE_BUDDY_ALGORITHM_BIT to VmaPoolCreateInfo::flags while creating VmaPool object.

Several limitations apply to pools that use buddy algorithm:

• It is recommended to use VmaPoolCreateInfo::blockSize that is a power of two. Otherwise, only largest power of two smaller than the size is used for allocations. The remaining space always stays unused.
• Margins and corruption detection don't work in such pools.
• Lost allocations don't work in such pools. You can use them, but they never become lost. Support may be added in the future.
• Defragmentation doesn't work with allocations made from such pool.

Defragmentation

Interleaved allocations and deallocations of many objects of varying size cause fragmentation over time, 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 defragmentation feature: VmaDefragmentationInfo2, DefragmentationBegin, DefragmentationEnd. Given set of allocations, this function can move them to compact used memory, ensure more continuous free space and possibly also free some VkDeviceMemory blocks.

What the defragmentation does is:

• Updates VmaAllocation objects to point to new VkDeviceMemory and offset. After allocation has been moved, its VmaAllocationInfo::deviceMemory and/or VmaAllocationInfo::offset changes. You must query them again using GetAllocationInfo if you need them.
• Moves actual data in memory.

What it doesn't do, so you need to do it yourself:

• Recreate buffers and images that were bound to allocations that were defragmented and bind them with their new places in memory. You must use vkDestroyBuffer(), vkDestroyImage(), vkCreateBuffer(), vkCreateImage(), BindBufferMemory, BindImageMemory for that purpose and NOT DestroyBuffer, DestroyImage, CreateBuffer, CreateImage, because you don't need to destroy or create allocation objects!
• Recreate views and update descriptors that point to these buffers and images.

Defragmenting CPU memory

Following example demonstrates how you can run defragmentation on CPU. Only allocations created in memory types that are HOST_VISIBLE can be defragmented. Others are ignored.

The way it works is:

• It temporarily maps entire memory blocks when necessary.
• It moves data using memmove() function.

 // Given following variables already initialized:
 VkDevice device;
 VmaAllocator allocator;
 std::vector<VkBuffer> buffers;
 std::vector<VmaAllocation> allocations;
 
 
 const uint32_t allocCount = (uint32_t)allocations.size();
 std::vector<VkBool32> allocationsChanged(allocCount);
 
 VmaDefragmentationInfo2 defragInfo = {};
 defragInfo.allocationCount = allocCount;
 defragInfo.pAllocations = allocations.data();
 defragInfo.pAllocationsChanged = allocationsChanged.data();
 defragInfo.maxCpuBytesToMove = VK_WHOLE_SIZE; // No limit.
 defragInfo.maxCpuAllocationsToMove = UINT32_MAX; // No limit.
 
 VmaDefragmentationContext defragCtx;
 vmaDefragmentationBegin(allocator, &defragInfo, nullptr, &defragCtx);
 vmaDefragmentationEnd(allocator, defragCtx);
 
 for(uint32_t i = 0; i < allocCount; ++i)
 {
     if(allocationsChanged[i])
     {
         // Destroy buffer that is immutably bound to memory region which is no longer valid.
         vkDestroyBuffer(device, buffers[i], nullptr);
 
         // Create new buffer with same parameters.
         VkBufferCreateInfo bufferInfo = ...;
         vkCreateBuffer(device, &bufferInfo, nullptr, &buffers[i]);
 
         // You can make dummy call to vkGetBufferMemoryRequirements here to silence validation layer warning.
 
         // Bind new buffer to new memory region. Data contained in it is already moved.
         VmaAllocationInfo allocInfo;
         vmaGetAllocationInfo(allocator, allocations[i], &allocInfo);
         vmaBindBufferMemory(allocator, allocations[i], buffers[i]);
     }
 }

Setting VmaDefragmentationInfo2::pAllocationsChanged is optional. This output array tells whether particular allocation in VmaDefragmentationInfo2::pAllocations at the same index has been modified during defragmentation. You can pass null, but you then need to query every allocation passed to defragmentation for new parameters using GetAllocationInfo if you might need to recreate and rebind a buffer or image associated with it.

If you use Custom memory pools, you can fill VmaDefragmentationInfo2::poolCount and VmaDefragmentationInfo2::pPools instead of VmaDefragmentationInfo2::allocationCount and VmaDefragmentationInfo2::pAllocations to defragment all allocations in given pools. You cannot use VmaDefragmentationInfo2::pAllocationsChanged in that case. You can also combine both methods.

Defragmenting GPU memory

It is also possible to defragment allocations created in memory types that are not HOST_VISIBLE. To do that, you need to pass a command buffer that meets requirements as described in VmaDefragmentationInfo2::commandBuffer. The way it works is:

• It creates temporary buffers and binds them to entire memory blocks when necessary.
• It issues vkCmdCopyBuffer() to passed command buffer.

Example:

 // Given following variables already initialized:
 VkDevice device;
 VmaAllocator allocator;
 VkCommandBuffer commandBuffer;
 std::vector<VkBuffer> buffers;
 std::vector<VmaAllocation> allocations;
 
 
 const uint32_t allocCount = (uint32_t)allocations.size();
 std::vector<VkBool32> allocationsChanged(allocCount);
 
 VkCommandBufferBeginInfo cmdBufBeginInfo = ...;
 vkBeginCommandBuffer(commandBuffer, &cmdBufBeginInfo);
 
 VmaDefragmentationInfo2 defragInfo = {};
 defragInfo.allocationCount = allocCount;
 defragInfo.pAllocations = allocations.data();
 defragInfo.pAllocationsChanged = allocationsChanged.data();
 defragInfo.maxGpuBytesToMove = VK_WHOLE_SIZE; // Notice it's "GPU" this time.
 defragInfo.maxGpuAllocationsToMove = UINT32_MAX; // Notice it's "GPU" this time.
 defragInfo.commandBuffer = commandBuffer;
 
 VmaDefragmentationContext defragCtx;
 vmaDefragmentationBegin(allocator, &defragInfo, nullptr, &defragCtx);
 
 vkEndCommandBuffer(commandBuffer);
 
 // Submit commandBuffer.
 // Wait for a fence that ensures commandBuffer execution finished.
 
 vmaDefragmentationEnd(allocator, defragCtx);
 
 for(uint32_t i = 0; i < allocCount; ++i)
 {
     if(allocationsChanged[i])
     {
         // Destroy buffer that is immutably bound to memory region which is no longer valid.
         vkDestroyBuffer(device, buffers[i], nullptr);
 
         // Create new buffer with same parameters.
         VkBufferCreateInfo bufferInfo = ...;
         vkCreateBuffer(device, &bufferInfo, nullptr, &buffers[i]);
 
         // You can make dummy call to vkGetBufferMemoryRequirements here to silence validation layer warning.
 
         // Bind new buffer to new memory region. Data contained in it is already moved.
         VmaAllocationInfo allocInfo;
         vmaGetAllocationInfo(allocator, allocations[i], &allocInfo);
         vmaBindBufferMemory(allocator, allocations[i], buffers[i]);
     }
 }

You can combine these two methods by specifying non-zero maxGpu* as well as maxCpu* parameters. The library automatically chooses best method to defragment each memory pool.

You may try not to block your entire program to wait until defragmentation finishes, but do it in the background, as long as you carefully fullfill requirements described in function DefragmentationBegin.

Additional notes

It is only legal to defragment allocations bound to:

• buffers
• images created with VK_IMAGE_CREATE_ALIAS_BIT, VK_IMAGE_TILING_LINEAR, and being currently in VK_IMAGE_LAYOUT_GENERAL or VK_IMAGE_LAYOUT_PREINITIALIZED.

Defragmentation of images created with VK_IMAGE_TILING_OPTIMAL or in any other layout may give undefined results.

If you defragment allocations bound to images, new images to be bound to new memory region after defragmentation should be created with VK_IMAGE_LAYOUT_PREINITIALIZED and then transitioned to their original layout from before defragmentation if needed using an image memory barrier.

While using defragmentation, you may experience validation layer warnings, which you just need to ignore.

Please don't expect memory to be fully compacted after defragmentation. Algorithms inside are based on some heuristics that try to maximize number of Vulkan memory blocks to make totally empty to release them, as well as to maximize continuous empty space inside remaining blocks, while minimizing the number and size of allocations that need to be moved. Some fragmentation may still remain - this is normal.

Writing custom defragmentation algorithm

If you want to implement your own, custom defragmentation algorithm, there is infrastructure prepared for that, but it is not exposed through the library API - you need to hack its source code.

Here are steps needed to do this:

• Main thing you need to do is to define your own class derived from base abstract class VmaDefragmentationAlgorithm and implement your version of its pure virtual methods. See definition and comments of this class for details.
• Your code needs to interact with device memory block metadata. If you need more access to its data than it's provided by its public interface, declare your new class as a friend class e.g. in class VmaBlockMetadata_Generic.
• If you want to create a flag that would enable your algorithm or pass some additional flags to configure it, add them to VmaDefragmentationFlagBits and use them in VmaDefragmentationInfo2::flags.
• Modify function VmaBlockVectorDefragmentationContext::Begin to create object of your new class whenever needed.

Lost allocations

If your game oversubscribes video memory, it 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) than 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 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 TouchAllocation. 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. GetAllocationInfo can also be used for checking status of the allocation. Allocation is lost when returned VmaAllocationInfo::deviceMemory == VK_NULL_HANDLE.

To create an allocation that can make some other allocations lost to make room for it, use ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag. You will usually use both flags ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT and 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 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.

Q: 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 TouchAllocation / GetAllocationInfo not only returns allocation status/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.

Q: 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 TouchAllocation / GetAllocationInfo 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).

Q: How do you inform the library when new frame starts?

You need to call function SetCurrentFrameIndex.

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.
         if(vmaTouchAllocation(allocator, m_Alloc))
         {
             // 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.

You can create an allocation that is already in lost state from the beginning using function CreateLostAllocation. It may be useful if you need a "dummy" allocation that is not null.

You can call function MakePoolAllocationsLost to set all eligible allocations in a specified custom pool to lost state. Allocations that have been "touched" in current frame or VmaPoolCreateInfo::frameInUseCount frames back cannot become lost.

Q: Can I touch allocation that cannot become lost?

Yes, although it has no visible effect. Calls to GetAllocationInfo and TouchAllocation update last use frame index also for allocations that cannot become lost, but the only way to observe it is to dump internal allocator state using BuildStatsString. You can use this feature for debugging purposes to explicitly mark allocations that you use in current frame and then analyze JSON dump to see for how long each allocation stays unused.

Statistics

This library contains functions that return information about its internal state, especially the amount of memory allocated from Vulkan. Please keep in mind that these functions need to traverse all internal data structures to gather these information, so they may be quite time-consuming. Don't call them too often.

Numeric statistics

You can query for overall statistics of the allocator using function CalculateStats. Information are returned using structure VmaStats. It contains VmaStatInfo - number of allocated blocks, number of allocations (occupied ranges in these blocks), number of unused (free) ranges in these blocks, number of bytes used and unused (but still allocated from Vulkan) and other information. They are summed across memory heaps, memory types and total for whole allocator.

You can query for statistics of a custom pool using function GetPoolStats. Information are returned using structure VmaPoolStats.

You can query for information about specific allocation using function GetAllocationInfo. It fill structure VmaAllocationInfo.

JSON dump

You can dump internal state of the allocator to a string in JSON format using function BuildStatsString. The result is guaranteed to be correct JSON. It uses ANSI encoding. Any strings provided by user are copied as-is and properly escaped for JSON, so if they use UTF-8, ISO-8859-2 or any other encoding, this JSON string can be treated as using this encoding. It must be freed using function FreeStatsString.

The format of this JSON string is not part of official documentation of the library, but it will not change in backward-incompatible way without increasing library major version number and appropriate mention in changelog.

The JSON string contains all the data that can be obtained using CalculateStats. It can also contain detailed map of allocated memory blocks and their regions - free and occupied by allocations. This allows e.g. to visualize the memory or assess fragmentation.

Allocation names and user data

Allocation user data

You can annotate allocations with your own information, e.g. for debugging purposes. To do that, fill VmaAllocationCreateInfo::pUserData field when creating an allocation. It's an opaque void* pointer. You can use it e.g. as a pointer, some handle, index, key, ordinal number or any other value that would associate the allocation with your custom metadata.

 VkBufferCreateInfo bufferInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
 // Fill bufferInfo...
 
 MyBufferMetadata* pMetadata = CreateBufferMetadata();
 
 VmaAllocationCreateInfo allocCreateInfo = {};
 allocCreateInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY;
 allocCreateInfo.pUserData = pMetadata;
 
 VkBuffer buffer;
 VmaAllocation allocation;
 vmaCreateBuffer(allocator, &bufferInfo, &allocCreateInfo, &buffer, &allocation, nullptr);

The pointer may be later retrieved as VmaAllocationInfo::pUserData:

 VmaAllocationInfo allocInfo;
 vmaGetAllocationInfo(allocator, allocation, &allocInfo);
 MyBufferMetadata* pMetadata = (MyBufferMetadata*)allocInfo.pUserData;

It can also be changed using function SetAllocationUserData.

Values of (non-zero) allocations' pUserData are printed in JSON report created by BuildStatsString, in hexadecimal form.

Allocation names

There is alternative mode available where pUserData pointer is used to point to a null-terminated string, giving a name to the allocation. To use this mode, set ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT flag in VmaAllocationCreateInfo::flags. Then pUserData passed as VmaAllocationCreateInfo::pUserData or argument to SetAllocationUserData must be either null or pointer to a null-terminated string. The library creates internal copy of the string, so the pointer you pass doesn't need to be valid for whole lifetime of the allocation. You can free it after the call.

 VkImageCreateInfo imageInfo = { VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO };
 // Fill imageInfo...
 
 std::string imageName = "Texture: ";
 imageName += fileName;
 
 VmaAllocationCreateInfo allocCreateInfo = {};
 allocCreateInfo.usage = VMA_MEMORY_USAGE_GPU_ONLY;
 allocCreateInfo.flags = VMA_ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT;
 allocCreateInfo.pUserData = imageName.c_str();
 
 VkImage image;
 VmaAllocation allocation;
 vmaCreateImage(allocator, &imageInfo, &allocCreateInfo, &image, &allocation, nullptr);

The value of pUserData pointer of the allocation will be different than the one you passed when setting allocation's name - pointing to a buffer managed internally that holds copy of the string.

 VmaAllocationInfo allocInfo;
 vmaGetAllocationInfo(allocator, allocation, &allocInfo);
 const char* imageName = (const char*)allocInfo.pUserData;
 printf("Image name: %s\n", imageName);

That string is also printed in JSON report created by BuildStatsString.

Debugging incorrect memory usage

If you suspect a bug with memory usage, like usage of uninitialized memory or memory being overwritten out of bounds of an allocation, you can use debug features of this library to verify this.

Memory initialization

If you experience a bug with incorrect and nondeterministic data in your program and you suspect uninitialized memory to be used, you can enable automatic memory initialization to verify this. To do it, define macro VMA_DEBUG_INITIALIZE_ALLOCATIONS to 1.

It makes memory of all new allocations initialized to bit pattern 0xDCDCDCDC. Before an allocation is destroyed, its memory is filled with bit pattern 0xEFEFEFEF. Memory is automatically mapped and unmapped if necessary.

If you find these values while debugging your program, good chances are that you incorrectly read Vulkan memory that is allocated but not initialized, or already freed, respectively.

Memory initialization works only with memory types that are HOST_VISIBLE. It works also with dedicated allocations. It doesn't work with allocations created with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT flag, as they cannot be mapped.

Margins

By default, allocations are laid out in memory blocks next to each other if possible (considering required alignment, bufferImageGranularity, and nonCoherentAtomSize).

Define macro VMA_DEBUG_MARGIN to some non-zero value (e.g. 16) to enforce specified number of bytes as a margin before and after every allocation.

If your bug goes away after enabling margins, it means it may be caused by memory being overwritten outside of allocation boundaries. It is not 100% certain though. Change in application behavior may also be caused by different order and distribution of allocations across memory blocks after margins are applied.

The margin is applied also before first and after last allocation in a block. It may occur only once between two adjacent allocations.

Margins work with all types of memory.

Margin is applied only to allocations made out of memory blocks and not to dedicated allocations, which have their own memory block of specific size. It is thus not applied to allocations made using ALLOCATION_CREATE_DEDICATED_MEMORY_BIT flag or those automatically decided to put into dedicated allocations, e.g. due to its large size or recommended by VK_KHR_dedicated_allocation extension. Margins are also not active in custom pools created with POOL_CREATE_BUDDY_ALGORITHM_BIT flag.

Margins appear in JSON dump as part of free space.

Note that enabling margins increases memory usage and fragmentation.

Corruption detection

You can additionally define macro VMA_DEBUG_DETECT_CORRUPTION to 1 to enable validation of contents of the margins.

When this feature is enabled, number of bytes specified as VMA_DEBUG_MARGIN (it must be multiple of 4) before and after every allocation is filled with a magic number. This idea is also know as "canary". Memory is automatically mapped and unmapped if necessary.

This number is validated automatically when the allocation is destroyed. If it's not equal to the expected value, VMA_ASSERT() is executed. It clearly means that either CPU or GPU overwritten the memory outside of boundaries of the allocation, which indicates a serious bug.

You can also explicitly request checking margins of all allocations in all memory blocks that belong to specified memory types by using function CheckCorruption, or in memory blocks that belong to specified custom pool, by using function CheckPoolCorruption.

Margin validation (corruption detection) works only for memory types that are HOST_VISIBLE and HOST_COHERENT.

Record and replay

Introduction

While using the library, sequence of calls to its functions together with their parameters can be recorded to a file and later replayed using standalone player application. It can be useful to:

• Test correctness - check if same sequence of calls will not cause crash or failures on a target platform.
• Gather statistics - see number of allocations, peak memory usage, number of calls etc.
• Benchmark performance - see how much time it takes to replay the whole sequence.

Usage

Recording functionality is disabled by default. To enable it, define following macro before every include of this library:

 #define VMA_RECORDING_ENABLED 1

To record sequence of calls to a file: Fill in VmaAllocatorCreateInfo::pRecordSettings member while creating VmaAllocator object. File is opened and written during whole lifetime of the allocator.

To replay file: Use VmaReplay - standalone command-line program. Precompiled binary can be found in "bin" directory. Its source can be found in "src/VmaReplay" directory. Its project is generated by Premake. Command line syntax is printed when the program is launched without parameters. Basic usage:

 VmaReplay.exe MyRecording.csv

Documentation of file format can be found in file: "docs/Recording file format.md". It's a human-readable, text file in CSV format (Comma Separated Values).

Additional considerations

• Replaying file that was recorded on a different GPU (with different parameters like bufferImageGranularity, nonCoherentAtomSize, and especially different set of memory heaps and types) may give different performance and memory usage results, as well as issue some warnings and errors.
• Current implementation of recording in VMA, as well as VmaReplay application, is coded and tested only on Windows. Inclusion of recording code is driven by VMA_RECORDING_ENABLED macro. Support for other platforms should be easy to add. Contributions are welcomed.

Recommended usage patterns

See also slides from talk: Sawicki, Adam. Advanced Graphics Techniques Tutorial: Memory management in Vulkan and DX12. Game Developers Conference, 2018

Common mistakes

Use of CPU_TO_GPU instead of CPU_ONLY memory

MEMORY_USAGE_CPU_TO_GPU is recommended only for resources that will be mapped and written by the CPU, as well as read directly by the GPU - like some buffers or textures updated every frame (dynamic). If you create a staging copy of a resource to be written by CPU and then used as a source of transfer to another resource placed in the GPU memory, that staging resource should be created with MEMORY_USAGE_CPU_ONLY. Please read the descriptions of these enums carefully for details.

Unnecessary use of custom pools

Custom memory pools may be useful for special purposes - when you want to keep certain type of resources separate e.g. to reserve minimum amount of memory for them, limit maximum amount of memory they can occupy, or make some of them push out the other through the mechanism of lost allocations. For most resources this is not needed and so it is not recommended to create VmaPool objects and allocations out of them. Allocating from the default pool is sufficient.

Simple patterns

Render targets

When: Any resources that you frequently write and read on GPU, e.g. images used as color attachments (aka "render targets"), depth-stencil attachments, images/buffers used as storage image/buffer (aka "Unordered Access View (UAV)").

What to do: Create them in video memory that is fastest to access from GPU using MEMORY_USAGE_GPU_ONLY.

Consider using VK_KHR_dedicated_allocation extension and/or manually creating them as dedicated allocations using ALLOCATION_CREATE_DEDICATED_MEMORY_BIT, especially if they are large or if you plan to destroy and recreate them e.g. when display resolution changes. Prefer to create such resources first and all other GPU resources (like textures and vertex buffers) later.

Immutable resources

When: Any resources that you fill on CPU only once (aka "immutable") or infrequently and then read frequently on GPU, e.g. textures, vertex and index buffers, constant buffers that don't change often.

What to do: Create them in video memory that is fastest to access from GPU using MEMORY_USAGE_GPU_ONLY.

To initialize content of such resource, create a CPU-side (aka "staging") copy of it in system memory - MEMORY_USAGE_CPU_ONLY, map it, fill it, and submit a transfer from it to the GPU resource. You can keep the staging copy if you need it for another upload transfer in the future. If you don't, you can destroy it or reuse this buffer for uploading different resource after the transfer finishes.

Prefer to create just buffers in system memory rather than images, even for uploading textures. Use vkCmdCopyBufferToImage(). Dont use images with VK_IMAGE_TILING_LINEAR.

Dynamic resources

When: Any resources that change frequently (aka "dynamic"), e.g. every frame or every draw call, written on CPU, read on GPU.

What to do: Create them using MEMORY_USAGE_CPU_TO_GPU. You can map it and write to it directly on CPU, as well as read from it on GPU.

This is a more complex situation. Different solutions are possible, and the best one depends on specific GPU type, but you can use this simple approach for the start. Prefer to write to such resource sequentially (e.g. using memcpy). Don't perform random access or any reads from it on CPU, as it may be very slow.

Readback

When: Resources that contain data written by GPU that you want to read back on CPU, e.g. results of some computations.

What to do: Create them using MEMORY_USAGE_GPU_TO_CPU. You can write to them directly on GPU, as well as map and read them on CPU.

Advanced patterns

Detecting integrated graphics

You can support integrated graphics (like Intel HD Graphics, AMD APU) better by detecting it in Vulkan. To do it, call vkGetPhysicalDeviceProperties(), inspect VkPhysicalDeviceProperties::deviceType and look for VK_PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU. When you find it, you can assume that memory is unified and all memory types are comparably fast to access from GPU, regardless of VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT.

You can then sum up sizes of all available memory heaps and treat them as useful for your GPU resources, instead of only DEVICE_LOCAL ones. You can also prefer to create your resources in memory types that are HOST_VISIBLE to map them directly instead of submitting explicit transfer (see below).

Direct access versus transfer

For resources that you frequently write on CPU and read on GPU, many solutions are possible:

1. Create one copy in video memory using MEMORY_USAGE_GPU_ONLY, second copy in system memory using MEMORY_USAGE_CPU_ONLY and submit explicit tranfer each time.
2. Create just single copy using MEMORY_USAGE_CPU_TO_GPU, map it and fill it on CPU, read it directly on GPU.
3. Create just single copy using MEMORY_USAGE_CPU_ONLY, map it and fill it on CPU, read it directly on GPU.

Which solution is the most efficient depends on your resource and especially on the GPU. It is best to measure it and then make the decision. Some general recommendations:

• On integrated graphics use (2) or (3) to avoid unnecesary time and memory overhead related to using a second copy and making transfer.
• For small resources (e.g. constant buffers) use (2). Discrete AMD cards have special 256 MiB pool of video memory that is directly mappable. Even if the resource ends up in system memory, its data may be cached on GPU after first fetch over PCIe bus.
• For larger resources (e.g. textures), decide between (1) and (2). You may want to differentiate NVIDIA and AMD, e.g. by looking for memory type that is both DEVICE_LOCAL and HOST_VISIBLE. When you find it, use (2), otherwise use (1).

Similarly, for resources that you frequently write on GPU and read on CPU, multiple solutions are possible:

1. Create one copy in video memory using MEMORY_USAGE_GPU_ONLY, second copy in system memory using MEMORY_USAGE_GPU_TO_CPU and submit explicit transfer each time.
2. Create just single copy using MEMORY_USAGE_GPU_TO_CPU, write to it directly on GPU, map it and read it on CPU.

You should take some measurements to decide which option is faster in case of your specific resource.

If you don't want to specialize your code for specific types of GPUs, you can still make an simple optimization for cases when your resource ends up in mappable memory to use it directly in this case instead of creating CPU-side staging copy. For details see Finding out if memory is mappable.

Configuration

Custom host memory allocator

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.

Device memory allocation callbacks

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.

Device heap memory limit

When device memory of certain heap runs out of free space, new allocations may fail (returning error code) or they may succeed, silently pushing some existing memory blocks from GPU VRAM to system RAM (which degrades performance). This behavior is implementation-dependant - it depends on GPU vendor and graphics driver.

On AMD cards it can be controlled while creating Vulkan device object by using VK_AMD_memory_overallocation_behavior extension, if available.

Alternatively, if you want to test how your program behaves with limited amount of Vulkan devicememory 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.

VK_KHR_dedicated_allocation

VK_KHR_dedicated_allocation is a Vulkan extension which can be used to improve performance on some GPUs. It augments Vulkan API with possibility to query driver whether it prefers particular buffer or image to have its own, dedicated allocation (separate VkDeviceMemory block) for better efficiency - to be able to do some internal optimizations.

The extension is supported by this library. It will be used automatically when enabled. To enable it:

1 . When creating Vulkan device, check if following 2 device extensions are supported (call vkEnumerateDeviceExtensionProperties()). If yes, enable them (fill VkDeviceCreateInfo::ppEnabledExtensionNames).

• VK_KHR_get_memory_requirements2
• VK_KHR_dedicated_allocation

If you enabled these extensions:

2 . Use ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT flag when creating your VmaAllocator to inform the library that you enabled required extensions and you want the library to use them.

 allocatorInfo.flags |= VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT;
 
 vmaCreateAllocator(&allocatorInfo, &allocator);

That's all. The extension will be automatically used whenever you create a buffer using CreateBuffer or image using CreateImage.

When using the extension together with Vulkan Validation Layer, you will receive warnings like this:

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

It is OK, you should just ignore it. It happens because you use function vkGetBufferMemoryRequirements2KHR() instead of standard vkGetBufferMemoryRequirements(), while the validation layer seems to be unaware of it.

To learn more about this extension, see:

• VK_KHR_dedicated_allocation in Vulkan specification
• VK_KHR_dedicated_allocation unofficial manual

General considerations

Thread safety

• The library has no global state, so separate VmaAllocator objects can be used independently. There should be no need to create multiple such objects though - one per VkDevice is enough.
• By default, all calls to functions that take VmaAllocator as first parameter are safe to call from multiple threads simultaneously because they are synchronized internally when needed.
• When the allocator is created with ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT flag, calls to functions that take such VmaAllocator object must be synchronized externally.
• Access to a VmaAllocation object must be externally synchronized. For example, you must not call GetAllocationInfo and MapMemory from different threads at the same time if you pass the same VmaAllocation object to these functions.

Validation layer warnings

When using this library, you can meet following types of warnings issued by Vulkan validation layer. They don't necessarily indicate a bug, so you may need to just ignore them.

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

  It happens when VK_KHR_dedicated_allocation extension is enabled. vkGetBufferMemoryRequirements2KHR function is used instead, while validation layer seems to be unaware of it.

• Mapping an image with layout VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL can result in undefined behavior if this memory is used by the device. Only GENERAL or PREINITIALIZED should be used.

  It happens when you map a buffer or image, because the library maps entire VkDeviceMemory block, where different types of images and buffers may end up together, especially on GPUs with unified memory like Intel.

• Non-linear image 0xebc91 is aliased with linear buffer 0xeb8e4 which may indicate a bug.

  It happens when you use lost allocations, and a new image or buffer is created in place of an existing object that became lost. It may happen also when you use defragmentation.

Allocation algorithm

The library uses following algorithm for allocation, in order:

1. Try to find free range of memory in existing blocks.
2. If failed, try to create a new block of VkDeviceMemory, with preferred block size.
3. If failed, try to create such block with size/2, size/4, size/8.
4. If failed and ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag was specified, try to find space in existing blocks, possilby making some other allocations lost.
5. If failed, try to allocate separate VkDeviceMemory for this allocation, just like when you use ALLOCATION_CREATE_DEDICATED_MEMORY_BIT.
6. If failed, choose other memory type that meets the requirements specified in VmaAllocationCreateInfo and go to point 1.
7. If failed, return VK_ERROR_OUT_OF_DEVICE_MEMORY.

Features not supported

Features deliberately excluded from the scope of this library:

• Data transfer. Uploading (streaming) and downloading data of buffers and images between CPU and GPU memory and related synchronization is responsibility of the user.
• Defining some "texture" object that would automatically stream its data from a staging copy in CPU memory to GPU memory would rather be a feature of another, higher-level library implemented on top of VMA.
• Allocations for imported/exported external memory. They tend to require explicit memory type index and dedicated allocation anyway, so they don't interact with main features of this library. Such special purpose allocations should be made manually, using vkCreateBuffer() and vkAllocateMemory().
• Recreation of buffers and images. Although the library has functions for buffer and image creation (CreateBuffer, CreateImage), you need to recreate these objects yourself after defragmentation. That's because the big structures VkBufferCreateInfo, VkImageCreateInfo are not stored in VmaAllocation object.
• Handling CPU memory allocation failures. When dynamically creating small C++ objects in CPU memory (not Vulkan memory), allocation failures are not checked and handled gracefully, because that would complicate code significantly and is usually not needed in desktop PC applications anyway.
• Code free of any compiler warnings. Maintaining the library to compile and work correctly on so many different platforms is hard enough. Being free of any warnings, on any version of any compiler, is simply not feasible.
• This is a C++ library with C interface. Bindings or ports to any other programming languages are welcomed as external projects and are not going to be included into this repository.

Field Summary

Fields

Modifier and Type	Field and Description
static int	VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_DONT_BIND_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_MAPPED_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_NEVER_ALLOCATE_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_STRATEGY_MASK Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_UPPER_ADDRESS_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BIT Flags to be passed as VmaAllocationCreateInfo::flags.
static int	VMA_ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT Flags for created VmaAllocator.
static int	VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT Flags for created VmaAllocator.
static int	VMA_ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT Flags for created VmaAllocator.
static int	VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT Flags for created VmaAllocator.
static int	VMA_MEMORY_USAGE_CPU_COPY VmaMemoryUsage
static int	VMA_MEMORY_USAGE_CPU_ONLY VmaMemoryUsage
static int	VMA_MEMORY_USAGE_CPU_TO_GPU VmaMemoryUsage
static int	VMA_MEMORY_USAGE_GPU_LAZILY_ALLOCATED VmaMemoryUsage
static int	VMA_MEMORY_USAGE_GPU_ONLY VmaMemoryUsage
static int	VMA_MEMORY_USAGE_GPU_TO_CPU VmaMemoryUsage
static int	VMA_MEMORY_USAGE_UNKNOWN VmaMemoryUsage
static int	VMA_POOL_CREATE_ALGORITHM_MASK Flags to be passed as VmaPoolCreateInfo::flags.
static int	VMA_POOL_CREATE_BUDDY_ALGORITHM_BIT Flags to be passed as VmaPoolCreateInfo::flags.
static int	VMA_POOL_CREATE_IGNORE_BUFFER_IMAGE_GRANULARITY_BIT Flags to be passed as VmaPoolCreateInfo::flags.
static int	VMA_POOL_CREATE_LINEAR_ALGORITHM_BIT Flags to be passed as VmaPoolCreateInfo::flags.
static int	VMA_RECORD_FLUSH_AFTER_CALL_BIT Flags to be used in VmaRecordSettings::flags.

Method Summary

Modifier and Type	Method and Description
static int	nvmaAllocateMemory(long allocator, long pVkMemoryRequirements, long pCreateInfo, long pAllocation, long pAllocationInfo) Unsafe version of: AllocateMemory
static int	nvmaAllocateMemoryForBuffer(long allocator, long buffer, long pCreateInfo, long pAllocation, long pAllocationInfo) Unsafe version of: AllocateMemoryForBuffer
static int	nvmaAllocateMemoryForImage(long allocator, long image, long pCreateInfo, long pAllocation, long pAllocationInfo) Unsafe version of: AllocateMemoryForImage
static int	nvmaAllocateMemoryPages(long allocator, long pVkMemoryRequirements, long pCreateInfo, long allocationCount, long pAllocations, long pAllocationInfo) Unsafe version of: AllocateMemoryPages
static int	nvmaBindBufferMemory(long allocator, long allocation, long buffer) Unsafe version of: BindBufferMemory
static int	nvmaBindBufferMemory2(long allocator, long allocation, long allocationLocalOffset, long buffer, long pNext) Unsafe version of: BindBufferMemory2
static int	nvmaBindImageMemory(long allocator, long allocation, long image) Unsafe version of: BindImageMemory
static int	nvmaBindImageMemory2(long allocator, long allocation, long allocationLocalOffset, long image, long pNext) Unsafe version of: BindImageMemory2
static void	nvmaBuildStatsString(long allocator, long ppStatsString, int detailedMap) Unsafe version of: BuildStatsString
static void	nvmaCalculateStats(long allocator, long pStats) Unsafe version of: CalculateStats
static int	nvmaCheckCorruption(long allocator, int memoryTypeBits) Unsafe version of: CheckCorruption
static int	nvmaCheckPoolCorruption(long allocator, long pool) Unsafe version of: CheckPoolCorruption
static int	nvmaCreateAllocator(long pCreateInfo, long pAllocator) Unsafe version of: CreateAllocator
static int	nvmaCreateBuffer(long allocator, long pBufferCreateInfo, long pAllocationCreateInfo, long pBuffer, long pAllocation, long pAllocationInfo) Unsafe version of: CreateBuffer
static int	nvmaCreateImage(long allocator, long pImageCreateInfo, long pAllocationCreateInfo, long pImage, long pAllocation, long pAllocationInfo) Unsafe version of: CreateImage
static void	nvmaCreateLostAllocation(long allocator, long pAllocation) Unsafe version of: CreateLostAllocation
static int	nvmaCreatePool(long allocator, long pCreateInfo, long pPool) Unsafe version of: CreatePool
static int	nvmaDefragment(long allocator, long pAllocations, long allocationCount, long pAllocationsChanged, long pDefragmentationInfo, long pDefragmentationStats) Unsafe version of: Defragment
static int	nvmaDefragmentationBegin(long allocator, long pInfo, long pStats, long pContext) Unsafe version of: DefragmentationBegin
static int	nvmaDefragmentationEnd(long allocator, long context) Unsafe version of: DefragmentationEnd
static void	nvmaDestroyAllocator(long allocator) Unsafe version of: DestroyAllocator
static void	nvmaDestroyBuffer(long allocator, long buffer, long allocation) Unsafe version of: DestroyBuffer
static void	nvmaDestroyImage(long allocator, long image, long allocation) Unsafe version of: DestroyImage
static void	nvmaDestroyPool(long allocator, long pool) Unsafe version of: DestroyPool
static int	nvmaFindMemoryTypeIndex(long allocator, int memoryTypeBits, long pAllocationCreateInfo, long pMemoryTypeIndex) Unsafe version of: FindMemoryTypeIndex
static int	nvmaFindMemoryTypeIndexForBufferInfo(long allocator, long pBufferCreateInfo, long pAllocationCreateInfo, long pMemoryTypeIndex) Unsafe version of: FindMemoryTypeIndexForBufferInfo
static int	nvmaFindMemoryTypeIndexForImageInfo(long allocator, long pImageCreateInfo, long pAllocationCreateInfo, long pMemoryTypeIndex) Unsafe version of: FindMemoryTypeIndexForImageInfo
static void	nvmaFlushAllocation(long allocator, long allocation, long offset, long size) Unsafe version of: FlushAllocation
static void	nvmaFreeMemory(long allocator, long allocation) Unsafe version of: FreeMemory
static void	nvmaFreeMemoryPages(long allocator, long allocationCount, long pAllocations) Unsafe version of: FreeMemoryPages
static void	nvmaFreeStatsString(long allocator, long pStatsString)
static void	nvmaGetAllocationInfo(long allocator, long allocation, long pAllocationInfo) Unsafe version of: GetAllocationInfo
static void	nvmaGetBudget(long allocator, long pBudget) Unsafe version of: GetBudget
static void	nvmaGetMemoryProperties(long allocator, long ppPhysicalDeviceMemoryProperties) Unsafe version of: GetMemoryProperties
static void	nvmaGetMemoryTypeProperties(long allocator, int memoryTypeIndex, long pFlags) Unsafe version of: GetMemoryTypeProperties
static void	nvmaGetPhysicalDeviceProperties(long allocator, long ppPhysicalDeviceProperties) Unsafe version of: GetPhysicalDeviceProperties
static void	nvmaGetPoolName(long allocator, long pool, long ppName) Unsafe version of: GetPoolName
static void	nvmaGetPoolStats(long allocator, long pool, long pPoolStats) Unsafe version of: GetPoolStats
static void	nvmaInvalidateAllocation(long allocator, long allocation, long offset, long size) Unsafe version of: InvalidateAllocation
static void	nvmaMakePoolAllocationsLost(long allocator, long pool, long pLostAllocationCount) Unsafe version of: MakePoolAllocationsLost
static int	nvmaMapMemory(long allocator, long allocation, long ppData) Unsafe version of: MapMemory
static int	nvmaResizeAllocation(long allocator, long allocation, long newSize) Unsafe version of: ResizeAllocation
static void	nvmaSetAllocationUserData(long allocator, long allocation, long pUserData) Unsafe version of: SetAllocationUserData
static void	nvmaSetCurrentFrameIndex(long allocator, int frameIndex) Unsafe version of: SetCurrentFrameIndex
static void	nvmaSetPoolName(long allocator, long pool, long pName) Unsafe version of: SetPoolName
static int	nvmaTouchAllocation(long allocator, long allocation) Unsafe version of: TouchAllocation
static void	nvmaUnmapMemory(long allocator, long allocation) Unsafe version of: UnmapMemory
static int	vmaAllocateMemory(long allocator, org.lwjgl.vulkan.VkMemoryRequirements pVkMemoryRequirements, VmaAllocationCreateInfo pCreateInfo, org.lwjgl.PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) General purpose memory allocation.
static int	vmaAllocateMemoryForBuffer(long allocator, long buffer, VmaAllocationCreateInfo pCreateInfo, org.lwjgl.PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) Buffer memory allocation.
static int	vmaAllocateMemoryForImage(long allocator, long image, VmaAllocationCreateInfo pCreateInfo, org.lwjgl.PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) Function similar to AllocateMemoryForBuffer.
static int	vmaAllocateMemoryPages(long allocator, org.lwjgl.vulkan.VkMemoryRequirements pVkMemoryRequirements, VmaAllocationCreateInfo pCreateInfo, org.lwjgl.PointerBuffer pAllocations, VmaAllocationInfo.Buffer pAllocationInfo) General purpose memory allocation for multiple allocation objects at once.
static int	vmaBindBufferMemory(long allocator, long allocation, long buffer) Binds buffer to allocation.
static int	vmaBindBufferMemory2(long allocator, long allocation, long allocationLocalOffset, long buffer, long pNext) Binds buffer to allocation with additional parameters.
static int	vmaBindImageMemory(long allocator, long allocation, long image) Binds image to allocation.
static int	vmaBindImageMemory2(long allocator, long allocation, long allocationLocalOffset, long image, long pNext) Binds image to allocation with additional parameters.
static void	vmaBuildStatsString(long allocator, org.lwjgl.PointerBuffer ppStatsString, boolean detailedMap) Builds and returns statistics as string in JSON format.
static void	vmaCalculateStats(long allocator, VmaStats pStats) Retrieves statistics from current state of the Allocator.
static int	vmaCheckCorruption(long allocator, int memoryTypeBits) Checks magic number in margins around all allocations in given memory types (in both default and custom pools) in search for corruptions.
static int	vmaCheckPoolCorruption(long allocator, long pool) Checks magic number in margins around all allocations in given memory pool in search for corruptions.
static int	vmaCreateAllocator(VmaAllocatorCreateInfo pCreateInfo, org.lwjgl.PointerBuffer pAllocator) Creates Allocator object.
static int	vmaCreateBuffer(long allocator, org.lwjgl.vulkan.VkBufferCreateInfo pBufferCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, java.nio.LongBuffer pBuffer, org.lwjgl.PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) This function automatically: Creates buffer. Allocates appropriate memory for it. Binds the buffer with the memory.
static int	vmaCreateImage(long allocator, org.lwjgl.vulkan.VkImageCreateInfo pImageCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, java.nio.LongBuffer pImage, org.lwjgl.PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) Function similar to CreateBuffer.
static void	vmaCreateLostAllocation(long allocator, org.lwjgl.PointerBuffer pAllocation) Creates new allocation that is in lost state from the beginning.
static int	vmaCreatePool(long allocator, VmaPoolCreateInfo pCreateInfo, org.lwjgl.PointerBuffer pPool) Allocates Vulkan device memory and creates VmaPool object.
static int	vmaDefragment(long allocator, org.lwjgl.PointerBuffer pAllocations, java.nio.IntBuffer pAllocationsChanged, VmaDefragmentationInfo pDefragmentationInfo, VmaDefragmentationStats pDefragmentationStats) Deprecated: This is a part of the old interface.
static int	vmaDefragmentationBegin(long allocator, VmaDefragmentationInfo2 pInfo, VmaDefragmentationStats pStats, org.lwjgl.PointerBuffer pContext) Begins defragmentation process.
static int	vmaDefragmentationEnd(long allocator, long context) Ends defragmentation process.
static void	vmaDestroyAllocator(long allocator) Destroys allocator object.
static void	vmaDestroyBuffer(long allocator, long buffer, long allocation) Destroys Vulkan buffer and frees allocated memory.
static void	vmaDestroyImage(long allocator, long image, long allocation) Destroys Vulkan image and frees allocated memory.
static void	vmaDestroyPool(long allocator, long pool) Destroys VmaPool object and frees Vulkan device memory.
static int	vmaFindMemoryTypeIndex(long allocator, int memoryTypeBits, VmaAllocationCreateInfo pAllocationCreateInfo, java.nio.IntBuffer pMemoryTypeIndex) Helps to find memoryTypeIndex, given memoryTypeBits and VmaAllocationCreateInfo.
static int	vmaFindMemoryTypeIndexForBufferInfo(long allocator, org.lwjgl.vulkan.VkBufferCreateInfo pBufferCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, java.nio.IntBuffer pMemoryTypeIndex) Helps to find memoryTypeIndex, given VkBufferCreateInfo and VmaAllocationCreateInfo.
static int	vmaFindMemoryTypeIndexForImageInfo(long allocator, org.lwjgl.vulkan.VkImageCreateInfo pImageCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, java.nio.IntBuffer pMemoryTypeIndex) Helps to find memoryTypeIndex, given VkImageCreateInfo and VmaAllocationCreateInfo.
static void	vmaFlushAllocation(long allocator, long allocation, long offset, long size) Flushes memory of given allocation.
static void	vmaFreeMemory(long allocator, long allocation) Frees memory previously allocated using AllocateMemory, AllocateMemoryForBuffer, or AllocateMemoryForImage.
static void	vmaFreeMemoryPages(long allocator, org.lwjgl.PointerBuffer pAllocations) Frees memory and destroys multiple allocations.
static void	vmaFreeStatsString(long allocator, java.nio.ByteBuffer pStatsString)
static void	vmaGetAllocationInfo(long allocator, long allocation, VmaAllocationInfo pAllocationInfo) Returns current information about specified allocation and atomically marks it as used in current frame.
static void	vmaGetBudget(long allocator, VmaBudget.Buffer pBudget) Retrieves information about current memory budget for all memory heaps.
static void	vmaGetMemoryProperties(long allocator, org.lwjgl.PointerBuffer ppPhysicalDeviceMemoryProperties) PhysicalDeviceMemoryProperties are fetched from physicalDevice by the allocator.
static void	vmaGetMemoryTypeProperties(long allocator, int memoryTypeIndex, java.nio.IntBuffer pFlags) Given Memory Type Index, returns Property Flags of this memory type.
static void	vmaGetPhysicalDeviceProperties(long allocator, org.lwjgl.PointerBuffer ppPhysicalDeviceProperties) PhysicalDeviceProperties are fetched from physicalDevice by the allocator.
static void	vmaGetPoolName(long allocator, long pool, org.lwjgl.PointerBuffer ppName) Retrieves name of a custom pool.
static void	vmaGetPoolStats(long allocator, long pool, VmaPoolStats pPoolStats) Retrieves statistics of existing VmaPool object.
static void	vmaInvalidateAllocation(long allocator, long allocation, long offset, long size) Invalidates memory of given allocation.
static long	vmaMakePoolAllocationsLost(long allocator, long pool) Marks all allocations in given pool as lost if they are not used in current frame or VmaPoolCreateInfo::frameInUseCount back from now.
static void	vmaMakePoolAllocationsLost(long allocator, long pool, org.lwjgl.PointerBuffer pLostAllocationCount) Marks all allocations in given pool as lost if they are not used in current frame or VmaPoolCreateInfo::frameInUseCount back from now.
static int	vmaMapMemory(long allocator, long allocation, org.lwjgl.PointerBuffer ppData) Maps memory represented by given allocation and returns pointer to it.
static int	vmaResizeAllocation(long allocator, long allocation, long newSize) Deprecated.
static void	vmaSetAllocationUserData(long allocator, long allocation, long pUserData) Sets pUserData in given allocation to new value.
static void	vmaSetCurrentFrameIndex(long allocator, int frameIndex) Sets index of the current frame.
static void	vmaSetPoolName(long allocator, long pool, java.nio.ByteBuffer pName) Sets name of a custom pool.
static void	vmaSetPoolName(long allocator, long pool, java.lang.CharSequence pName) Sets name of a custom pool.
static boolean	vmaTouchAllocation(long allocator, long allocation) Returns VK_TRUE if allocation is not lost and atomically marks it as used in current frame.
static void	vmaUnmapMemory(long allocator, long allocation) Unmaps memory represented by given allocation, mapped previously using MapMemory.

Methods inherited from class java.lang.Object

equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

VMA_RECORD_FLUSH_AFTER_CALL_BIT

public static final int VMA_RECORD_FLUSH_AFTER_CALL_BIT

Flags to be used in VmaRecordSettings::flags.

Enum values:

• RECORD_FLUSH_AFTER_CALL_BIT - Enables flush after recording every function call.

  Enable it if you expect your application to crash, which may leave recording file truncated. It may degrade performance though.

See Also:

Constant Field Values

VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT

public static final int VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT

Flags for created VmaAllocator. (VmaAllocatorCreateFlagBits)

Enum values:

• 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.

• ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT - Enables usage of VK_KHR_dedicated_allocation extension.

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

  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 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.

• ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT - Enables usage of VK_KHR_bind_memory2 extension.

  The flag works only if VmaAllocatorCreateInfo::vulkanApiVersion == VK_API_VERSION_1_0. When it's 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.

• ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT - 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.

See Also:

Constant Field Values

VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT

public static final int VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT

Flags for created VmaAllocator. (VmaAllocatorCreateFlagBits)

Enum values:

• 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.

• ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT - Enables usage of VK_KHR_dedicated_allocation extension.

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

  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 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.

• ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT - Enables usage of VK_KHR_bind_memory2 extension.

  The flag works only if VmaAllocatorCreateInfo::vulkanApiVersion == VK_API_VERSION_1_0. When it's 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.

• ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT - 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.

See Also:

Constant Field Values

VMA_ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT

public static final int VMA_ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT

Flags for created VmaAllocator. (VmaAllocatorCreateFlagBits)

Enum values:

• 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.

• ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT - Enables usage of VK_KHR_dedicated_allocation extension.

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

  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 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.

• ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT - Enables usage of VK_KHR_bind_memory2 extension.

  The flag works only if VmaAllocatorCreateInfo::vulkanApiVersion == VK_API_VERSION_1_0. When it's 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.

• ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT - 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.

See Also:

Constant Field Values

VMA_ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT

public static final int VMA_ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT

Flags for created VmaAllocator. (VmaAllocatorCreateFlagBits)

Enum values:

• 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.

• ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT - Enables usage of VK_KHR_dedicated_allocation extension.

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

  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 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.

• ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT - Enables usage of VK_KHR_bind_memory2 extension.

  The flag works only if VmaAllocatorCreateInfo::vulkanApiVersion == VK_API_VERSION_1_0. When it's 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.

• ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT - 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.

See Also:

Constant Field Values

VMA_MEMORY_USAGE_UNKNOWN

public static final int VMA_MEMORY_USAGE_UNKNOWN

VmaMemoryUsage

Enum values:

• MEMORY_USAGE_UNKNOWN - No intended memory usage specified.

  Use other members of VmaAllocationCreateInfo to specify your requirements.

• MEMORY_USAGE_GPU_ONLY - Memory will be used on device only, so fast access from the device is preferred.

  It usually means device-local GPU (video) memory. No need to be mappable on host. It is roughly equivalent of D3D12_HEAP_TYPE_DEFAULT.

  Usage:

  • Resources written and read by device, e.g. images used as attachments.
  • Resources transferred from host once (immutable) or infrequently and read by device multiple times, e.g. textures to be sampled, vertex buffers, uniform (constant) buffers, and majority of other types of resources used on GPU.

  Allocation may still end up in HOST_VISIBLE memory on some implementations. In such case, you are free to map it. You can use ALLOCATION_CREATE_MAPPED_BIT with this usage type.

• MEMORY_USAGE_CPU_ONLY - Memory will be mappable on host.

  It usually means CPU (system) memory. Guarantees to be HOST_VISIBLE and HOST_COHERENT. CPU access is typically uncached. Writes may be write-combined. Resources created in this pool may still be accessible to the device, but access to them can be slow. It is roughly equivalent of D3D12_HEAP_TYPE_UPLOAD.

  Usage: Staging copy of resources used as transfer source.

• MEMORY_USAGE_CPU_TO_GPU - Memory that is both mappable on host (guarantees to be HOST_VISIBLE) and preferably fast to access by GPU.

  CPU access is typically uncached. Writes may be write-combined.

  Usage: Resources written frequently by host (dynamic), read by device. E.g. textures, vertex buffers, uniform buffers updated every frame or every draw call.

• MEMORY_USAGE_GPU_TO_CPU - Memory mappable on host (guarantees to be HOST_VISIBLE) and cached.

  It is roughly equivalent of D3D12_HEAP_TYPE_READBACK.

  Usage:

  • Resources written by device, read by host - results of some computations, e.g. screen capture, average scene luminance for HDR tone mapping.
  • Any resources read or accessed randomly on host, e.g. CPU-side copy of vertex buffer used as source of transfer, but also used for collision detection.
• MEMORY_USAGE_CPU_COPY - CPU memory - memory that is preferably not DEVICE_LOCAL, but also not guaranteed to be HOST_VISIBLE.

  Usage: Staging copy of resources moved from GPU memory to CPU memory as part of custom paging/residency mechanism, to be moved back to GPU memory when needed.

• MEMORY_USAGE_GPU_LAZILY_ALLOCATED - 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.

See Also:

Constant Field Values

VMA_MEMORY_USAGE_GPU_ONLY

public static final int VMA_MEMORY_USAGE_GPU_ONLY

VmaMemoryUsage

Enum values:

• MEMORY_USAGE_UNKNOWN - No intended memory usage specified.

  Use other members of VmaAllocationCreateInfo to specify your requirements.

• MEMORY_USAGE_GPU_ONLY - Memory will be used on device only, so fast access from the device is preferred.

  It usually means device-local GPU (video) memory. No need to be mappable on host. It is roughly equivalent of D3D12_HEAP_TYPE_DEFAULT.

  Usage:

  • Resources written and read by device, e.g. images used as attachments.
  • Resources transferred from host once (immutable) or infrequently and read by device multiple times, e.g. textures to be sampled, vertex buffers, uniform (constant) buffers, and majority of other types of resources used on GPU.

  Allocation may still end up in HOST_VISIBLE memory on some implementations. In such case, you are free to map it. You can use ALLOCATION_CREATE_MAPPED_BIT with this usage type.

• MEMORY_USAGE_CPU_ONLY - Memory will be mappable on host.

  It usually means CPU (system) memory. Guarantees to be HOST_VISIBLE and HOST_COHERENT. CPU access is typically uncached. Writes may be write-combined. Resources created in this pool may still be accessible to the device, but access to them can be slow. It is roughly equivalent of D3D12_HEAP_TYPE_UPLOAD.

  Usage: Staging copy of resources used as transfer source.

• MEMORY_USAGE_CPU_TO_GPU - Memory that is both mappable on host (guarantees to be HOST_VISIBLE) and preferably fast to access by GPU.

  CPU access is typically uncached. Writes may be write-combined.

  Usage: Resources written frequently by host (dynamic), read by device. E.g. textures, vertex buffers, uniform buffers updated every frame or every draw call.

• MEMORY_USAGE_GPU_TO_CPU - Memory mappable on host (guarantees to be HOST_VISIBLE) and cached.

  It is roughly equivalent of D3D12_HEAP_TYPE_READBACK.

  Usage:

  • Resources written by device, read by host - results of some computations, e.g. screen capture, average scene luminance for HDR tone mapping.
  • Any resources read or accessed randomly on host, e.g. CPU-side copy of vertex buffer used as source of transfer, but also used for collision detection.
• MEMORY_USAGE_CPU_COPY - CPU memory - memory that is preferably not DEVICE_LOCAL, but also not guaranteed to be HOST_VISIBLE.

  Usage: Staging copy of resources moved from GPU memory to CPU memory as part of custom paging/residency mechanism, to be moved back to GPU memory when needed.

• MEMORY_USAGE_GPU_LAZILY_ALLOCATED - 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.

See Also:

Constant Field Values

VMA_MEMORY_USAGE_CPU_ONLY

public static final int VMA_MEMORY_USAGE_CPU_ONLY

VmaMemoryUsage

Enum values:

• MEMORY_USAGE_UNKNOWN - No intended memory usage specified.

  Use other members of VmaAllocationCreateInfo to specify your requirements.

• MEMORY_USAGE_GPU_ONLY - Memory will be used on device only, so fast access from the device is preferred.

  It usually means device-local GPU (video) memory. No need to be mappable on host. It is roughly equivalent of D3D12_HEAP_TYPE_DEFAULT.

  Usage:

  • Resources written and read by device, e.g. images used as attachments.
  • Resources transferred from host once (immutable) or infrequently and read by device multiple times, e.g. textures to be sampled, vertex buffers, uniform (constant) buffers, and majority of other types of resources used on GPU.

  Allocation may still end up in HOST_VISIBLE memory on some implementations. In such case, you are free to map it. You can use ALLOCATION_CREATE_MAPPED_BIT with this usage type.

• MEMORY_USAGE_CPU_ONLY - Memory will be mappable on host.

  It usually means CPU (system) memory. Guarantees to be HOST_VISIBLE and HOST_COHERENT. CPU access is typically uncached. Writes may be write-combined. Resources created in this pool may still be accessible to the device, but access to them can be slow. It is roughly equivalent of D3D12_HEAP_TYPE_UPLOAD.

  Usage: Staging copy of resources used as transfer source.

• MEMORY_USAGE_CPU_TO_GPU - Memory that is both mappable on host (guarantees to be HOST_VISIBLE) and preferably fast to access by GPU.

  CPU access is typically uncached. Writes may be write-combined.

  Usage: Resources written frequently by host (dynamic), read by device. E.g. textures, vertex buffers, uniform buffers updated every frame or every draw call.

• MEMORY_USAGE_GPU_TO_CPU - Memory mappable on host (guarantees to be HOST_VISIBLE) and cached.

  It is roughly equivalent of D3D12_HEAP_TYPE_READBACK.

  Usage:

  • Resources written by device, read by host - results of some computations, e.g. screen capture, average scene luminance for HDR tone mapping.
  • Any resources read or accessed randomly on host, e.g. CPU-side copy of vertex buffer used as source of transfer, but also used for collision detection.
• MEMORY_USAGE_CPU_COPY - CPU memory - memory that is preferably not DEVICE_LOCAL, but also not guaranteed to be HOST_VISIBLE.

  Usage: Staging copy of resources moved from GPU memory to CPU memory as part of custom paging/residency mechanism, to be moved back to GPU memory when needed.

• MEMORY_USAGE_GPU_LAZILY_ALLOCATED - 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.

See Also:

Constant Field Values

VMA_MEMORY_USAGE_CPU_TO_GPU

public static final int VMA_MEMORY_USAGE_CPU_TO_GPU

VmaMemoryUsage

Enum values:

• MEMORY_USAGE_UNKNOWN - No intended memory usage specified.

  Use other members of VmaAllocationCreateInfo to specify your requirements.

• MEMORY_USAGE_GPU_ONLY - Memory will be used on device only, so fast access from the device is preferred.

  It usually means device-local GPU (video) memory. No need to be mappable on host. It is roughly equivalent of D3D12_HEAP_TYPE_DEFAULT.

  Usage:

  • Resources written and read by device, e.g. images used as attachments.
  • Resources transferred from host once (immutable) or infrequently and read by device multiple times, e.g. textures to be sampled, vertex buffers, uniform (constant) buffers, and majority of other types of resources used on GPU.

  Allocation may still end up in HOST_VISIBLE memory on some implementations. In such case, you are free to map it. You can use ALLOCATION_CREATE_MAPPED_BIT with this usage type.

• MEMORY_USAGE_CPU_ONLY - Memory will be mappable on host.

  It usually means CPU (system) memory. Guarantees to be HOST_VISIBLE and HOST_COHERENT. CPU access is typically uncached. Writes may be write-combined. Resources created in this pool may still be accessible to the device, but access to them can be slow. It is roughly equivalent of D3D12_HEAP_TYPE_UPLOAD.

  Usage: Staging copy of resources used as transfer source.

• MEMORY_USAGE_CPU_TO_GPU - Memory that is both mappable on host (guarantees to be HOST_VISIBLE) and preferably fast to access by GPU.

  CPU access is typically uncached. Writes may be write-combined.

  Usage: Resources written frequently by host (dynamic), read by device. E.g. textures, vertex buffers, uniform buffers updated every frame or every draw call.

• MEMORY_USAGE_GPU_TO_CPU - Memory mappable on host (guarantees to be HOST_VISIBLE) and cached.

  It is roughly equivalent of D3D12_HEAP_TYPE_READBACK.

  Usage:

  • Resources written by device, read by host - results of some computations, e.g. screen capture, average scene luminance for HDR tone mapping.
  • Any resources read or accessed randomly on host, e.g. CPU-side copy of vertex buffer used as source of transfer, but also used for collision detection.
• MEMORY_USAGE_CPU_COPY - CPU memory - memory that is preferably not DEVICE_LOCAL, but also not guaranteed to be HOST_VISIBLE.

  Usage: Staging copy of resources moved from GPU memory to CPU memory as part of custom paging/residency mechanism, to be moved back to GPU memory when needed.

• MEMORY_USAGE_GPU_LAZILY_ALLOCATED - 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.

See Also:

Constant Field Values

VMA_MEMORY_USAGE_GPU_TO_CPU

public static final int VMA_MEMORY_USAGE_GPU_TO_CPU

VmaMemoryUsage

Enum values:

• MEMORY_USAGE_UNKNOWN - No intended memory usage specified.

  Use other members of VmaAllocationCreateInfo to specify your requirements.

• MEMORY_USAGE_GPU_ONLY - Memory will be used on device only, so fast access from the device is preferred.

  It usually means device-local GPU (video) memory. No need to be mappable on host. It is roughly equivalent of D3D12_HEAP_TYPE_DEFAULT.

  Usage:

  • Resources written and read by device, e.g. images used as attachments.
  • Resources transferred from host once (immutable) or infrequently and read by device multiple times, e.g. textures to be sampled, vertex buffers, uniform (constant) buffers, and majority of other types of resources used on GPU.

  Allocation may still end up in HOST_VISIBLE memory on some implementations. In such case, you are free to map it. You can use ALLOCATION_CREATE_MAPPED_BIT with this usage type.

• MEMORY_USAGE_CPU_ONLY - Memory will be mappable on host.

  It usually means CPU (system) memory. Guarantees to be HOST_VISIBLE and HOST_COHERENT. CPU access is typically uncached. Writes may be write-combined. Resources created in this pool may still be accessible to the device, but access to them can be slow. It is roughly equivalent of D3D12_HEAP_TYPE_UPLOAD.

  Usage: Staging copy of resources used as transfer source.

• MEMORY_USAGE_CPU_TO_GPU - Memory that is both mappable on host (guarantees to be HOST_VISIBLE) and preferably fast to access by GPU.

  CPU access is typically uncached. Writes may be write-combined.

  Usage: Resources written frequently by host (dynamic), read by device. E.g. textures, vertex buffers, uniform buffers updated every frame or every draw call.

• MEMORY_USAGE_GPU_TO_CPU - Memory mappable on host (guarantees to be HOST_VISIBLE) and cached.

  It is roughly equivalent of D3D12_HEAP_TYPE_READBACK.

  Usage:

  • Resources written by device, read by host - results of some computations, e.g. screen capture, average scene luminance for HDR tone mapping.
  • Any resources read or accessed randomly on host, e.g. CPU-side copy of vertex buffer used as source of transfer, but also used for collision detection.
• MEMORY_USAGE_CPU_COPY - CPU memory - memory that is preferably not DEVICE_LOCAL, but also not guaranteed to be HOST_VISIBLE.

  Usage: Staging copy of resources moved from GPU memory to CPU memory as part of custom paging/residency mechanism, to be moved back to GPU memory when needed.

• MEMORY_USAGE_GPU_LAZILY_ALLOCATED - 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.

See Also:

Constant Field Values

VMA_MEMORY_USAGE_CPU_COPY

public static final int VMA_MEMORY_USAGE_CPU_COPY

VmaMemoryUsage

Enum values:

• MEMORY_USAGE_UNKNOWN - No intended memory usage specified.

  Use other members of VmaAllocationCreateInfo to specify your requirements.

• MEMORY_USAGE_GPU_ONLY - Memory will be used on device only, so fast access from the device is preferred.

  It usually means device-local GPU (video) memory. No need to be mappable on host. It is roughly equivalent of D3D12_HEAP_TYPE_DEFAULT.

  Usage:

  • Resources written and read by device, e.g. images used as attachments.
  • Resources transferred from host once (immutable) or infrequently and read by device multiple times, e.g. textures to be sampled, vertex buffers, uniform (constant) buffers, and majority of other types of resources used on GPU.

  Allocation may still end up in HOST_VISIBLE memory on some implementations. In such case, you are free to map it. You can use ALLOCATION_CREATE_MAPPED_BIT with this usage type.

• MEMORY_USAGE_CPU_ONLY - Memory will be mappable on host.

  It usually means CPU (system) memory. Guarantees to be HOST_VISIBLE and HOST_COHERENT. CPU access is typically uncached. Writes may be write-combined. Resources created in this pool may still be accessible to the device, but access to them can be slow. It is roughly equivalent of D3D12_HEAP_TYPE_UPLOAD.

  Usage: Staging copy of resources used as transfer source.

• MEMORY_USAGE_CPU_TO_GPU - Memory that is both mappable on host (guarantees to be HOST_VISIBLE) and preferably fast to access by GPU.

  CPU access is typically uncached. Writes may be write-combined.

  Usage: Resources written frequently by host (dynamic), read by device. E.g. textures, vertex buffers, uniform buffers updated every frame or every draw call.

• MEMORY_USAGE_GPU_TO_CPU - Memory mappable on host (guarantees to be HOST_VISIBLE) and cached.

  It is roughly equivalent of D3D12_HEAP_TYPE_READBACK.

  Usage:

  • Resources written by device, read by host - results of some computations, e.g. screen capture, average scene luminance for HDR tone mapping.
  • Any resources read or accessed randomly on host, e.g. CPU-side copy of vertex buffer used as source of transfer, but also used for collision detection.
• MEMORY_USAGE_CPU_COPY - CPU memory - memory that is preferably not DEVICE_LOCAL, but also not guaranteed to be HOST_VISIBLE.

  Usage: Staging copy of resources moved from GPU memory to CPU memory as part of custom paging/residency mechanism, to be moved back to GPU memory when needed.

• MEMORY_USAGE_GPU_LAZILY_ALLOCATED - 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.

See Also:

Constant Field Values

VMA_MEMORY_USAGE_GPU_LAZILY_ALLOCATED

public static final int VMA_MEMORY_USAGE_GPU_LAZILY_ALLOCATED

VmaMemoryUsage

Enum values:

• MEMORY_USAGE_UNKNOWN - No intended memory usage specified.

  Use other members of VmaAllocationCreateInfo to specify your requirements.

• MEMORY_USAGE_GPU_ONLY - Memory will be used on device only, so fast access from the device is preferred.

  It usually means device-local GPU (video) memory. No need to be mappable on host. It is roughly equivalent of D3D12_HEAP_TYPE_DEFAULT.

  Usage:

  • Resources written and read by device, e.g. images used as attachments.
  • Resources transferred from host once (immutable) or infrequently and read by device multiple times, e.g. textures to be sampled, vertex buffers, uniform (constant) buffers, and majority of other types of resources used on GPU.

  Allocation may still end up in HOST_VISIBLE memory on some implementations. In such case, you are free to map it. You can use ALLOCATION_CREATE_MAPPED_BIT with this usage type.

• MEMORY_USAGE_CPU_ONLY - Memory will be mappable on host.

  It usually means CPU (system) memory. Guarantees to be HOST_VISIBLE and HOST_COHERENT. CPU access is typically uncached. Writes may be write-combined. Resources created in this pool may still be accessible to the device, but access to them can be slow. It is roughly equivalent of D3D12_HEAP_TYPE_UPLOAD.

  Usage: Staging copy of resources used as transfer source.

• MEMORY_USAGE_CPU_TO_GPU - Memory that is both mappable on host (guarantees to be HOST_VISIBLE) and preferably fast to access by GPU.

  CPU access is typically uncached. Writes may be write-combined.

  Usage: Resources written frequently by host (dynamic), read by device. E.g. textures, vertex buffers, uniform buffers updated every frame or every draw call.

• MEMORY_USAGE_GPU_TO_CPU - Memory mappable on host (guarantees to be HOST_VISIBLE) and cached.

  It is roughly equivalent of D3D12_HEAP_TYPE_READBACK.

  Usage:

  • Resources written by device, read by host - results of some computations, e.g. screen capture, average scene luminance for HDR tone mapping.
  • Any resources read or accessed randomly on host, e.g. CPU-side copy of vertex buffer used as source of transfer, but also used for collision detection.
• MEMORY_USAGE_CPU_COPY - CPU memory - memory that is preferably not DEVICE_LOCAL, but also not guaranteed to be HOST_VISIBLE.

  Usage: Staging copy of resources moved from GPU memory to CPU memory as part of custom paging/residency mechanism, to be moved back to GPU memory when needed.

• MEMORY_USAGE_GPU_LAZILY_ALLOCATED - 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.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT

public static final int VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_NEVER_ALLOCATE_BIT

public static final int VMA_ALLOCATION_CREATE_NEVER_ALLOCATE_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_MAPPED_BIT

public static final int VMA_ALLOCATION_CREATE_MAPPED_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT

public static final int VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT

public static final int VMA_ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT

public static final int VMA_ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_UPPER_ADDRESS_BIT

public static final int VMA_ALLOCATION_CREATE_UPPER_ADDRESS_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_DONT_BIND_BIT

public static final int VMA_ALLOCATION_CREATE_DONT_BIND_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BIT

public static final int VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT

public static final int VMA_ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT

public static final int VMA_ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT

public static final int VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT

public static final int VMA_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT

public static final int VMA_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT

public static final int VMA_ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_ALLOCATION_CREATE_STRATEGY_MASK

public static final int VMA_ALLOCATION_CREATE_STRATEGY_MASK

Flags to be passed as VmaAllocationCreateInfo::flags. (VmaAllocationCreateFlagBits)

Enum values:

• 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.

  You should not use this flag if VmaAllocationCreateInfo::pool is not null.

• ALLOCATION_CREATE_NEVER_ALLOCATE_BIT - 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.

  If VmaAllocationCreateInfo::pool is not null, this flag is implied and ignored.

• ALLOCATION_CREATE_MAPPED_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.

  Is it 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).

  You should not use this flag together with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT.

• ALLOCATION_CREATE_CAN_BECOME_LOST_BIT - Allocation created with this flag can become lost as a result of another allocation with ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flag, so you must check it before use.

  To check if allocation is not lost, call GetAllocationInfo and check if VmaAllocationInfo::deviceMemory is not VK_NULL_HANDLE.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

  You should not use this flag together with ALLOCATION_CREATE_MAPPED_BIT.

• ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT - While creating allocation using this flag, other allocations that were created with flag ALLOCATION_CREATE_CAN_BECOME_LOST_BIT can become lost.

  For details about supporting lost allocations, see Lost Allocations chapter of User Guide on Main Page.

• ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT - 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 pUserData. The string is automatically freed together with the allocation. It is also used in BuildStatsString.
• ALLOCATION_CREATE_UPPER_ADDRESS_BIT - 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.

• ALLOCATION_CREATE_DONT_BIND_BIT - 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.

• ALLOCATION_CREATE_WITHIN_BUDGET_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.

• ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT - Allocation strategy that chooses smallest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_WORST_FIT_BIT - Allocation strategy that chooses biggest possible free range for the allocation.
• ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT - Allocation strategy that chooses first suitable free range for the allocation.

  "First" doesn't necessarily means the one with smallest offset in memory, but rather the one that is easiest and fastest to find.

• ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT - Allocation strategy that tries to minimize memory usage.
• ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT - Allocation strategy that tries to minimize allocation time.
• ALLOCATION_CREATE_STRATEGY_MIN_FRAGMENTATION_BIT - Allocation strategy that tries to minimize memory fragmentation.
• ALLOCATION_CREATE_STRATEGY_MASK - A bit mask to extract only STRATEGY bits from entire set of flags.

See Also:

Constant Field Values

VMA_POOL_CREATE_IGNORE_BUFFER_IMAGE_GRANULARITY_BIT

public static final int VMA_POOL_CREATE_IGNORE_BUFFER_IMAGE_GRANULARITY_BIT

Flags to be passed as VmaPoolCreateInfo::flags. (VmaPoolCreateFlagBits)

Enum values:

• 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 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.

• POOL_CREATE_LINEAR_ALGORITHM_BIT - 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.

  When using this flag, you must specify VmaPoolCreateInfo::maxBlockCount == 1 (or 0 for default).

• POOL_CREATE_BUDDY_ALGORITHM_BIT - Enables alternative, buddy allocation algorithm in this pool.

  It operates on a tree of blocks, each having size that is a power of two and a half of its parent's size. Comparing to default algorithm, this one provides faster allocation and deallocation and decreased external fragmentation, at the expense of more memory wasted (internal fragmentation).

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

See Also:

Constant Field Values

VMA_POOL_CREATE_LINEAR_ALGORITHM_BIT

public static final int VMA_POOL_CREATE_LINEAR_ALGORITHM_BIT

Flags to be passed as VmaPoolCreateInfo::flags. (VmaPoolCreateFlagBits)

Enum values:

• 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 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.

• POOL_CREATE_LINEAR_ALGORITHM_BIT - 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.

  When using this flag, you must specify VmaPoolCreateInfo::maxBlockCount == 1 (or 0 for default).

• POOL_CREATE_BUDDY_ALGORITHM_BIT - Enables alternative, buddy allocation algorithm in this pool.

  It operates on a tree of blocks, each having size that is a power of two and a half of its parent's size. Comparing to default algorithm, this one provides faster allocation and deallocation and decreased external fragmentation, at the expense of more memory wasted (internal fragmentation).

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

See Also:

Constant Field Values

VMA_POOL_CREATE_BUDDY_ALGORITHM_BIT

public static final int VMA_POOL_CREATE_BUDDY_ALGORITHM_BIT

Flags to be passed as VmaPoolCreateInfo::flags. (VmaPoolCreateFlagBits)

Enum values:

• 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 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.

• POOL_CREATE_LINEAR_ALGORITHM_BIT - 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.

  When using this flag, you must specify VmaPoolCreateInfo::maxBlockCount == 1 (or 0 for default).

• POOL_CREATE_BUDDY_ALGORITHM_BIT - Enables alternative, buddy allocation algorithm in this pool.

  It operates on a tree of blocks, each having size that is a power of two and a half of its parent's size. Comparing to default algorithm, this one provides faster allocation and deallocation and decreased external fragmentation, at the expense of more memory wasted (internal fragmentation).

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

See Also:

Constant Field Values

VMA_POOL_CREATE_ALGORITHM_MASK

public static final int VMA_POOL_CREATE_ALGORITHM_MASK

Flags to be passed as VmaPoolCreateInfo::flags. (VmaPoolCreateFlagBits)

Enum values:

• 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 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.

• POOL_CREATE_LINEAR_ALGORITHM_BIT - 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.

  When using this flag, you must specify VmaPoolCreateInfo::maxBlockCount == 1 (or 0 for default).

• POOL_CREATE_BUDDY_ALGORITHM_BIT - Enables alternative, buddy allocation algorithm in this pool.

  It operates on a tree of blocks, each having size that is a power of two and a half of its parent's size. Comparing to default algorithm, this one provides faster allocation and deallocation and decreased external fragmentation, at the expense of more memory wasted (internal fragmentation).

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

See Also:

Constant Field Values

Method Detail

nvmaCreateAllocator

public static int nvmaCreateAllocator(long pCreateInfo,
                                      long pAllocator)

Unsafe version of: CreateAllocator

vmaCreateAllocator

public static int vmaCreateAllocator(VmaAllocatorCreateInfo pCreateInfo,
                                     org.lwjgl.PointerBuffer pAllocator)

Creates Allocator object.

LWJGL: Use VmaVulkanFunctions::set(VkInstance, VkDevice) to populate the VmaAllocatorCreateInfo::pVulkanFunctions struct.

nvmaDestroyAllocator

public static void nvmaDestroyAllocator(long allocator)

Unsafe version of: DestroyAllocator

vmaDestroyAllocator

public static void vmaDestroyAllocator(long allocator)

Destroys allocator object.

nvmaGetPhysicalDeviceProperties

public static void nvmaGetPhysicalDeviceProperties(long allocator,
                                                   long ppPhysicalDeviceProperties)

Unsafe version of: GetPhysicalDeviceProperties

vmaGetPhysicalDeviceProperties

public static void vmaGetPhysicalDeviceProperties(long allocator,
                                                  org.lwjgl.PointerBuffer ppPhysicalDeviceProperties)

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

nvmaGetMemoryProperties

public static void nvmaGetMemoryProperties(long allocator,
                                           long ppPhysicalDeviceMemoryProperties)

Unsafe version of: GetMemoryProperties

vmaGetMemoryProperties

public static void vmaGetMemoryProperties(long allocator,
                                          org.lwjgl.PointerBuffer ppPhysicalDeviceMemoryProperties)

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

nvmaGetMemoryTypeProperties

public static void nvmaGetMemoryTypeProperties(long allocator,
                                               int memoryTypeIndex,
                                               long pFlags)

Unsafe version of: GetMemoryTypeProperties

vmaGetMemoryTypeProperties

public static void vmaGetMemoryTypeProperties(long allocator,
                                              int memoryTypeIndex,
                                              java.nio.IntBuffer pFlags)

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

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

nvmaSetCurrentFrameIndex

public static void nvmaSetCurrentFrameIndex(long allocator,
                                            int frameIndex)

Unsafe version of: SetCurrentFrameIndex

vmaSetCurrentFrameIndex

public static void vmaSetCurrentFrameIndex(long allocator,
                                           int frameIndex)

Sets index of the current frame.

This function must be used if you make allocations with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT and ALLOCATION_CREATE_CAN_MAKE_OTHER_LOST_BIT flags to inform the allocator when a new frame begins. Allocations queried using GetAllocationInfo cannot become lost in the current frame.

nvmaCalculateStats

public static void nvmaCalculateStats(long allocator,
                                      long pStats)

Unsafe version of: CalculateStats

vmaCalculateStats

public static void vmaCalculateStats(long allocator,
                                     VmaStats pStats)

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. For faster but more brief statistics suitable to be called every frame or every allocation, use GetBudget.

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

nvmaGetBudget

public static void nvmaGetBudget(long allocator,
                                 long pBudget)

Unsafe version of: GetBudget

vmaGetBudget

public static void vmaGetBudget(long allocator,
                                VmaBudget.Buffer pBudget)

Retrieves information about current memory budget for all memory heaps.

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 CalculateStats.

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

Parameters:

pBudget - must point to array with number of elements at least equal to number of memory heaps in physical device used

nvmaBuildStatsString

public static void nvmaBuildStatsString(long allocator,
                                        long ppStatsString,
                                        int detailedMap)

Unsafe version of: BuildStatsString

vmaBuildStatsString

public static void vmaBuildStatsString(long allocator,
                                       org.lwjgl.PointerBuffer ppStatsString,
                                       boolean detailedMap)

Builds and returns statistics as string in JSON format.

Parameters:

ppStatsString - must be freed using FreeStatsString function

nvmaFreeStatsString

public static void nvmaFreeStatsString(long allocator,
                                       long pStatsString)

vmaFreeStatsString

public static void vmaFreeStatsString(long allocator,
                                      java.nio.ByteBuffer pStatsString)

nvmaFindMemoryTypeIndex

public static int nvmaFindMemoryTypeIndex(long allocator,
                                          int memoryTypeBits,
                                          long pAllocationCreateInfo,
                                          long pMemoryTypeIndex)

Unsafe version of: FindMemoryTypeIndex

vmaFindMemoryTypeIndex

public static int vmaFindMemoryTypeIndex(long allocator,
                                         int memoryTypeBits,
                                         VmaAllocationCreateInfo pAllocationCreateInfo,
                                         java.nio.IntBuffer pMemoryTypeIndex)

Helps to find memoryTypeIndex, given memoryTypeBits and VmaAllocationCreateInfo.

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:

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.

nvmaFindMemoryTypeIndexForBufferInfo

public static int nvmaFindMemoryTypeIndexForBufferInfo(long allocator,
                                                       long pBufferCreateInfo,
                                                       long pAllocationCreateInfo,
                                                       long pMemoryTypeIndex)

Unsafe version of: FindMemoryTypeIndexForBufferInfo

vmaFindMemoryTypeIndexForBufferInfo

public static int vmaFindMemoryTypeIndexForBufferInfo(long allocator,
                                                      org.lwjgl.vulkan.VkBufferCreateInfo pBufferCreateInfo,
                                                      VmaAllocationCreateInfo pAllocationCreateInfo,
                                                      java.nio.IntBuffer pMemoryTypeIndex)

Helps to find memoryTypeIndex, given VkBufferCreateInfo and VmaAllocationCreateInfo.

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. It is just a convenience function, equivalent to calling:

• vkCreateBuffer
• vkGetBufferMemoryRequirements
• FindMemoryTypeIndex
• vkDestroyBuffer

nvmaFindMemoryTypeIndexForImageInfo

public static int nvmaFindMemoryTypeIndexForImageInfo(long allocator,
                                                      long pImageCreateInfo,
                                                      long pAllocationCreateInfo,
                                                      long pMemoryTypeIndex)

Unsafe version of: FindMemoryTypeIndexForImageInfo

vmaFindMemoryTypeIndexForImageInfo

public static int vmaFindMemoryTypeIndexForImageInfo(long allocator,
                                                     org.lwjgl.vulkan.VkImageCreateInfo pImageCreateInfo,
                                                     VmaAllocationCreateInfo pAllocationCreateInfo,
                                                     java.nio.IntBuffer pMemoryTypeIndex)

Helps to find memoryTypeIndex, given VkImageCreateInfo and VmaAllocationCreateInfo.

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. It is just a convenience function, equivalent to calling:

• vkCreateImage
• vkGetImageMemoryRequirements
• FindMemoryTypeIndex
• vkDestroyImage

nvmaCreatePool

public static int nvmaCreatePool(long allocator,
                                 long pCreateInfo,
                                 long pPool)

Unsafe version of: CreatePool

vmaCreatePool

public static int vmaCreatePool(long allocator,
                                VmaPoolCreateInfo pCreateInfo,
                                org.lwjgl.PointerBuffer pPool)

Allocates Vulkan device memory and creates VmaPool object.

Parameters:

allocator - Allocator object

pCreateInfo - parameters of pool to create

pPool - handle to created pool

nvmaDestroyPool

public static void nvmaDestroyPool(long allocator,
                                   long pool)

Unsafe version of: DestroyPool

vmaDestroyPool

public static void vmaDestroyPool(long allocator,
                                  long pool)

Destroys VmaPool object and frees Vulkan device memory.

nvmaGetPoolStats

public static void nvmaGetPoolStats(long allocator,
                                    long pool,
                                    long pPoolStats)

Unsafe version of: GetPoolStats

vmaGetPoolStats

public static void vmaGetPoolStats(long allocator,
                                   long pool,
                                   VmaPoolStats pPoolStats)

Retrieves statistics of existing VmaPool object.

Parameters:

allocator - Allocator object

pool - pool object

pPoolStats - statistics of specified pool

nvmaMakePoolAllocationsLost

public static void nvmaMakePoolAllocationsLost(long allocator,
                                               long pool,
                                               long pLostAllocationCount)

Unsafe version of: MakePoolAllocationsLost

vmaMakePoolAllocationsLost

public static void vmaMakePoolAllocationsLost(long allocator,
                                              long pool,
                                              @Nullable
                                              org.lwjgl.PointerBuffer pLostAllocationCount)

Marks all allocations in given pool as lost if they are not used in current frame or VmaPoolCreateInfo::frameInUseCount back from now.

Parameters:

allocator - Allocator object

pool - pool

pLostAllocationCount - number of allocations marked as lost. Optional - pass null if you don't need this information.

vmaMakePoolAllocationsLost

public static long vmaMakePoolAllocationsLost(long allocator,
                                              long pool)

Marks all allocations in given pool as lost if they are not used in current frame or VmaPoolCreateInfo::frameInUseCount back from now.

Parameters:

allocator - Allocator object

pool - pool

nvmaCheckPoolCorruption

public static int nvmaCheckPoolCorruption(long allocator,
                                          long pool)

Unsafe version of: CheckPoolCorruption

vmaCheckPoolCorruption

public static int vmaCheckPoolCorruption(long allocator,
                                         long pool)

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.

Returns:

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_VALIDATION_FAILED_EXT - 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.

nvmaGetPoolName

public static void nvmaGetPoolName(long allocator,
                                   long pool,
                                   long ppName)

Unsafe version of: GetPoolName

vmaGetPoolName

public static void vmaGetPoolName(long allocator,
                                  long pool,
                                  org.lwjgl.PointerBuffer ppName)

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.

nvmaSetPoolName

public static void nvmaSetPoolName(long allocator,
                                   long pool,
                                   long pName)

Unsafe version of: SetPoolName

vmaSetPoolName

public static void vmaSetPoolName(long allocator,
                                  long pool,
                                  @Nullable
                                  java.nio.ByteBuffer pName)

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.

vmaSetPoolName

public static void vmaSetPoolName(long allocator,
                                  long pool,
                                  @Nullable
                                  java.lang.CharSequence pName)

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.

nvmaAllocateMemory

public static int nvmaAllocateMemory(long allocator,
                                     long pVkMemoryRequirements,
                                     long pCreateInfo,
                                     long pAllocation,
                                     long pAllocationInfo)

Unsafe version of: AllocateMemory

vmaAllocateMemory

public static int vmaAllocateMemory(long allocator,
                                    org.lwjgl.vulkan.VkMemoryRequirements pVkMemoryRequirements,
                                    VmaAllocationCreateInfo pCreateInfo,
                                    org.lwjgl.PointerBuffer pAllocation,
                                    @Nullable
                                    VmaAllocationInfo pAllocationInfo)

General purpose memory allocation.

You should free the memory using FreeMemory or FreeMemoryPages.

It is recommended to use AllocateMemoryForBuffer, AllocateMemoryForImage, CreateBuffer, CreateImage instead whenever possible.

Parameters:

pAllocation - handle to allocated memory

pAllocationInfo - information about allocated memory. Optional. It can be later fetched using function GetAllocationInfo.

nvmaAllocateMemoryPages

public static int nvmaAllocateMemoryPages(long allocator,
                                          long pVkMemoryRequirements,
                                          long pCreateInfo,
                                          long allocationCount,
                                          long pAllocations,
                                          long pAllocationInfo)

Unsafe version of: AllocateMemoryPages

Parameters:

allocationCount - number of allocations to make

vmaAllocateMemoryPages

public static int vmaAllocateMemoryPages(long allocator,
                                         org.lwjgl.vulkan.VkMemoryRequirements pVkMemoryRequirements,
                                         VmaAllocationCreateInfo pCreateInfo,
                                         org.lwjgl.PointerBuffer pAllocations,
                                         @Nullable
                                         VmaAllocationInfo.Buffer pAllocationInfo)

General purpose memory allocation for multiple allocation objects at once.

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.

Parameters:

allocator - allocator object

pVkMemoryRequirements - memory requirements for each allocation

pCreateInfo - creation parameters for each alloction

pAllocations - pointer to array that will be filled with handles to created allocations

pAllocationInfo - pointer to array that will be filled with parameters of created allocations. Optional.

nvmaAllocateMemoryForBuffer

public static int nvmaAllocateMemoryForBuffer(long allocator,
                                              long buffer,
                                              long pCreateInfo,
                                              long pAllocation,
                                              long pAllocationInfo)

Unsafe version of: AllocateMemoryForBuffer

vmaAllocateMemoryForBuffer

public static int vmaAllocateMemoryForBuffer(long allocator,
                                             long buffer,
                                             VmaAllocationCreateInfo pCreateInfo,
                                             org.lwjgl.PointerBuffer pAllocation,
                                             @Nullable
                                             VmaAllocationInfo pAllocationInfo)

Buffer memory allocation.

You should free the memory using FreeMemory.

Parameters:

pAllocation - handle to allocated memory

pAllocationInfo - information about allocated memory. Optional. It can be later fetched using function GetAllocationInfo.

nvmaAllocateMemoryForImage

public static int nvmaAllocateMemoryForImage(long allocator,
                                             long image,
                                             long pCreateInfo,
                                             long pAllocation,
                                             long pAllocationInfo)

Unsafe version of: AllocateMemoryForImage

vmaAllocateMemoryForImage

public static int vmaAllocateMemoryForImage(long allocator,
                                            long image,
                                            VmaAllocationCreateInfo pCreateInfo,
                                            org.lwjgl.PointerBuffer pAllocation,
                                            @Nullable
                                            VmaAllocationInfo pAllocationInfo)

Function similar to AllocateMemoryForBuffer.

Parameters:

pAllocation - handle to allocated memory

pAllocationInfo - information about allocated memory. Optional. It can be later fetched using function GetAllocationInfo.

nvmaFreeMemory

public static void nvmaFreeMemory(long allocator,
                                  long allocation)

Unsafe version of: FreeMemory

vmaFreeMemory

public static void vmaFreeMemory(long allocator,
                                 long allocation)

Frees memory previously allocated using AllocateMemory, AllocateMemoryForBuffer, or AllocateMemoryForImage.

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

nvmaFreeMemoryPages

public static void nvmaFreeMemoryPages(long allocator,
                                       long allocationCount,
                                       long pAllocations)

Unsafe version of: FreeMemoryPages

vmaFreeMemoryPages

public static void vmaFreeMemoryPages(long allocator,
                                      org.lwjgl.PointerBuffer pAllocations)

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.

nvmaResizeAllocation

public static int nvmaResizeAllocation(long allocator,
                                       long allocation,
                                       long newSize)

Unsafe version of: ResizeAllocation

vmaResizeAllocation

public static int vmaResizeAllocation(long allocator,
                                      long allocation,
                                      long newSize)

Deprecated.

In version 2.2.0 it used to try to change allocation's size without moving or reallocating it. In current version it returns VK_SUCCESS only if newSize equals current allocation's size. Otherwise returns VK_ERROR_OUT_OF_POOL_MEMORY, indicating that allocation's size could not be changed.

Returns:

VK_SUCCESS if allocation's size has been successfully changed. Returns VK_ERROR_OUT_OF_POOL_MEMORY if allocation's size could not be changed.

nvmaGetAllocationInfo

public static void nvmaGetAllocationInfo(long allocator,
                                         long allocation,
                                         long pAllocationInfo)

Unsafe version of: GetAllocationInfo

vmaGetAllocationInfo

public static void vmaGetAllocationInfo(long allocator,
                                        long allocation,
                                        VmaAllocationInfo pAllocationInfo)

Returns current information about specified allocation and atomically marks it as used in current frame.

Current parameters of given allocation are returned in pAllocationInfo.

This function also atomically "touches" allocation - marks it as used in current frame, just like TouchAllocation. If the allocation is in lost state, pAllocationInfo->deviceMemory == VK_NULL_HANDLE.

Although this function uses atomics and doesn't lock any mutex, so it should be quite efficient, you can avoid calling it too often.

• You can retrieve same VmaAllocationInfo 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 or allocation becoming lost).
• If you just want to check if allocation is not lost, TouchAllocation will work faster.

nvmaTouchAllocation

public static int nvmaTouchAllocation(long allocator,
                                      long allocation)

Unsafe version of: TouchAllocation

vmaTouchAllocation

public static boolean vmaTouchAllocation(long allocator,
                                         long allocation)

Returns VK_TRUE if allocation is not lost and atomically marks it as used in current frame.

If the allocation has been created with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT flag, this function returns VK_TRUE if it's not in lost state, so it can still be used. It then also atomically "touches" the allocation - marks it as used in current frame, so that you can be sure it won't become lost in current frame or next frameInUseCount frames.

If the allocation is in lost state, the function returns VK_FALSE. Memory of such allocation, as well as buffer or image bound to it, should not be used. Lost allocation and the buffer/image still need to be destroyed.

If the allocation has been created without ALLOCATION_CREATE_CAN_BECOME_LOST_BIT flag, this function always returns VK_TRUE.

nvmaSetAllocationUserData

public static void nvmaSetAllocationUserData(long allocator,
                                             long allocation,
                                             long pUserData)

Unsafe version of: SetAllocationUserData

vmaSetAllocationUserData

public static void vmaSetAllocationUserData(long allocator,
                                            long allocation,
                                            long pUserData)

Sets pUserData in given allocation to new value.

If the allocation was created with ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT, pUserData 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 pUserData. String passed as pUserData 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 pUserData is freed from memory.

If the flag was not used, the value of pointer pUserData is just 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.

nvmaCreateLostAllocation

public static void nvmaCreateLostAllocation(long allocator,
                                            long pAllocation)

Unsafe version of: CreateLostAllocation

vmaCreateLostAllocation

public static void vmaCreateLostAllocation(long allocator,
                                           org.lwjgl.PointerBuffer 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 FreeMemory.

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.

nvmaMapMemory

public static int nvmaMapMemory(long allocator,
                                long allocation,
                                long ppData)

Unsafe version of: MapMemory

vmaMapMemory

public static int vmaMapMemory(long allocator,
                               long allocation,
                               org.lwjgl.PointerBuffer ppData)

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. If the allocation is part of bigger VkDeviceMemory block, the pointer is correctly offseted to the beginning of region assigned to this particular allocation.

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 vmaUnmapMemory() same number of times as you called vmaMapMemory().

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 vmaUnmapMemory() same number of times as you called vmaMapMemory(). You must not call vmaUnmapMemory() 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 always fails when called for allocation that was created with ALLOCATION_CREATE_CAN_BECOME_LOST_BIT flag. Such allocations cannot be mapped.

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.

nvmaUnmapMemory

public static void nvmaUnmapMemory(long allocator,
                                   long allocation)

Unsafe version of: UnmapMemory

vmaUnmapMemory

public static void vmaUnmapMemory(long allocator,
                                  long allocation)

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

For details, see description of vmaMapMemory().

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.

nvmaFlushAllocation

public static void nvmaFlushAllocation(long allocator,
                                       long allocation,
                                       long offset,
                                       long size)

Unsafe version of: FlushAllocation

vmaFlushAllocation

public static void vmaFlushAllocation(long allocator,
                                      long allocation,
                                      long offset,
                                      long size)

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!!!

nvmaInvalidateAllocation

public static void nvmaInvalidateAllocation(long allocator,
                                            long allocation,
                                            long offset,
                                            long size)

Unsafe version of: InvalidateAllocation

vmaInvalidateAllocation

public static void vmaInvalidateAllocation(long allocator,
                                           long allocation,
                                           long offset,
                                           long size)

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!!!

nvmaCheckCorruption

public static int nvmaCheckCorruption(long allocator,
                                      int memoryTypeBits)

Unsafe version of: CheckCorruption

vmaCheckCorruption

public static int vmaCheckCorruption(long allocator,
                                     int memoryTypeBits)

Checks magic number in margins around all allocations in given memory types (in both default and custom pools) 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 only for memory types that are HOST_VISIBLE and HOST_COHERENT.

Parameters:

memoryTypeBits - bit mask, where each bit set means that a memory type with that index should be checked

Returns:

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_VALIDATION_FAILED_EXT - 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.

nvmaDefragmentationBegin

public static int nvmaDefragmentationBegin(long allocator,
                                           long pInfo,
                                           long pStats,
                                           long pContext)

Unsafe version of: DefragmentationBegin

vmaDefragmentationBegin

public static int vmaDefragmentationBegin(long allocator,
                                          VmaDefragmentationInfo2 pInfo,
                                          @Nullable
                                          VmaDefragmentationStats pStats,
                                          org.lwjgl.PointerBuffer pContext)

Begins defragmentation process.

Use this function instead of old, deprecated Defragment.

Warning! Between the call to vmaDefragmentationBegin and DefragmentationEnd:

• You should not use any of allocations passed as pInfo->pAllocations or any allocations that belong to pools passed as pInfo->pPools, including calling GetAllocationInfo, TouchAllocation, or access their data.
• Some mutexes protecting internal data structures may be locked, so trying to make or free any allocations, bind buffers or images, map memory, or launch another simultaneous defragmentation in between may cause stall (when done on another thread) or deadlock (when done on the same thread), unless you are 100% sure that defragmented allocations are in different pools.
• Information returned via pStats and pInfo->pAllocationsChanged are undefined. They become valid after call to DefragmentationEnd.
• If pInfo->commandBuffer is not null, you must submit that command buffer and make sure it finished execution before calling DefragmentationEnd.

Parameters:

allocator - allocator object

pInfo - structure filled with parameters of defragmentation

pStats - Optional. Statistics of defragmentation. You can pass null if you are not interested in this information.

pContext - context object that must be passed to DefragmentationEnd to finish defragmentation

Returns:

VK_SUCCESS and *pContext == null if defragmentation finished within this function call. VK_NOT_READY and *pContext != null if defragmentation has been started and you need to call DefragmentationEnd to finish it. Negative value in case of error.

nvmaDefragmentationEnd

public static int nvmaDefragmentationEnd(long allocator,
                                         long context)

Unsafe version of: DefragmentationEnd

vmaDefragmentationEnd

public static int vmaDefragmentationEnd(long allocator,
                                        long context)

Ends defragmentation process.

Use this function to finish defragmentation started by DefragmentationBegin. It is safe to pass context == null. The function then does nothing.

Parameters:

allocator - allocator object

nvmaDefragment

public static int nvmaDefragment(long allocator,
                                 long pAllocations,
                                 long allocationCount,
                                 long pAllocationsChanged,
                                 long pDefragmentationInfo,
                                 long pDefragmentationStats)

Unsafe version of: Defragment

Parameters:

allocationCount - number of elements in pAllocations and pAllocationsChanged arrays

vmaDefragment

public static int vmaDefragment(long allocator,
                                org.lwjgl.PointerBuffer pAllocations,
                                @Nullable
                                java.nio.IntBuffer pAllocationsChanged,
                                @Nullable
                                VmaDefragmentationInfo pDefragmentationInfo,
                                @Nullable
                                VmaDefragmentationStats pDefragmentationStats)

Deprecated: This is a part of the old interface. It is recommended to use structure VmaDefragmentationInfo2 and function DefragmentationBegin instead.

Compacts memory by moving allocations.

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:

• Only allocations made in memory types that have VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT and VK_MEMORY_PROPERTY_HOST_COHERENT_BIT flags can be compacted. You may pass other allocations but it makes no sense - these will never be moved.
• Custom pools created with POOL_CREATE_LINEAR_ALGORITHM_BIT or POOL_CREATE_BUDDY_ALGORITHM_BIT flag are not defragmented. Allocations passed to this function that come from such pools are ignored.
• Allocations created with ALLOCATION_CREATE_DEDICATED_MEMORY_BIT or created as dedicated allocations for any other reason are also ignored.
• Both allocations made with or without ALLOCATION_CREATE_MAPPED_BIT flag can be compacted. If not persistently mapped, memory will be mapped temporarily inside this function if needed.
• You must not pass same VmaAllocation object multiple times in pAllocations array.

The function also frees empty VkDeviceMemory blocks.

Warning: This function may be time-consuming, so you shouldn't call it too often (like after every resource creation/destruction). You can call it on special occasions (like when reloading a game level or when you just destroyed a lot of objects). Calling it every frame may be OK, but you should measure that on your platform.

Parameters:

pAllocations - array of allocations that can be moved during this compaction

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.

pDefragmentationStats - statistics returned by the function. Optional - pass null if you don't need this information.

Returns:

VK_SUCCESS if completed, negative error code in case of error.

nvmaBindBufferMemory

public static int nvmaBindBufferMemory(long allocator,
                                       long allocation,
                                       long buffer)

Unsafe version of: BindBufferMemory

vmaBindBufferMemory

public static int vmaBindBufferMemory(long allocator,
                                      long allocation,
                                      long buffer)

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.

nvmaBindBufferMemory2

public static int nvmaBindBufferMemory2(long allocator,
                                        long allocation,
                                        long allocationLocalOffset,
                                        long buffer,
                                        long pNext)

Unsafe version of: BindBufferMemory2

vmaBindBufferMemory2

public static int vmaBindBufferMemory2(long allocator,
                                       long allocation,
                                       long allocationLocalOffset,
                                       long buffer,
                                       long pNext)

Binds buffer to allocation with additional parameters.

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

If pNext is not null, VmaAllocator 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.

Parameters:

allocationLocalOffset - additional offset to be added while binding, relative to the beginning of the allocation. Normally it should be 0.

pNext - a chain of structures to be attached to VkBindBufferMemoryInfoKHR structure used internally. Normally it should be null.

nvmaBindImageMemory

public static int nvmaBindImageMemory(long allocator,
                                      long allocation,
                                      long image)

Unsafe version of: BindImageMemory

vmaBindImageMemory

public static int vmaBindImageMemory(long allocator,
                                     long allocation,
                                     long image)

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 vmaCreateImage() instead of this one.

nvmaBindImageMemory2

public static int nvmaBindImageMemory2(long allocator,
                                       long allocation,
                                       long allocationLocalOffset,
                                       long image,
                                       long pNext)

Unsafe version of: BindImageMemory2

vmaBindImageMemory2

public static int vmaBindImageMemory2(long allocator,
                                      long allocation,
                                      long allocationLocalOffset,
                                      long image,
                                      long pNext)

Binds image to allocation with additional parameters.

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

If pNext is not null, VmaAllocator 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.

Parameters:

allocationLocalOffset - additional offset to be added while binding, relative to the beginning of the allocation. Normally it should be 0.

pNext - a chain of structures to be attached to VkBindImageMemoryInfoKHR structure used internally. Normally it should be null.

nvmaCreateBuffer

public static int nvmaCreateBuffer(long allocator,
                                   long pBufferCreateInfo,
                                   long pAllocationCreateInfo,
                                   long pBuffer,
                                   long pAllocation,
                                   long pAllocationInfo)

Unsafe version of: CreateBuffer

vmaCreateBuffer

public static int vmaCreateBuffer(long allocator,
                                  org.lwjgl.vulkan.VkBufferCreateInfo pBufferCreateInfo,
                                  VmaAllocationCreateInfo pAllocationCreateInfo,
                                  java.nio.LongBuffer pBuffer,
                                  org.lwjgl.PointerBuffer pAllocation,
                                  @Nullable
                                  VmaAllocationInfo pAllocationInfo)

This function automatically:

• Creates buffer.
• Allocates appropriate memory for it.
• 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 VmaAllocationCreateInfo::pool is null and ALLOCATION_CREATE_NEVER_ALLOCATE_BIT is not used), it creates dedicated allocation for this buffer, just like when using ALLOCATION_CREATE_DEDICATED_MEMORY_BIT.

Parameters:

pBuffer - buffer that was created

pAllocation - allocation that was created

pAllocationInfo - information about allocated memory. Optional. It can be later fetched using function GetAllocationInfo.

nvmaDestroyBuffer

public static void nvmaDestroyBuffer(long allocator,
                                     long buffer,
                                     long allocation)

Unsafe version of: DestroyBuffer

vmaDestroyBuffer

public static void vmaDestroyBuffer(long allocator,
                                    long buffer,
                                    long allocation)

Destroys Vulkan buffer and frees allocated memory.

This is just a convenience function equivalent to:

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

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

nvmaCreateImage

public static int nvmaCreateImage(long allocator,
                                  long pImageCreateInfo,
                                  long pAllocationCreateInfo,
                                  long pImage,
                                  long pAllocation,
                                  long pAllocationInfo)

Unsafe version of: CreateImage

vmaCreateImage

public static int vmaCreateImage(long allocator,
                                 org.lwjgl.vulkan.VkImageCreateInfo pImageCreateInfo,
                                 VmaAllocationCreateInfo pAllocationCreateInfo,
                                 java.nio.LongBuffer pImage,
                                 org.lwjgl.PointerBuffer pAllocation,
                                 @Nullable
                                 VmaAllocationInfo pAllocationInfo)

Function similar to CreateBuffer.

Parameters:

pImage - image that was created

pAllocation - allocation that was created

pAllocationInfo - information about allocated memory. Optional. It can be later fetched using function GetAllocationInfo.

nvmaDestroyImage

public static void nvmaDestroyImage(long allocator,
                                    long image,
                                    long allocation)

Unsafe version of: DestroyImage

vmaDestroyImage

public static void vmaDestroyImage(long allocator,
                                   long image,
                                   long allocation)

Destroys Vulkan image and frees allocated memory.

This is just a convenience function equivalent to:

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

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