Class Vma
Quick start
Initialization
At program startup:
- Initialize Vulkan to have
VkPhysicalDevice
,VkDevice
andVkInstance
object. - Fill
VmaAllocatorCreateInfo
structure and createVmaAllocator
object by callingCreateAllocator
.
VmaVulkanFunctions vulkanFunctions = {};
vulkanFunctions.vkGetInstanceProcAddr = &vkGetInstanceProcAddr;
vulkanFunctions.vkGetDeviceProcAddr = &vkGetDeviceProcAddr;
VmaAllocatorCreateInfo allocatorCreateInfo = {};
allocatorCreateInfo.vulkanApiVersion = VK_API_VERSION_1_2;
allocatorCreateInfo.physicalDevice = physicalDevice;
allocatorCreateInfo.device = device;
allocatorCreateInfo.instance = instance;
allocatorCreateInfo.pVulkanFunctions = &vulkanFunctions;
VmaAllocator allocator;
vmaCreateAllocator(&allocatorCreateInfo, &allocator);
Only members physicalDevice
, device
, instance
are required. However, you should inform the library which Vulkan version do you
use by setting VmaAllocatorCreateInfo::vulkanApiVersion
and which extensions did you enable by setting VmaAllocatorCreateInfo::flags
(like ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
for VK_KHR_buffer_device_address
). Otherwise, VMA would use only features of Vulkan 1.0 core
with no extensions.
Resource allocation
When you want to create a buffer or image:
- Fill
VkBufferCreateInfo
/VkImageCreateInfo
structure. - Fill
VmaAllocationCreateInfo
structure. - Call
CreateBuffer
/CreateImage
to getVkBuffer
/VkImage
with memory already allocated and bound to it, plusVmaAllocation
objects that represents its underlying memory.
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_AUTO;
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.
- If you just want to find memory type index that meets your requirements, you can use function:
FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
,FindMemoryTypeIndex
. - 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. - 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
. - This is the easiest and recommended way to use this library: 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
.
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. Since version 3 of the library, it is recommended to use MEMORY_USAGE_AUTO
to let
it select best memory type for your resource automatically.
For example, if you want to create a uniform buffer that will be filled using transfer only once or infrequently and then used for rendering every
frame as a uniform buffer, you can do it using following code. The buffer will most likely end up in a memory type with
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
to be fast to access by the GPU device.
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_AUTO;
VkBuffer buffer;
VmaAllocation allocation;
vmaCreateBuffer(allocator, &bufferInfo, &allocInfo, &buffer, &allocation, nullptr);
If you have a preference for putting the resource in GPU (device) memory or CPU (host) memory on systems with discrete graphics card that have the
memories separate, you can use MEMORY_USAGE_AUTO_PREFER_DEVICE
or MEMORY_USAGE_AUTO_PREFER_HOST
.
When using VMA_MEMORY_USAGE_AUTO*
while you want to map the allocated memory, you also need to specify one of the host access flags:
ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
or ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
. This will help the library decide about preferred
memory type to ensure it has VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
so you can map it.
For example, a staging buffer that will be filled via mapped pointer and then used as a source of transfer to the buffer described previously can be
created like this. It will likely end up in a memory type that is HOST_VISIBLE
and HOST_COHERENT
but not HOST_CACHED
(meaning
uncached, write-combined) and not DEVICE_LOCAL
(meaning system RAM).
VkBufferCreateInfo stagingBufferInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
stagingBufferInfo.size = 65536;
stagingBufferInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT;
VmaAllocationCreateInfo stagingAllocInfo = {};
stagingAllocInfo.usage = VMA_MEMORY_USAGE_AUTO;
stagingAllocInfo.flags = VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT;
VkBuffer stagingBuffer;
VmaAllocation stagingAllocation;
vmaCreateBuffer(allocator, &stagingBufferInfo, &stagingAllocInfo, &stagingBuffer, &stagingAllocation, nullptr);
Usage values VMA_MEMORY_USAGE_AUTO*
are legal to use only when the library knows about the resource being created by having
VkBufferCreateInfo
/ VkImageCreateInfo
passed, so they work with functions like: CreateBuffer
, CreateImage
,
FindMemoryTypeIndexForBufferInfo
etc. If you allocate raw memory using function AllocateMemory
, you have to use other means of selecting memory
type, as described below.
Note
Old usage values (MEMORY_USAGE_GPU_ONLY
, MEMORY_USAGE_CPU_ONLY
, MEMORY_USAGE_CPU_TO_GPU
, MEMORY_USAGE_GPU_TO_CPU
, MEMORY_USAGE_CPU_COPY
) are still
available and work same way as in previous versions of the library for backward compatibility, but they are not recommended.
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_HOST_ACCESS_RANDOM_BIT | 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.
Value passed in VmaAllocationCreateInfo
::usage
is internally converted to a set of required and preferred flags, plus some extra "magic"
(heuristics).
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 is 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:
Note
If you want to be able to map an allocation, you need to specify one of the flags ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
or
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
in VmaAllocationCreateInfo
::flags
. These flags are required for an allocation to be mappable when
using MEMORY_USAGE_AUTO
or other VMA_MEMORY_USAGE_AUTO*
enum values. For other usage values they are ignored and every such allocation made in
HOST_VISIBLE
memory type is mappable, but they can still be used for consistency.
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 is 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
Keeping 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_AUTO;
allocCreateInfo.flags = VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT |
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));
Note
ALLOCATION_CREATE_MAPPED_BIT
by itself doesn't guarantee that the allocation will end up in a mappable memory type. For this, you need to also specify
ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
or ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
. ALLOCATION_CREATE_MAPPED_BIT
only guarantees that if
the memory is HOST_VISIBLE
, the allocation will be mapped on creation.
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
, or multiple objects at once: FlushAllocations
, InvalidateAllocations
.
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 PC 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:
call GetAllocationMemoryProperties
and look for VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
flag.
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;
vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, nullptr);
VkMemoryPropertyFlags memFlags;
vmaGetAllocationMemoryProperties(allocator, alloc, &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_VISIBL
E, 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.pMappedData != nullptr)
{
// Allocation ended up in mappable memory.
// It is 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 is 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 GetHeapBudgets
. Returned structure VmaBudget
contains quantities expressed in
bytes, per Vulkan memory heap.
Please note that this function returns different information and works faster than CalculateStatistics
. vmaGetHeapBudgets()
can be called
every frame or even before every allocation, while vmaCalculateStatistics()
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:
- Make sure extensions
VK_EXT_memory_budget
andVK_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! - Use flag
ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
when creatingVmaAllocator
object. - 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. VMA then tries to make the allocation from the
next eligible Vulkan memory type. The all of them fail, the call then 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).
On AMD graphics cards there is a custom vendor extension available: VK_AMD_memory_overallocation_behavior
that allows to control the behavior
of the Vulkan implementation in out-of-memory cases - whether it should fail with an error code or still allow the allocation. Usage of this extension
involves only passing extra structure on Vulkan device creation, so it is out of scope of this library.
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.
Note: Creating custom memory pools with VmaPoolCreateInfo
::minBlockCount
set to more than 0 will currently try to allocate memory blocks
without checking whether they fit within budget.
Resource aliasing (overlap)
New explicit graphics APIs (Vulkan and Direct3D 12), thanks to manual memory management, give an opportunity to alias (overlap) multiple resources in the same region of memory - a feature not available in the old APIs (Direct3D 11, OpenGL). It can be useful to save video memory, but it must be used with caution.
For example, if you know the flow of your whole render frame in advance, you are going to use some intermediate textures or buffers only during a small range of render passes, and you know these ranges don't overlap in time, you can bind these resources to the same place in memory, even if they have completely different parameters (width, height, format etc.).
Such scenario is possible using VMA, but you need to create your images manually. Then you need to calculate parameters of an allocation to be made using formula:
- allocation size = max(size of each image)
- allocation alignment = max(alignment of each image)
- allocation memoryTypeBits = bitwise AND(memoryTypeBits of each image)
Following example shows two different images bound to the same place in memory, allocated to fit largest of them.
// A 512x512 texture to be sampled.
VkImageCreateInfo img1CreateInfo = { VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO };
img1CreateInfo.imageType = VK_IMAGE_TYPE_2D;
img1CreateInfo.extent.width = 512;
img1CreateInfo.extent.height = 512;
img1CreateInfo.extent.depth = 1;
img1CreateInfo.mipLevels = 10;
img1CreateInfo.arrayLayers = 1;
img1CreateInfo.format = VK_FORMAT_R8G8B8A8_SRGB;
img1CreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
img1CreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
img1CreateInfo.usage = VK_IMAGE_USAGE_TRANSFER_DST_BIT | VK_IMAGE_USAGE_SAMPLED_BIT;
img1CreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
// A full screen texture to be used as color attachment.
VkImageCreateInfo img2CreateInfo = { VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO };
img2CreateInfo.imageType = VK_IMAGE_TYPE_2D;
img2CreateInfo.extent.width = 1920;
img2CreateInfo.extent.height = 1080;
img2CreateInfo.extent.depth = 1;
img2CreateInfo.mipLevels = 1;
img2CreateInfo.arrayLayers = 1;
img2CreateInfo.format = VK_FORMAT_R8G8B8A8_UNORM;
img2CreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
img2CreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
img2CreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
img2CreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
VkImage img1;
res = vkCreateImage(device, &img1CreateInfo, nullptr, &img1);
VkImage img2;
res = vkCreateImage(device, &img2CreateInfo, nullptr, &img2);
VkMemoryRequirements img1MemReq;
vkGetImageMemoryRequirements(device, img1, &img1MemReq);
VkMemoryRequirements img2MemReq;
vkGetImageMemoryRequirements(device, img2, &img2MemReq);
VkMemoryRequirements finalMemReq = {};
finalMemReq.size = std::max(img1MemReq.size, img2MemReq.size);
finalMemReq.alignment = std::max(img1MemReq.alignment, img2MemReq.alignment);
finalMemReq.memoryTypeBits = img1MemReq.memoryTypeBits & img2MemReq.memoryTypeBits;
// Validate if(finalMemReq.memoryTypeBits != 0)
VmaAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.preferredFlags = VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT;
VmaAllocation alloc;
res = vmaAllocateMemory(allocator, &finalMemReq, &allocCreateInfo, &alloc, nullptr);
res = vmaBindImageMemory(allocator, alloc, img1);
res = vmaBindImageMemory(allocator, alloc, img2);
// You can use img1, img2 here, but not at the same time!
vmaFreeMemory(allocator, alloc);
vkDestroyImage(allocator, img2, nullptr);
vkDestroyImage(allocator, img1, nullptr);
VMA also provides convenience functions that create a buffer or image and bind it to memory represented by an existing VmaAllocation
:
CreateAliasingBuffer
, CreateAliasingBuffer2
, CreateAliasingImage
, CreateAliasingImage2
. Versions with "2" offer additional parameter
allocationLocalOffset
.
Remember that using resources that alias in memory requires proper synchronization. You need to issue a memory barrier to make sure commands that use
img1
and img2
don't overlap on GPU timeline. You also need to treat a resource after aliasing as uninitialized - containing garbage
data. For example, if you use img1
and then want to use img2
, you need to issue an image memory barrier for img2
with
oldLayout = VK_IMAGE_LAYOUT_UNDEFINED
.
Additional considerations:
- Vulkan also allows to interpret contents of memory between aliasing resources consistently in some cases. See chapter 11.8. "Memory Aliasing" of
Vulkan specification or
VK_IMAGE_CREATE_ALIAS_BIT
flag. - You can create more complex layout where different images and buffers are bound at different offsets inside one large allocation. For example, one
can imagine a big texture used in some render passes, aliasing with a set of many small buffers used between in some further passes. To bind a
resource at non-zero offset in an allocation, use
BindBufferMemory2
/BindImageMemory2
. - Before allocating memory for the resources you want to alias, check
memoryTypeBits
returned in memory requirements of each resource to make sure the bits overlap. Some GPUs may expose multiple memory types suitable e.g. only for buffers or images withCOLOR_ATTACHMENT
usage, so the sets of memory types supported by your resources may be disjoint. Aliasing them is not possible in that case.
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.
- Use extra parameters for a set of your allocations that are available in
VmaPoolCreateInfo
but not inVmaAllocationCreateInfo
- e.g., custom minimum alignment, custompNext
chain. - Perform defragmentation on a specific subset of your allocations.
To use custom memory pools:
- Fill
VmaPoolCreateInfo
structure. - Call
CreatePool
to obtainVmaPool
handle. - When making an allocation, set
VmaAllocationCreateInfo
::pool
to this handle. You don't need to specify any other parameters of this structure, likeusage
.
Example:
// Find memoryTypeIndex for the pool.
VkBufferCreateInfo sampleBufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
sampleBufCreateInfo.size = 0x10000; // Doesn't matter.
sampleBufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;
VmaAllocationCreateInfo sampleAllocCreateInfo = {};
sampleAllocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
uint32_t memTypeIndex;
VkResult res = vmaFindMemoryTypeIndexForBufferInfo(allocator,
&sampleBufCreateInfo, &sampleAllocCreateInfo, &memTypeIndex);
// Check res...
// Create a pool that can have at most 2 blocks, 128 MiB each.
VmaPoolCreateInfo poolCreateInfo = {};
poolCreateInfo.memoryTypeIndex = memTypeIndex
poolCreateInfo.blockSize = 128ull * 1024 * 1024;
poolCreateInfo.maxBlockCount = 2;
VmaPool pool;
res = vmaCreatePool(allocator, &poolCreateInfo, &pool);
// Check res...
// 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;
res = vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, nullptr);
// Check res...
You have to free all allocations made from this pool before destroying it.
vmaDestroyBuffer(allocator, buf, alloc);
vmaDestroyPool(allocator, pool);
New versions of this library support creating dedicated allocations in custom pools. It is supported only when VmaPoolCreateInfo::blockSize = 0
.
To use this feature, set VmaAllocationCreateInfo::pool
to the pointer to your custom pool and VmaAllocationCreateInfo::flags
to
ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
.
Note
Excessive use of custom pools is a common mistake when using this library. Custom 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 or limit maximum amount of memory they can occupy. 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.
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; // Doesn't matter
exampleBufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;
VmaAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
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 differentVK_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 onlypool
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.
Ring buffer is available only in pools with one memory block - VmaPoolCreateInfo
::maxBlockCount
must be 1. Otherwise behavior is undefined.
Note: defragmentation is not supported in custom pools created with POOL_CREATE_LINEAR_ALGORITHM_BIT
.
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. It doesn't happen automatically though and needs your cooperation, because VMA is a low
level library that only allocates memory. It cannot recreate buffers and images in a new place as it doesn't remember the contents of
VkBufferCreateInfo
/ VkImageCreateInfo
structures. It cannot copy their contents as it doesn't record any commands to a command buffer.
Example:
VmaDefragmentationInfo defragInfo = {};
defragInfo.pool = myPool;
defragInfo.flags = VMA_DEFRAGMENTATION_FLAG_ALGORITHM_FAST_BIT;
VmaDefragmentationContext defragCtx;
VkResult res = vmaBeginDefragmentation(allocator, &defragInfo, &defragCtx);
// Check res...
for(;;)
{
VmaDefragmentationPassMoveInfo pass;
res = vmaBeginDefragmentationPass(allocator, defragCtx, &pass);
if(res == VK_SUCCESS)
break;
else if(res != VK_INCOMPLETE)
// Handle error...
for(uint32_t i = 0; i < pass.moveCount; ++i)
{
// Inspect pass.pMoves[i].srcAllocation, identify what buffer/image it represents.
VmaAllocationInfo allocInfo;
vmaGetAllocationInfo(allocator, pass.pMoves[i].srcAllocation, &allocInfo);
MyEngineResourceData* resData = (MyEngineResourceData*)allocInfo.pUserData;
// Recreate and bind this buffer/image at: pass.pMoves[i].dstMemory, pass.pMoves[i].dstOffset.
VkImageCreateInfo imgCreateInfo = ...
VkImage newImg;
res = vkCreateImage(device, &imgCreateInfo, nullptr, &newImg);
// Check res...
res = vmaBindImageMemory(allocator, pass.pMoves[i].dstTmpAllocation, newImg);
// Check res...
// Issue a vkCmdCopyBuffer/vkCmdCopyImage to copy its content to the new place.
vkCmdCopyImage(cmdBuf, resData->img, ..., newImg, ...);
}
// Make sure the copy commands finished executing.
vkWaitForFences(...);
// Destroy old buffers/images bound with pass.pMoves[i].srcAllocation.
for(uint32_t i = 0; i < pass.moveCount; ++i)
{
// ...
vkDestroyImage(device, resData->img, nullptr);
}
// Update appropriate descriptors to point to the new places...
res = vmaEndDefragmentationPass(allocator, defragCtx, &pass);
if(res == VK_SUCCESS)
break;
else if(res != VK_INCOMPLETE)
// Handle error...
}
vmaEndDefragmentation(allocator, defragCtx, nullptr);
Although functions like CreateBuffer
, CreateImage
, DestroyBuffer
, DestroyImage
create/destroy an allocation and a buffer/image at once,
these are just a shortcut for creating the resource, allocating memory, and binding them together. Defragmentation works on memory allocations only.
You must handle the rest manually. Defragmentation is an iterative process that should repreat "passes" as long as related functions return
VK_INCOMPLETE
not VK_SUCCESS
. In each pass:
BeginDefragmentationPass
function call:- Calculates and returns the list of allocations to be moved in this pass. Note this can be a time-consuming process.
- Reserves destination memory for them by creating temporary destination allocations that you can query for their
VkDeviceMemory
+offset
usingGetAllocationInfo
.
- Inside the pass, you should:
- Inspect the returned list of allocations to be moved.
- Create new buffers/images and bind them at the returned destination temporary allocations.
- Copy data from source to destination resources if necessary.
- Destroy the source buffers/images, but NOT their allocations.
EndDefragmentationPass
function call:- Frees the source memory reserved for the allocations that are moved.
- Modifies source
VmaAllocation
objects that are moved to point to the destination reserved memory. - Frees
VkDeviceMemory
blocks that became empty.
Unlike in previous iterations of the defragmentation API, there is no list of "movable" allocations passed as a parameter. Defragmentation algorithm
tries to move all suitable allocations. You can, however, refuse to move some of them inside a defragmentation pass, by setting
pass.pMoves[i].operation
to DEFRAGMENTATION_MOVE_OPERATION_IGNORE
. This is not recommended and may result in suboptimal packing of the
allocations after defragmentation. If you cannot ensure any allocation can be moved, it is better to keep movable allocations separate in a custom
pool.
Inside a pass, for each allocation that should be moved:
- You should copy its data from the source to the destination place by calling e.g.
vkCmdCopyBuffer()
,vkCmdCopyImage()
.You need to make sure these commands finished executing before destroying the source buffers/images and before calling
EndDefragmentationPass
. - If a resource doesn't contain any meaningful data, e.g. it is a transient color attachment image to be cleared, filled, and used temporarily in each rendering frame, you can just recreate this image without copying its data.
- If the resource is in
HOST_VISIBLE
andHOST_CACHED
memory, you can copy its data on the CPU usingmemcpy()
. - If you cannot move the allocation, you can set
pass.pMoves[i].operation
toDEFRAGMENTATION_MOVE_OPERATION_IGNORE
. This will cancel the move.EndDefragmentationPass
will then free the destination memory not the source memory of the allocation, leaving it unchanged. - If you decide the allocation is unimportant and can be destroyed instead of moved (e.g. it wasn't used for long time), you can set
pass.pMoves[i].operation
toDEFRAGMENTATION_MOVE_OPERATION_DESTROY
.EndDefragmentationPass
will then free both source and destination memory, and will destroy the sourceVmaAllocation
object.
You can defragment a specific custom pool by setting VmaDefragmentationInfo
::pool
(like in the example above) or all the default pools by
setting this member to null.
Defragmentation is always performed in each pool separately. Allocations are never moved between different Vulkan memory types. The size of the
destination memory reserved for a moved allocation is the same as the original one. Alignment of an allocation as it was determined using
vkGetBufferMemoryRequirements()
etc. is also respected after defragmentation. Buffers/images should be recreated with the same
VkBufferCreateInfo
/ VkImageCreateInfo
parameters as the original ones.
You can perform the defragmentation incrementally to limit the number of allocations and bytes to be moved in each pass, e.g. to call it in sync with
render frames and not to experience too big hitches. See members: VmaDefragmentationInfo
::maxBytesPerPass
,
VmaDefragmentationInfo
::maxAllocationsPerPass
.
It is also safe to perform the defragmentation asynchronously to render frames and other Vulkan and VMA usage, possibly from multiple threads, with the
exception that allocations returned in VmaDefragmentationPassMoveInfo
::pMoves
shouldn't be destroyed until the defragmentation pass is ended.
Mapping is preserved on allocations that are moved during defragmentation. Whether through ALLOCATION_CREATE_MAPPED_BIT
or MapMemory
, the
allocations are mapped at their new place. Of course, pointer to the mapped data changes, so it needs to be queried using
VmaAllocationInfo
::pMappedData
.
Note: Defragmentation is not supported in custom pools created with POOL_CREATE_LINEAR_ALGORITHM_BIT
.
Statistics
This library contains several functions that return information about its internal state, especially the amount of memory allocated from Vulkan.
Numeric statistics
If you need to obtain basic statistics about memory usage per heap, together with current budget, you can call function GetHeapBudgets
and inspect
structure VmaBudget
. This is useful to keep track of memory usage and stay within budget. Example:
uint32_t heapIndex = ...
VmaBudget budgets[VK_MAX_MEMORY_HEAPS];
vmaGetHeapBudgets(allocator, budgets);
printf("My heap currently has %u allocations taking %llu B,\n",
budgets[heapIndex].statistics.allocationCount,
budgets[heapIndex].statistics.allocationBytes);
printf("allocated out of %u Vulkan device memory blocks taking %llu B,\n",
budgets[heapIndex].statistics.blockCount,
budgets[heapIndex].statistics.blockBytes);
printf("Vulkan reports total usage %llu B with budget %llu B.\n",
budgets[heapIndex].usage,
budgets[heapIndex].budget);
You can query for more detailed statistics per memory heap, type, and totals, including minimum and maximum allocation size and unused range size, by
calling function CalculateStatistics
and inspecting structure VmaTotalStatistics
. This function is slower though, as it has to traverse all the
internal data structures, so it should be used only for debugging purposes.
You can query for statistics of a custom pool using function GetPoolStatistics
or CalculatePoolStatistics
.
You can query for information about a specific allocation using function GetAllocationInfo
. It fills 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 CalculateStatistics
. 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 is 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. It is useful to identify appropriate data structures in your engine
given VmaAllocation
, e.g. when doing defragmentation.
VkBufferCreateInfo bufCreateInfo = ...
MyBufferMetadata* pMetadata = CreateBufferMetadata();
VmaAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
allocCreateInfo.pUserData = pMetadata;
VkBuffer buffer;
VmaAllocation allocation;
vmaCreateBuffer(allocator, &bufCreateInfo, &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
An allocation can also carry a null-terminated string, giving a name to the allocation. To set it, call SetAllocationName
. 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.
std::string imageName = "Texture: ";
imageName += fileName;
vmaSetAllocationName(allocator, allocation, imageName.c_str());
The string can be later retrieved by inspecting VmaAllocationInfo
::pName
. It is also printed in JSON report created by BuildStatsString
.
Note: Setting string name to VMA allocation doesn't automatically set it to the Vulkan buffer or image created with it. You must do it manually using
an extension like VK_EXT_debug_utils
, which is independent of this library.
Virtual allocator
As an extra feature, the core allocation algorithm of the library is exposed through a simple and convenient API of "virtual allocator". It doesn't allocate any real GPU memory. It just keeps track of used and free regions of a "virtual block". You can use it to allocate your own memory or other objects, even completely unrelated to Vulkan. A common use case is sub-allocation of pieces of one large GPU buffer.
Creating virtual block
To use this functionality, there is no main "allocator" object. You don't need to have VmaAllocator
object created. All you need to do is to
create a separate VmaVirtualBlock
object for each block of memory you want to be managed by the allocator:
- Fill in
VmaVirtualBlockCreateInfo
structure. - Call
CreateVirtualBlock
. Get newVmaVirtualBlock
object.
Example:
VmaVirtualBlockCreateInfo blockCreateInfo = {};
blockCreateInfo.size = 1048576; // 1 MB
VmaVirtualBlock block;
VkResult res = vmaCreateVirtualBlock(&blockCreateInfo, &block);
Making virtual allocations
VmaVirtualBlock
object contains internal data structure that keeps track of free and occupied regions using the same code as the main Vulkan
memory allocator. Similarly to VmaAllocation
for standard GPU allocations, there is VmaVirtualAllocation
type that represents an opaque
handle to an allocation within the virtual block.
In order to make such allocation:
- Fill in
VmaVirtualAllocationCreateInfo
structure. - Call
VirtualAllocate
. Get newVmaVirtualAllocation
object that represents the allocation. You can also receiveVkDeviceSize offset
that was assigned to the allocation.
Example:
VmaVirtualAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.size = 4096; // 4 KB
VmaVirtualAllocation alloc;
VkDeviceSize offset;
res = vmaVirtualAllocate(block, &allocCreateInfo, &alloc, &offset);
if(res == VK_SUCCESS)
{
// Use the 4 KB of your memory starting at offset.
}
else
{
// Allocation failed - no space for it could be found. Handle this error!
}
Deallocation
When no longer needed, an allocation can be freed by calling VirtualFree
. You can only pass to this function an allocation that was previously
returned by vmaVirtualAllocate()
called for the same VmaVirtualBlock
.
When whole block is no longer needed, the block object can be released by calling DestroyVirtualBlock
. All allocations must be freed before the
block is destroyed, which is checked internally by an assert. However, if you don't want to call vmaVirtualFree()
for each allocation, you can
use ClearVirtualBlock
to free them all at once - a feature not available in normal Vulkan memory allocator. Example:
vmaVirtualFree(block, alloc);
vmaDestroyVirtualBlock(block);
Allocation parameters
You can attach a custom pointer to each allocation by using SetVirtualAllocationUserData
. Its default value is null. It can be used to store any
data that needs to be associated with that allocation - e.g. an index, a handle, or a pointer to some larger data structure containing more
information. Example:
struct CustomAllocData
{
std::string m_AllocName;
};
CustomAllocData* allocData = new CustomAllocData();
allocData->m_AllocName = "My allocation 1";
vmaSetVirtualAllocationUserData(block, alloc, allocData);
The pointer can later be fetched, along with allocation offset and size, by passing the allocation handle to function GetVirtualAllocationInfo
and
inspecting returned structure VmaVirtualAllocationInfo
. If you allocated a new object to be used as the custom pointer, don't forget to delete
that object before freeing the allocation! Example:
VmaVirtualAllocationInfo allocInfo;
vmaGetVirtualAllocationInfo(block, alloc, &allocInfo);
delete (CustomAllocData*)allocInfo.pUserData;
vmaVirtualFree(block, alloc);
Alignment and units
It feels natural to express sizes and offsets in bytes. If an offset of an allocation needs to be aligned to a multiply of some number (e.g. 4 bytes),
you can fill optional member VmaVirtualAllocationCreateInfo::alignment
to request it. Example:
VmaVirtualAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.size = 4096; // 4 KB
allocCreateInfo.alignment = 4; // Returned offset must be a multiply of 4 B
VmaVirtualAllocation alloc;
res = vmaVirtualAllocate(block, &allocCreateInfo, &alloc, nullptr);
Alignments of different allocations made from one block may vary. However, if all alignments and sizes are always multiply of some size e.g. 4 B or
sizeof(MyDataStruct)
, you can express all sizes, alignments, and offsets in multiples of that size instead of individual bytes. It might be
more convenient, but you need to make sure to use this new unit consistently in all the places:
VmaVirtualBlockCreateInfo::size
VmaVirtualAllocationCreateInfo::size
andVmaVirtualAllocationCreateInfo::alignment
- Using offset returned by
vmaVirtualAllocate()
or inVmaVirtualAllocationInfo::offset
Statistics
You can obtain statistics of a virtual block using GetVirtualBlockStatistics
(to get brief statistics that are fast to calculate) or
CalculateVirtualBlockStatistics
(to get more detailed statistics, slower to calculate). The functions fill structures VmaStatistics
,
VmaDetailedStatistics
respectively - same as used by the normal Vulkan memory allocator. Example:
VmaStatistics stats;
vmaGetVirtualBlockStatistics(block, &stats);
printf("My virtual block has %llu bytes used by %u virtual allocations\n",
stats.allocationBytes, stats.allocationCount);
You can also request a full list of allocations and free regions as a string in JSON format by calling BuildVirtualBlockStatsString
. Returned string
must be later freed using FreeVirtualBlockStatsString
. The format of this string differs from the one returned by the main Vulkan allocator, but it
is similar.
Additional considerations
The "virtual allocator" functionality is implemented on a level of individual memory blocks. Keeping track of a whole collection of blocks, allocating new ones when out of free space, deleting empty ones, and deciding which one to try first for a new allocation must be implemented by the user.
Alternative allocation algorithms are supported, just like in custom pools of the real GPU memory. See enum VmaVirtualBlockCreateFlagBits
to
learn how to specify them (e.g. VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
). Allocation strategies are also supported. See enum
VmaVirtualAllocationCreateFlagBits
to learn how to specify them (e.g. VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
).
Following features are supported only by the allocator of the real GPU memory and not by virtual allocations: buffer-image granularity,
VMA_DEBUG_MARGIN
, VMA_MIN_ALIGNMENT
.
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 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
and with allocations that can be mapped.. It works also with dedicated
allocations.
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 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 appear in JSON dump as part of free space.
Note that enabling margins increases memory usage and fragmentation.
Margins do not apply to virtual allocator.
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) 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 is 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
.
OpenGL Interop
VMA provides some features that help with interoperability with OpenGL.
Exporting memory
If you want to attach VkExportMemoryAllocateInfoKHR
structure to pNext
chain of memory allocations made by the library:
It is recommended to create custom memory pools for such allocations. Define and fill in your VkExportMemoryAllocateInfoKHR
structure and
attach it to VmaPoolCreateInfo
::pMemoryAllocateNext
while creating the custom pool. Please note that the structure must remain alive and
unchanged for the whole lifetime of the VmaPool
, not only while creating it, as no copy of the structure is made, but its original pointer is
used for each allocation instead.
If you want to export all memory allocated by the library from certain memory types, also dedicated allocations or other allocations made from default
pools, an alternative solution is to fill in VmaAllocatorCreateInfo
::pTypeExternalMemoryHandleTypes
. It should point to an array with
VkExternalMemoryHandleTypeFlagsKHR
to be automatically passed by the library through VkExportMemoryAllocateInfoKHR
on each allocation
made from a specific memory type. Please note that new versions of the library also support dedicated allocations created in custom pools.
You should not mix these two methods in a way that allows to apply both to the same memory type. Otherwise, VkExportMemoryAllocateInfoKHR
structure would be attached twice to the pNext
chain of VkMemoryAllocateInfo
.
Custom alignment
Buffers or images exported to a different API like OpenGL may require a different alignment, higher than the one used by the library automatically,
queried from functions like vkGetBufferMemoryRequirements
. To impose such alignment:
It is recommended to create custom memory pools for such allocations. Set VmaPoolCreateInfo
::minAllocationAlignment
member to the minimum
alignment required for each allocation to be made out of this pool. The alignment actually used will be the maximum of this member and the alignment
returned for the specific buffer or image from a function like vkGetBufferMemoryRequirements
, which is called by VMA automatically.
If you want to create a buffer with a specific minimum alignment out of default pools, use special function CreateBufferWithAlignment
, which takes
additional parameter minAlignment
.
Note the problem of alignment affects only resources placed inside bigger VkDeviceMemory
blocks and not dedicated allocations, as these, by
definition, always have alignment = 0
because the resource is bound to the beginning of its dedicated block. Contrary to Direct3D 12, Vulkan
doesn't have a concept of alignment of the entire memory block passed on its allocation.
Recommended usage patterns
Vulkan gives great flexibility in memory allocation. This chapter shows the most common patterns.
See also slides from talk: Sawicki, Adam. Advanced Graphics Techniques Tutorial: Memory management in Vulkan and DX12. Game Developers Conference, 2018
GPU-only resource
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: Let the library select the optimal memory type, which will likely have VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.
VkImageCreateInfo imgCreateInfo = { VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO };
imgCreateInfo.imageType = VK_IMAGE_TYPE_2D;
imgCreateInfo.extent.width = 3840;
imgCreateInfo.extent.height = 2160;
imgCreateInfo.extent.depth = 1;
imgCreateInfo.mipLevels = 1;
imgCreateInfo.arrayLayers = 1;
imgCreateInfo.format = VK_FORMAT_R8G8B8A8_UNORM;
imgCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
imgCreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
imgCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
imgCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
VmaAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
allocCreateInfo.flags = VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT;
allocCreateInfo.priority = 1.0f;
VkImage img;
VmaAllocation alloc;
vmaCreateImage(allocator, &imgCreateInfo, &allocCreateInfo, &img, &alloc, nullptr);
Also consider: 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 with different sizes e.g. when display resolution changes. Prefer to create such resources first and all other GPU
resources (like textures and vertex buffers) later. When VK_EXT_memory_priority
extension is enabled, it is also worth setting high priority to
such allocation to decrease chances to be evicted to system memory by the operating system.
Staging copy for upload
When: A "staging" buffer than you want to map and fill from CPU code, then use as a source of transfer to some GPU resource.
What to do: Use flag ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
. Let the library select the optimal memory type, which will always have
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
.
VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
bufCreateInfo.size = 65536;
bufCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT;
VmaAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
allocCreateInfo.flags = VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT |
VMA_ALLOCATION_CREATE_MAPPED_BIT;
VkBuffer buf;
VmaAllocation alloc;
VmaAllocationInfo allocInfo;
vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo);
...
memcpy(allocInfo.pMappedData, myData, myDataSize);
Also consider: You can map the allocation using MapMemory
or you can create it as persistenly mapped using ALLOCATION_CREATE_MAPPED_BIT
, as
in the example above.
Readback
When: Buffers for data written by or transferred from the GPU that you want to read back on the CPU, e.g. results of some computations.
What to do: Use flag ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
. Let the library select the optimal memory type, which will always have
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
and VK_MEMORY_PROPERTY_HOST_CACHED_BIT
.
VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
bufCreateInfo.size = 65536;
bufCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_DST_BIT;
VmaAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
allocCreateInfo.flags = VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT |
VMA_ALLOCATION_CREATE_MAPPED_BIT;
VkBuffer buf;
VmaAllocation alloc;
VmaAllocationInfo allocInfo;
vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo);
...
const float* downloadedData = (const float*)allocInfo.pMappedData;
Advanced data uploading
For resources that you frequently write on CPU via mapped pointer and frequently read on GPU e.g. as a uniform buffer (also called "dynamic"), multiple options are possible:
- Easiest solution is to have one copy of the resource in
HOST_VISIBLE
memory, even if it means system RAM (notDEVICE_LOCAL
) on systems with a discrete graphics card, and make the device reach out to that resource directly. Reads performed by the device will then go through PCI Express bus. The performance of this access may be limited, but it may be fine depending on the size of this resource (whether it is small enough to quickly end up in GPU cache) and the sparsity of access. - On systems with unified memory (e.g. AMD APU or Intel integrated graphics, mobile chips), a memory type may be available that is both
HOST_VISIBLE
(available for mapping) andDEVICE_LOCAL
(fast to access from the GPU). Then, it is likely the best choice for such type of resource. - Systems with a discrete graphics card and separate video memory may or may not expose a memory type that is both
HOST_VISIBLE
andDEVICE_LOCAL
, also known as Base Address Register (BAR). If they do, it represents a piece of VRAM (or entire VRAM, if ReBAR is enabled in the motherboard BIOS) that is available to CPU for mapping. Writes performed by the host to that memory go through PCI Express bus. The performance of these writes may be limited, but it may be fine, especially on PCIe 4.0, as long as rules of using uncached and write-combined memory are followed - only sequential writes and no reads. - Finally, you may need or prefer to create a separate copy of the resource in
DEVICE_LOCAL
memory, a separate "staging" copy inHOST_VISIBLE
memory and perform an explicit transfer command between them.
Thankfully, VMA offers an aid to create and use such resources in the the way optimal for the current Vulkan device. To help the library make the best
choice, use flag ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
together with ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
. It will
then prefer a memory type that is both DEVICE_LOCAL
and HOST_VISIBLE
(integrated memory or BAR), but if no such memory type is
available or allocation from it fails (PC graphics cards have only 256 MB of BAR by default, unless ReBAR is supported and enabled in BIOS), it will
fall back to DEVICE_LOCAL
memory for fast GPU access. It is then up to you to detect that the allocation ended up in a memory type that is not
HOST_VISIBLE
, so you need to create another "staging" allocation and perform explicit transfers.
VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
bufCreateInfo.size = 65536;
bufCreateInfo.usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;
VmaAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
allocCreateInfo.flags = VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT |
VMA_ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT |
VMA_ALLOCATION_CREATE_MAPPED_BIT;
VkBuffer buf;
VmaAllocation alloc;
VmaAllocationInfo allocInfo;
vmaCreateBuffer(allocator, &bufCreateInfo, &allocCreateInfo, &buf, &alloc, &allocInfo);
VkMemoryPropertyFlags memPropFlags;
vmaGetAllocationMemoryProperties(allocator, alloc, &memPropFlags);
if(memPropFlags & VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT)
{
// Allocation ended up in a mappable memory and is already mapped - write to it directly.
// [Executed in runtime]:
memcpy(allocInfo.pMappedData, myData, myDataSize);
}
else
{
// Allocation ended up in a non-mappable memory - need to transfer.
VkBufferCreateInfo stagingBufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };
stagingBufCreateInfo.size = 65536;
stagingBufCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT;
VmaAllocationCreateInfo stagingAllocCreateInfo = {};
stagingAllocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
stagingAllocCreateInfo.flags = VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT |
VMA_ALLOCATION_CREATE_MAPPED_BIT;
VkBuffer stagingBuf;
VmaAllocation stagingAlloc;
VmaAllocationInfo stagingAllocInfo;
vmaCreateBuffer(allocator, &stagingBufCreateInfo, &stagingAllocCreateInfo,
&stagingBuf, &stagingAlloc, stagingAllocInfo);
// [Executed in runtime]:
memcpy(stagingAllocInfo.pMappedData, myData, myDataSize);
vmaFlushAllocation(allocator, stagingAlloc, 0, VK_WHOLE_SIZE);
//vkCmdPipelineBarrier: VK_ACCESS_HOST_WRITE_BIT --> VK_ACCESS_TRANSFER_READ_BIT
VkBufferCopy bufCopy = {
0, // srcOffset
0, // dstOffset,
myDataSize); // size
vkCmdCopyBuffer(cmdBuf, stagingBuf, buf, 1, &bufCopy);
}
Other use cases
Here are some other, less obvious use cases and their recommended settings:
- An image that is used only as transfer source and destination, but it should stay on the device, as it is used to temporarily store a copy of some
texture, e.g. from the current to the next frame, for temporal antialiasing or other temporal effects.
- Use
VkImageCreateInfo::usage = VK_IMAGE_USAGE_TRANSFER_SRC_BIT | VK_IMAGE_USAGE_TRANSFER_DST_BIT
- Use
VmaAllocationCreateInfo::usage = VMA_MEMORY_USAGE_AUTO
- Use
- An image that is used only as transfer source and destination, but it should be placed in the system RAM despite it doesn't need to be mapped,
because it serves as a "swap" copy to evict least recently used textures from VRAM.
- Use
VkImageCreateInfo::usage = VK_IMAGE_USAGE_TRANSFER_SRC_BIT | VK_IMAGE_USAGE_TRANSFER_DST_BIT
- Use
VmaAllocationCreateInfo::usage = VMA_MEMORY_USAGE_AUTO_PREFER_HOST
, as VMA needs a hint here to differentiate from the previous case.
- Use
- A buffer that you want to map and write from the CPU, directly read from the GPU (e.g. as a uniform or vertex buffer), but you have a clear
preference to place it in device or host memory due to its large size.
- Use
VkBufferCreateInfo::usage = VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT
- Use
VmaAllocationCreateInfo::usage = VMA_MEMORY_USAGE_AUTO_PREFER_DEVICE or VMA_MEMORY_USAGE_AUTO_PREFER_HOST
- Use
VmaAllocationCreateInfo::flags = VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Use
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-dependent - 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.
It has been promoted to core Vulkan 1.1, so if you use eligible Vulkan version and inform VMA about it by setting
VmaAllocatorCreateInfo
::vulkanApiVersion
, you are all set.
Otherwise, if you want to use it as an extension:
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 is 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_EXT_memory_priority
VK_EXT_memory_priority
is a device extension that allows to pass additional "priority" value to Vulkan memory allocations that the
implementation may use prefer certain buffers and images that are critical for performance to stay in device-local memory in cases when the memory is
over-subscribed, while some others may be moved to the system memory.
VMA offers convenient usage of this extension. If you enable it, you can pass "priority" parameter when creating allocations or custom pools and the library automatically passes the value to Vulkan using this extension.
If you want to use this extension in connection with VMA, follow these steps:
Initialization
- Call
vkEnumerateDeviceExtensionProperties
for the physical device. Check if the extension is supported - if returned array ofVkExtensionProperties
contains"VK_EXT_memory_priority"
. - Call
vkGetPhysicalDeviceFeatures2
for the physical device instead of oldvkGetPhysicalDeviceFeatures
. Attach additional structureVkPhysicalDeviceMemoryPriorityFeaturesEXT
toVkPhysicalDeviceFeatures2::pNext
to be returned. Check if the device feature is really supported - check ifVkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority
is true. - While creating device with
vkCreateDevice
, enable this extension - add"VK_EXT_memory_priority"
to the list passed asVkDeviceCreateInfo::ppEnabledExtensionNames
. - While creating the device, also don't set
VkDeviceCreateInfo::pEnabledFeatures
. Fill inVkPhysicalDeviceFeatures2
structure instead and pass it asVkDeviceCreateInfo::pNext
. Enable this device feature - attach additional structureVkPhysicalDeviceMemoryPriorityFeaturesEXT
toVkPhysicalDeviceFeatures2::pNext
chain and set its membermemoryPriority
toVK_TRUE
. - While creating
VmaAllocator
withCreateAllocator
inform VMA that you have enabled this extension and feature - addALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
toVmaAllocatorCreateInfo
::flags
.
Usage
When using this extension, you should initialize following member:
VmaAllocationCreateInfo
::priority
when creating a dedicated allocation withALLOCATION_CREATE_DEDICATED_MEMORY_BIT
.VmaPoolCreateInfo
::priority
when creating a custom pool.
It should be a floating-point value between 0.0f
and 1.0f
, where recommended default is 0.5f
. Memory allocated with higher
value can be treated by the Vulkan implementation as higher priority and so it can have lower chances of being pushed out to system memory,
experiencing degraded performance.
It might be a good idea to create performance-critical resources like color-attachment or depth-stencil images as dedicated and set high priority to them. For example:
VkImageCreateInfo imgCreateInfo = { VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO };
imgCreateInfo.imageType = VK_IMAGE_TYPE_2D;
imgCreateInfo.extent.width = 3840;
imgCreateInfo.extent.height = 2160;
imgCreateInfo.extent.depth = 1;
imgCreateInfo.mipLevels = 1;
imgCreateInfo.arrayLayers = 1;
imgCreateInfo.format = VK_FORMAT_R8G8B8A8_UNORM;
imgCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
imgCreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
imgCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
imgCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
VmaAllocationCreateInfo allocCreateInfo = {};
allocCreateInfo.usage = VMA_MEMORY_USAGE_AUTO;
allocCreateInfo.flags = VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT;
allocCreateInfo.priority = 1.0f;
VkImage img;
VmaAllocation alloc;
vmaCreateImage(allocator, &imgCreateInfo, &allocCreateInfo, &img, &alloc, nullptr);
priority
member is ignored in the following situations:
- Allocations created in custom pools: They inherit the priority, along with all other allocation parameters from the parameters passed in
VmaPoolCreateInfo
when the pool was created. - Allocations created in default pools: They inherit the priority from the parameters VMA used when creating default pools, which means
priority == 0.5f
.
VK_AMD_device_coherent_memory
VK_AMD_device_coherent_memory
is a device extension that enables access to additional memory types with
VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD
and VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD
flag. It is useful mostly for allocation of
buffers intended for writing "breadcrumb markers" in between passes or draw calls, which in turn are useful for debugging GPU crash/hang/TDR cases.
When the extension is available but has not been enabled, Vulkan physical device still exposes those memory types, but their usage is forbidden. VMA
automatically takes care of that - it returns VK_ERROR_FEATURE_NOT_PRESENT
when an attempt to allocate memory of such type is made.
If you want to use this extension in connection with VMA, follow these steps:
Initialization
- Call
vkEnumerateDeviceExtensionProperties
for the physical device. Check if the extension is supported - if returned array ofVkExtensionProperties
contains"VK_AMD_device_coherent_memory"
. - Call
vkGetPhysicalDeviceFeatures2
for the physical device instead of oldvkGetPhysicalDeviceFeatures
. Attach additional structureVkPhysicalDeviceCoherentMemoryFeaturesAMD
toVkPhysicalDeviceFeatures2::pNext
to be returned. Check if the device feature is really supported - check ifVkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory
is true. - While creating device with
vkCreateDevice
, enable this extension - add"VK_AMD_device_coherent_memory"
to the list passed asVkDeviceCreateInfo::ppEnabledExtensionNames
. - While creating the device, also don't set
VkDeviceCreateInfo::pEnabledFeatures
. Fill inVkPhysicalDeviceFeatures2
structure instead and pass it asVkDeviceCreateInfo::pNext
. Enable this device feature - attach additional structureVkPhysicalDeviceCoherentMemoryFeaturesAMD
toVkPhysicalDeviceFeatures2::pNext
and set its memberdeviceCoherentMemory
toVK_TRUE
. - While creating
VmaAllocator
withCreateAllocator
inform VMA that you have enabled this extension and feature - addALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
toVmaAllocatorCreateInfo
::flags
.
Usage
After following steps described above, you can create VMA allocations and custom pools out of the special DEVICE_COHERENT
and
DEVICE_UNCACHED
memory types on eligible devices. There are multiple ways to do it, for example:
- You can request or prefer to allocate out of such memory types by adding
VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD
toVmaAllocationCreateInfo
::requiredFlags
orVmaAllocationCreateInfo::preferredFlags
. Those flags can be freely mixed with other ways of choosing memory type, like settingVmaAllocationCreateInfo::usage
. - If you manually found memory type index to use for this purpose, force allocation from this specific index by setting
VmaAllocationCreateInfo::memoryTypeBits = 1u << index
.
More information
To learn more about this extension, see VK_AMD_device_coherent_memory in Vulkan specification.
Example use of this extension can be found in the code of the sample and test suite accompanying this library.
Enabling buffer device address
Device extension VK_KHR_buffer_device_address
allows to fetch raw GPU pointer to a buffer and pass it for usage in a shader code. It has been
promoted to core Vulkan 1.2.
If you want to use this feature in connection with VMA, follow these steps:
Initialization
- (For Vulkan version < 1.2) Call
vkEnumerateDeviceExtensionProperties
for the physical device. Check if the extension is supported - if returned array ofVkExtensionProperties
contains"VK_KHR_buffer_device_address"
. - Call
vkGetPhysicalDeviceFeatures2
for the physical device instead of oldvkGetPhysicalDeviceFeatures
. Attach additional structureVkPhysicalDeviceBufferDeviceAddressFeatures*
toVkPhysicalDeviceFeatures2::pNext
to be returned. Check if the device feature is really supported - check ifVkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress
is true. - (For Vulkan version < 1.2) While creating device with
vkCreateDevice
, enable this extension - add"VK_KHR_buffer_device_address"
to the list passed asVkDeviceCreateInfo::ppEnabledExtensionNames
. - While creating the device, also don't set
VkDeviceCreateInfo::pEnabledFeatures
. Fill inVkPhysicalDeviceFeatures2
structure instead and pass it asVkDeviceCreateInfo::pNext
. Enable this device feature - attach additional structureVkPhysicalDeviceBufferDeviceAddressFeatures*
toVkPhysicalDeviceFeatures2::pNext
and set its memberbufferDeviceAddress
toVK_TRUE
. - While creating
VmaAllocator
withCreateAllocator
inform VMA that you have enabled this feature - addALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
toVmaAllocatorCreateInfo
::flags
.
Usage
After following steps described above, you can create buffers with VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT*
using VMA. The library
automatically adds VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT*
to allocated memory blocks wherever it might be needed.
Please note that the library supports only VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT*
. The second part of this functionality related to
"capture and replay" is not supported, as it is intended for usage in debugging tools like RenderDoc, not in everyday Vulkan usage.
More information
To learn more about this extension, see VK_KHR_buffer_device_address in Vulkan specification
Example use of this extension can be found in the code of the sample and test suite accompanying this library.
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 perVkDevice
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. This includes allocation and deallocation from default memory pool, as well as customVmaPool
. - When the allocator is created with
ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT
flag, calls to functions that take suchVmaAllocator
object must be synchronized externally. - Access to a
VmaAllocation
object must be externally synchronized. For example, you must not callGetAllocationInfo
andMapMemory
from different threads at the same time if you pass the sameVmaAllocation
object to these functions. VmaVirtualBlock
is not safe to be used from multiple threads simultaneously.
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 buffer0xeb8e4
butvkGetBufferMemoryRequirements()
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. OnlyGENERAL
orPREINITIALIZED
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 buffer0xeb8e4
which may indicate a bug.It may happen when you use defragmentation.
Allocation algorithm
The library uses following algorithm for allocation, in order:
- Try to find free range of memory in existing blocks.
- If failed, try to create a new block of
VkDeviceMemor
y, with preferred block size. - If failed, try to create such block with
size / 2
,size / 4
,size / 8
. - If failed, try to allocate separate
VkDeviceMemory
for this allocation, just like when you useALLOCATION_CREATE_DEDICATED_MEMORY_BIT
. - If failed, choose other memory type that meets the requirements specified in
VmaAllocationCreateInfo
and go to point 1. - 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. VMA doesn't record any commands to a
VkCommandBuffer
. It just allocates memory. - 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 is because the big structuresVkBufferCreateInfo
,VkImageCreateInfo
are not stored inVmaAllocation
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. Success of an allocation is just checked with an assert.
- 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.
There are many preprocessor macros that make some variables unused, function parameters unreferenced, or conditional expressions constant in some configurations. The code of this library should not be bigger or more complicated just to silence these warnings. It is recommended to disable such warnings instead.
- This is a C++ library with C interface. Bindings or ports to any other programming languages are welcome as external projects but are not going to be included into this repository.
-
Field Summary
Modifier and TypeFieldDescriptionstatic final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
.static final int
Flags for createdVmaAllocator
.static final int
Flags for createdVmaAllocator
.static final int
Flags for createdVmaAllocator
.static final int
Flags for createdVmaAllocator
.static final int
Flags for createdVmaAllocator
.static final int
Flags for createdVmaAllocator
.static final int
Flags for createdVmaAllocator
.static final int
Flags to be passed asVmaDefragmentationInfo
::flags
.static final int
Flags to be passed asVmaDefragmentationInfo
::flags
.static final int
Flags to be passed asVmaDefragmentationInfo
::flags
.static final int
Flags to be passed asVmaDefragmentationInfo
::flags
.static final int
Flags to be passed asVmaDefragmentationInfo
::flags
.static final int
VmaDefragmentationMoveOperationstatic final int
VmaDefragmentationMoveOperationstatic final int
VmaDefragmentationMoveOperationstatic final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
VmaMemoryUsage
static final int
Flags to be passed asVmaPoolCreateInfo
::flags
.static final int
Flags to be passed asVmaPoolCreateInfo
::flags
.static final int
Flags to be passed asVmaPoolCreateInfo
::flags
.static final int
Flags to be passed asVmaVirtualAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaVirtualAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaVirtualAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaVirtualAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaVirtualAllocationCreateInfo
::flags
.static final int
Flags to be passed asVmaVirtualBlockCreateInfo
::flags
.static final int
Flags to be passed asVmaVirtualBlockCreateInfo
::flags
.static final int
Flags to be passed asVmaAllocationCreateInfo
::flags
. -
Method Summary
Modifier and TypeMethodDescriptionstatic 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
nvmaBeginDefragmentation
(long allocator, long pInfo, long pContext) Unsafe version of:BeginDefragmentation
static int
nvmaBeginDefragmentationPass
(long allocator, long context, long pInfo) Unsafe version of:BeginDefragmentationPass
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
nvmaBuildVirtualBlockStatsString
(long virtualBlock, long ppStatsString, int detailedMap) Unsafe version of:BuildVirtualBlockStatsString
static void
nvmaCalculatePoolStatistics
(long allocator, long pool, long pPoolStats) Unsafe version of:CalculatePoolStatistics
static void
nvmaCalculateStatistics
(long allocator, long pStats) Unsafe version of:CalculateStatistics
static void
nvmaCalculateVirtualBlockStatistics
(long virtualBlock, long pStats) Unsafe version of:CalculateVirtualBlockStatistics
static int
nvmaCheckCorruption
(long allocator, int memoryTypeBits) Unsafe version of:CheckCorruption
static int
nvmaCheckPoolCorruption
(long allocator, long pool) Unsafe version of:CheckPoolCorruption
static void
nvmaClearVirtualBlock
(long virtualBlock) Unsafe version of:ClearVirtualBlock
static int
nvmaCreateAliasingBuffer
(long allocator, long allocation, long pBufferCreateInfo, long pBuffer) Unsafe version of:CreateAliasingBuffer
static int
nvmaCreateAliasingBuffer2
(long allocator, long allocation, long allocationLocalOffset, long pBufferCreateInfo, long pBuffer) Unsafe version of:CreateAliasingBuffer2
static int
nvmaCreateAliasingImage
(long allocator, long allocation, long pImageCreateInfo, long pImage) Unsafe version of:CreateAliasingImage
static int
nvmaCreateAliasingImage2
(long allocator, long allocation, long allocationLocalOffset, long pImageCreateInfo, long pImage) Unsafe version of:CreateAliasingImage2
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
nvmaCreateBufferWithAlignment
(long allocator, long pBufferCreateInfo, long pAllocationCreateInfo, long minAlignment, long pBuffer, long pAllocation, long pAllocationInfo) Unsafe version of:CreateBufferWithAlignment
static int
nvmaCreateImage
(long allocator, long pImageCreateInfo, long pAllocationCreateInfo, long pImage, long pAllocation, long pAllocationInfo) Unsafe version of:CreateImage
static int
nvmaCreatePool
(long allocator, long pCreateInfo, long pPool) Unsafe version of:CreatePool
static int
nvmaCreateVirtualBlock
(long pCreateInfo, long pVirtualBlock) Unsafe version of:CreateVirtualBlock
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 void
nvmaDestroyVirtualBlock
(long virtualBlock) Unsafe version of:DestroyVirtualBlock
static void
nvmaEndDefragmentation
(long allocator, long context, long pStats) Unsafe version of:EndDefragmentation
static int
nvmaEndDefragmentationPass
(long allocator, long context, long pPassInfo) Unsafe version of:EndDefragmentationPass
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 int
nvmaFlushAllocations
(long allocator, int allocationCount, long allocations, long offsets, long sizes) Unsafe version of:FlushAllocations
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
nvmaFreeVirtualBlockStatsString
(long virtualBlock, long pStatsString) Unsafe version of:FreeVirtualBlockStatsString
static void
nvmaGetAllocationInfo
(long allocator, long allocation, long pAllocationInfo) Unsafe version of:GetAllocationInfo
static void
nvmaGetAllocationMemoryProperties
(long allocator, long allocation, long pFlags) Unsafe version of:GetAllocationMemoryProperties
static void
nvmaGetAllocatorInfo
(long allocator, long pAllocatorInfo) Unsafe version of:GetAllocatorInfo
static void
nvmaGetHeapBudgets
(long allocator, long pBudget) Unsafe version of:GetHeapBudgets
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
nvmaGetPoolStatistics
(long allocator, long pool, long pPoolStats) Unsafe version of:GetPoolStatistics
static void
nvmaGetVirtualAllocationInfo
(long virtualBlock, long allocation, long pVirtualAllocInfo) Unsafe version of:GetVirtualAllocationInfo
static void
nvmaGetVirtualBlockStatistics
(long virtualBlock, long pStats) Unsafe version of:GetVirtualBlockStatistics
static void
nvmaInvalidateAllocation
(long allocator, long allocation, long offset, long size) Unsafe version of:InvalidateAllocation
static int
nvmaInvalidateAllocations
(long allocator, int allocationCount, long allocations, long offsets, long sizes) Unsafe version of:InvalidateAllocations
static int
nvmaIsVirtualBlockEmpty
(long virtualBlock) Unsafe version of:IsVirtualBlockEmpty
static int
nvmaMapMemory
(long allocator, long allocation, long ppData) Unsafe version of:MapMemory
static void
nvmaSetAllocationName
(long allocator, long allocation, long pName) Unsafe version of:SetAllocationName
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 void
nvmaSetVirtualAllocationUserData
(long virtualBlock, long allocation, long pUserData) Unsafe version of:SetVirtualAllocationUserData
static void
nvmaUnmapMemory
(long allocator, long allocation) Unsafe version of:UnmapMemory
static int
nvmaVirtualAllocate
(long virtualBlock, long pCreateInfo, long pAllocation, long pOffset) Unsafe version of:VirtualAllocate
static void
nvmaVirtualFree
(long virtualBlock, long allocation) Unsafe version of:VirtualFree
static int
vmaAllocateMemory
(long allocator, VkMemoryRequirements pVkMemoryRequirements, VmaAllocationCreateInfo pCreateInfo, PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) General purpose memory allocation.static int
vmaAllocateMemoryForBuffer
(long allocator, long buffer, VmaAllocationCreateInfo pCreateInfo, PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) Allocates memory suitable for givenVkBuffer
.static int
vmaAllocateMemoryForImage
(long allocator, long image, VmaAllocationCreateInfo pCreateInfo, PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) Allocates memory suitable for givenVkImage
.static int
vmaAllocateMemoryPages
(long allocator, VkMemoryRequirements pVkMemoryRequirements, VmaAllocationCreateInfo pCreateInfo, PointerBuffer pAllocations, VmaAllocationInfo.Buffer pAllocationInfo) General purpose memory allocation for multiple allocation objects at once.static int
vmaBeginDefragmentation
(long allocator, VmaDefragmentationInfo pInfo, PointerBuffer pContext) Begins defragmentation process.static int
vmaBeginDefragmentationPass
(long allocator, long context, VmaDefragmentationPassMoveInfo pInfo) Starts single defragmentation pass.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, PointerBuffer ppStatsString, boolean detailedMap) Builds and returns statistics as a null-terminated string in JSON format.static void
vmaBuildVirtualBlockStatsString
(long virtualBlock, PointerBuffer ppStatsString, boolean detailedMap) Builds and returns a null-terminated string in JSON format with information about givenVmaVirtualBlock
.static void
vmaCalculatePoolStatistics
(long allocator, long pool, VmaDetailedStatistics pPoolStats) Retrieves detailed statistics of existingVmaPool
object.static void
vmaCalculateStatistics
(long allocator, VmaTotalStatistics pStats) Retrieves statistics from current state of the Allocator.static void
vmaCalculateVirtualBlockStatistics
(long virtualBlock, VmaDetailedStatistics pStats) Calculates and returns detailed statistics about virtual allocations and memory usage in givenVmaVirtualBlock
.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 void
vmaClearVirtualBlock
(long virtualBlock) Frees all virtual allocations inside givenVmaVirtualBlock
.static int
vmaCreateAliasingBuffer
(long allocator, long allocation, VkBufferCreateInfo pBufferCreateInfo, LongBuffer pBuffer) Creates a newVkBuffer
, binds already created memory for it.static int
vmaCreateAliasingBuffer2
(long allocator, long allocation, long allocationLocalOffset, VkBufferCreateInfo pBufferCreateInfo, LongBuffer pBuffer) Creates a newVkBuffer
, binds already created memory for it.static int
vmaCreateAliasingImage
(long allocator, long allocation, VkImageCreateInfo pImageCreateInfo, LongBuffer pImage) Function similar toCreateAliasingBuffer
but for images.static int
vmaCreateAliasingImage2
(long allocator, long allocation, long allocationLocalOffset, VkImageCreateInfo pImageCreateInfo, LongBuffer pImage) Function similar toCreateAliasingBuffer2
but for images.static int
vmaCreateAllocator
(VmaAllocatorCreateInfo pCreateInfo, PointerBuffer pAllocator) Creates Allocator object.static int
vmaCreateBuffer
(long allocator, VkBufferCreateInfo pBufferCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, LongBuffer pBuffer, PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) Creates a newVkBuffer
, allocates and binds memory for it.static int
vmaCreateBufferWithAlignment
(long allocator, VkBufferCreateInfo pBufferCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, long minAlignment, LongBuffer pBuffer, PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) Similar toCreateBuffer
but provides additional parameterminAlignment
which allows to specify custom, minimum alignment to be used when placing the buffer inside a larger memory block, which may be needed e.g.static int
vmaCreateImage
(long allocator, VkImageCreateInfo pImageCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, LongBuffer pImage, PointerBuffer pAllocation, VmaAllocationInfo pAllocationInfo) Function similar toCreateBuffer
.static int
vmaCreatePool
(long allocator, VmaPoolCreateInfo pCreateInfo, PointerBuffer pPool) Allocates Vulkan device memory and createsVmaPool
object.static int
vmaCreateVirtualBlock
(VmaVirtualBlockCreateInfo pCreateInfo, PointerBuffer pVirtualBlock) Creates newVmaVirtualBlock
object.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) DestroysVmaPool
object and frees Vulkan device memory.static void
vmaDestroyVirtualBlock
(long virtualBlock) DestroysVmaVirtualBlock
object.static void
vmaEndDefragmentation
(long allocator, long context, VmaDefragmentationStats pStats) Ends defragmentation process.static int
vmaEndDefragmentationPass
(long allocator, long context, VmaDefragmentationPassMoveInfo pPassInfo) Ends single defragmentation pass.static int
vmaFindMemoryTypeIndex
(long allocator, int memoryTypeBits, VmaAllocationCreateInfo pAllocationCreateInfo, IntBuffer pMemoryTypeIndex) static int
vmaFindMemoryTypeIndexForBufferInfo
(long allocator, VkBufferCreateInfo pBufferCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, IntBuffer pMemoryTypeIndex) static int
vmaFindMemoryTypeIndexForImageInfo
(long allocator, VkImageCreateInfo pImageCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, IntBuffer pMemoryTypeIndex) static void
vmaFlushAllocation
(long allocator, long allocation, long offset, long size) Flushes memory of given allocation.static int
vmaFlushAllocations
(long allocator, PointerBuffer allocations, LongBuffer offsets, LongBuffer sizes) Flushes memory of given set of allocations.static void
vmaFreeMemory
(long allocator, long allocation) Frees memory previously allocated usingAllocateMemory
,AllocateMemoryForBuffer
, orAllocateMemoryForImage
.static void
vmaFreeMemoryPages
(long allocator, PointerBuffer pAllocations) Frees memory and destroys multiple allocations.static void
vmaFreeStatsString
(long allocator, ByteBuffer pStatsString) static void
vmaFreeVirtualBlockStatsString
(long virtualBlock, ByteBuffer pStatsString) Frees a string returned byBuildVirtualBlockStatsString
.static void
vmaGetAllocationInfo
(long allocator, long allocation, VmaAllocationInfo pAllocationInfo) Returns current information about specified allocation.static void
vmaGetAllocationMemoryProperties
(long allocator, long allocation, IntBuffer pFlags) Given an allocation, returns Property Flags of its memory type.static void
vmaGetAllocatorInfo
(long allocator, VmaAllocatorInfo pAllocatorInfo) Returns information about existingVmaAllocator
object - handle to Vulkan device etc.static void
vmaGetHeapBudgets
(long allocator, VmaBudget.Buffer pBudget) Retrieves information about current memory usage and budget for all memory heaps.static void
vmaGetMemoryProperties
(long allocator, PointerBuffer ppPhysicalDeviceMemoryProperties) PhysicalDeviceMemoryProperties
are fetched fromphysicalDevice
by the allocator.static void
vmaGetMemoryTypeProperties
(long allocator, int memoryTypeIndex, IntBuffer pFlags) Given Memory Type Index, returns Property Flags of this memory type.static void
vmaGetPhysicalDeviceProperties
(long allocator, PointerBuffer ppPhysicalDeviceProperties) PhysicalDeviceProperties
are fetched fromphysicalDevice
by the allocator.static void
vmaGetPoolName
(long allocator, long pool, PointerBuffer ppName) Retrieves name of a custom pool.static void
vmaGetPoolStatistics
(long allocator, long pool, VmaStatistics pPoolStats) Retrieves statistics of existing VmaPool object.static void
vmaGetVirtualAllocationInfo
(long virtualBlock, long allocation, VmaVirtualAllocationInfo pVirtualAllocInfo) Returns information about a specific virtual allocation within a virtual block, like its size andpUserData
pointer.static void
vmaGetVirtualBlockStatistics
(long virtualBlock, VmaStatistics pStats) Calculates and returns statistics about virtual allocations and memory usage in givenVmaVirtualBlock
.static void
vmaInvalidateAllocation
(long allocator, long allocation, long offset, long size) Invalidates memory of given allocation.static int
vmaInvalidateAllocations
(long allocator, PointerBuffer allocations, LongBuffer offsets, LongBuffer sizes) Invalidates memory of given set of allocations.static boolean
vmaIsVirtualBlockEmpty
(long virtualBlock) Returns true of theVmaVirtualBlock
is empty - contains 0 virtual allocations and has all its space available for new allocations.static int
vmaMapMemory
(long allocator, long allocation, PointerBuffer ppData) Maps memory represented by given allocation and returns pointer to it.static void
vmaSetAllocationName
(long allocator, long allocation, CharSequence pName) SetspName
in given allocation to new value.static void
vmaSetAllocationName
(long allocator, long allocation, ByteBuffer pName) SetspName
in given allocation to new value.static void
vmaSetAllocationUserData
(long allocator, long allocation, long pUserData) SetspUserData
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, CharSequence pName) Sets name of a custom pool.static void
vmaSetPoolName
(long allocator, long pool, ByteBuffer pName) Sets name of a custom pool.static void
vmaSetVirtualAllocationUserData
(long virtualBlock, long allocation, long pUserData) Changes custom pointer associated with given virtual allocation.static void
vmaUnmapMemory
(long allocator, long allocation) Unmaps memory represented by given allocation, mapped previously usingMapMemory
.static int
vmaVirtualAllocate
(long virtualBlock, VmaVirtualAllocationCreateInfo pCreateInfo, PointerBuffer pAllocation, LongBuffer pOffset) Allocates new virtual allocation inside givenVmaVirtualBlock
.static void
vmaVirtualFree
(long virtualBlock, long allocation) Frees virtual allocation inside givenVmaVirtualBlock
.
-
Field Details
-
VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BIT
public static final int VMA_ALLOCATOR_CREATE_EXTERNALLY_SYNCHRONIZED_BITFlags for createdVmaAllocator
. (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 ofVK_KHR_dedicated_allocation
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_API_VERSION_1_1
, the flag is ignored because the extension has been promoted to Vulkan 1.1.Using this extension will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used
ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
flag) when it is recommended by the driver. It may improve performance on some GPUs.You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as
VmaAllocatorCreateInfo
::device
, and you want them to be used internally by this library:VK_KHR_get_memory_requirements2
(device extension)VK_KHR_dedicated_allocation
(device extension)
When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them.
> vkBindBufferMemory(): Binding memory to buffer 0x2d but vkGetBufferMemoryRequirements() has not been called on that buffer.
ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
- Enables usage ofVK_KHR_bind_memory2
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_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
andvkBindImageMemory2KHR
, which allow to pass a chain ofpNext
structures while binding. This flag is required if you usepNext
parameter inBindBufferMemory2
orBindImageMemory2
.ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
- Enables usage ofVK_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 extensionVK_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.
ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
- Enables usage ofVK_AMD_device_coherent_memory
extension.You may set this flag only if you:
- found out that this device extension is supported and enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,
- checked that `VkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory` is true and set it while creating the Vulkan device,
- want it to be used internally by this library.
The extension and accompanying device feature provide access to memory types with `VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD` and `VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD` flags. They are useful mostly for writing breadcrumb markers - a common method for debugging GPU crash/hang/TDR.
When the extension is not enabled, such memory types are still enumerated, but their usage is illegal. To protect from this error, if you don't create the allocator with this flag, it will refuse to allocate any memory or create a custom pool in such memory type, returning `VK_ERROR_FEATURE_NOT_PRESENT`.
ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
- Enables usage of "buffer device address" feature, which allows you to use functionvkGetBufferDeviceAddress*
to get raw GPU pointer to a buffer and pass it for usage inside a shader.You may set this flag only if you:
- (For Vulkan version < 1.2) Found as available and enabled device extension
VK_KHR_buffer_device_address
. This extension is promoted to core Vulkan 1.2. - Found as available and enabled device feature
VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress
.
When this flag is set, you can create buffers with
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT
using VMA. The library automatically addsVK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT
to allocated memory blocks wherever it might be needed.- (For Vulkan version < 1.2) Found as available and enabled device extension
ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
- Enables usage ofVK_EXT_memory_priority
extension in the library.You may set this flag only if you found available and enabled this device extension, along with
VkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority == VK_TRUE
, while creating Vulkan device passed asVmaAllocatorCreateInfo::device
.When this flag is used,
VmaAllocationCreateInfo::priority
andVmaPoolCreateInfo::priority
are used to set priorities of allocated Vulkan memory. Without it, these variables are ignored.A priority must be a floating-point value between 0 and 1, indicating the priority of the allocation relative to other memory allocations. Larger values are higher priority. The granularity of the priorities is implementation-dependent. It is automatically passed to every call to
vkAllocateMemory
done by the library using structureVkMemoryPriorityAllocateInfoEXT
. The value to be used for default priority is 0.5. For more details, see the documentation of theVK_EXT_memory_priority
extension.
- See Also:
-
VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT
public static final int VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BITFlags for createdVmaAllocator
. (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 ofVK_KHR_dedicated_allocation
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_API_VERSION_1_1
, the flag is ignored because the extension has been promoted to Vulkan 1.1.Using this extension will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used
ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
flag) when it is recommended by the driver. It may improve performance on some GPUs.You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as
VmaAllocatorCreateInfo
::device
, and you want them to be used internally by this library:VK_KHR_get_memory_requirements2
(device extension)VK_KHR_dedicated_allocation
(device extension)
When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them.
> vkBindBufferMemory(): Binding memory to buffer 0x2d but vkGetBufferMemoryRequirements() has not been called on that buffer.
ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
- Enables usage ofVK_KHR_bind_memory2
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_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
andvkBindImageMemory2KHR
, which allow to pass a chain ofpNext
structures while binding. This flag is required if you usepNext
parameter inBindBufferMemory2
orBindImageMemory2
.ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
- Enables usage ofVK_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 extensionVK_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.
ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
- Enables usage ofVK_AMD_device_coherent_memory
extension.You may set this flag only if you:
- found out that this device extension is supported and enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,
- checked that `VkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory` is true and set it while creating the Vulkan device,
- want it to be used internally by this library.
The extension and accompanying device feature provide access to memory types with `VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD` and `VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD` flags. They are useful mostly for writing breadcrumb markers - a common method for debugging GPU crash/hang/TDR.
When the extension is not enabled, such memory types are still enumerated, but their usage is illegal. To protect from this error, if you don't create the allocator with this flag, it will refuse to allocate any memory or create a custom pool in such memory type, returning `VK_ERROR_FEATURE_NOT_PRESENT`.
ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
- Enables usage of "buffer device address" feature, which allows you to use functionvkGetBufferDeviceAddress*
to get raw GPU pointer to a buffer and pass it for usage inside a shader.You may set this flag only if you:
- (For Vulkan version < 1.2) Found as available and enabled device extension
VK_KHR_buffer_device_address
. This extension is promoted to core Vulkan 1.2. - Found as available and enabled device feature
VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress
.
When this flag is set, you can create buffers with
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT
using VMA. The library automatically addsVK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT
to allocated memory blocks wherever it might be needed.- (For Vulkan version < 1.2) Found as available and enabled device extension
ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
- Enables usage ofVK_EXT_memory_priority
extension in the library.You may set this flag only if you found available and enabled this device extension, along with
VkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority == VK_TRUE
, while creating Vulkan device passed asVmaAllocatorCreateInfo::device
.When this flag is used,
VmaAllocationCreateInfo::priority
andVmaPoolCreateInfo::priority
are used to set priorities of allocated Vulkan memory. Without it, these variables are ignored.A priority must be a floating-point value between 0 and 1, indicating the priority of the allocation relative to other memory allocations. Larger values are higher priority. The granularity of the priorities is implementation-dependent. It is automatically passed to every call to
vkAllocateMemory
done by the library using structureVkMemoryPriorityAllocateInfoEXT
. The value to be used for default priority is 0.5. For more details, see the documentation of theVK_EXT_memory_priority
extension.
- See Also:
-
VMA_ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
public static final int VMA_ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BITFlags for createdVmaAllocator
. (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 ofVK_KHR_dedicated_allocation
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_API_VERSION_1_1
, the flag is ignored because the extension has been promoted to Vulkan 1.1.Using this extension will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used
ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
flag) when it is recommended by the driver. It may improve performance on some GPUs.You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as
VmaAllocatorCreateInfo
::device
, and you want them to be used internally by this library:VK_KHR_get_memory_requirements2
(device extension)VK_KHR_dedicated_allocation
(device extension)
When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them.
> vkBindBufferMemory(): Binding memory to buffer 0x2d but vkGetBufferMemoryRequirements() has not been called on that buffer.
ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
- Enables usage ofVK_KHR_bind_memory2
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_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
andvkBindImageMemory2KHR
, which allow to pass a chain ofpNext
structures while binding. This flag is required if you usepNext
parameter inBindBufferMemory2
orBindImageMemory2
.ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
- Enables usage ofVK_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 extensionVK_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.
ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
- Enables usage ofVK_AMD_device_coherent_memory
extension.You may set this flag only if you:
- found out that this device extension is supported and enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,
- checked that `VkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory` is true and set it while creating the Vulkan device,
- want it to be used internally by this library.
The extension and accompanying device feature provide access to memory types with `VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD` and `VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD` flags. They are useful mostly for writing breadcrumb markers - a common method for debugging GPU crash/hang/TDR.
When the extension is not enabled, such memory types are still enumerated, but their usage is illegal. To protect from this error, if you don't create the allocator with this flag, it will refuse to allocate any memory or create a custom pool in such memory type, returning `VK_ERROR_FEATURE_NOT_PRESENT`.
ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
- Enables usage of "buffer device address" feature, which allows you to use functionvkGetBufferDeviceAddress*
to get raw GPU pointer to a buffer and pass it for usage inside a shader.You may set this flag only if you:
- (For Vulkan version < 1.2) Found as available and enabled device extension
VK_KHR_buffer_device_address
. This extension is promoted to core Vulkan 1.2. - Found as available and enabled device feature
VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress
.
When this flag is set, you can create buffers with
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT
using VMA. The library automatically addsVK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT
to allocated memory blocks wherever it might be needed.- (For Vulkan version < 1.2) Found as available and enabled device extension
ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
- Enables usage ofVK_EXT_memory_priority
extension in the library.You may set this flag only if you found available and enabled this device extension, along with
VkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority == VK_TRUE
, while creating Vulkan device passed asVmaAllocatorCreateInfo::device
.When this flag is used,
VmaAllocationCreateInfo::priority
andVmaPoolCreateInfo::priority
are used to set priorities of allocated Vulkan memory. Without it, these variables are ignored.A priority must be a floating-point value between 0 and 1, indicating the priority of the allocation relative to other memory allocations. Larger values are higher priority. The granularity of the priorities is implementation-dependent. It is automatically passed to every call to
vkAllocateMemory
done by the library using structureVkMemoryPriorityAllocateInfoEXT
. The value to be used for default priority is 0.5. For more details, see the documentation of theVK_EXT_memory_priority
extension.
- See Also:
-
VMA_ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
public static final int VMA_ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BITFlags for createdVmaAllocator
. (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 ofVK_KHR_dedicated_allocation
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_API_VERSION_1_1
, the flag is ignored because the extension has been promoted to Vulkan 1.1.Using this extension will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used
ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
flag) when it is recommended by the driver. It may improve performance on some GPUs.You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as
VmaAllocatorCreateInfo
::device
, and you want them to be used internally by this library:VK_KHR_get_memory_requirements2
(device extension)VK_KHR_dedicated_allocation
(device extension)
When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them.
> vkBindBufferMemory(): Binding memory to buffer 0x2d but vkGetBufferMemoryRequirements() has not been called on that buffer.
ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
- Enables usage ofVK_KHR_bind_memory2
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_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
andvkBindImageMemory2KHR
, which allow to pass a chain ofpNext
structures while binding. This flag is required if you usepNext
parameter inBindBufferMemory2
orBindImageMemory2
.ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
- Enables usage ofVK_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 extensionVK_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.
ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
- Enables usage ofVK_AMD_device_coherent_memory
extension.You may set this flag only if you:
- found out that this device extension is supported and enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,
- checked that `VkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory` is true and set it while creating the Vulkan device,
- want it to be used internally by this library.
The extension and accompanying device feature provide access to memory types with `VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD` and `VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD` flags. They are useful mostly for writing breadcrumb markers - a common method for debugging GPU crash/hang/TDR.
When the extension is not enabled, such memory types are still enumerated, but their usage is illegal. To protect from this error, if you don't create the allocator with this flag, it will refuse to allocate any memory or create a custom pool in such memory type, returning `VK_ERROR_FEATURE_NOT_PRESENT`.
ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
- Enables usage of "buffer device address" feature, which allows you to use functionvkGetBufferDeviceAddress*
to get raw GPU pointer to a buffer and pass it for usage inside a shader.You may set this flag only if you:
- (For Vulkan version < 1.2) Found as available and enabled device extension
VK_KHR_buffer_device_address
. This extension is promoted to core Vulkan 1.2. - Found as available and enabled device feature
VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress
.
When this flag is set, you can create buffers with
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT
using VMA. The library automatically addsVK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT
to allocated memory blocks wherever it might be needed.- (For Vulkan version < 1.2) Found as available and enabled device extension
ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
- Enables usage ofVK_EXT_memory_priority
extension in the library.You may set this flag only if you found available and enabled this device extension, along with
VkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority == VK_TRUE
, while creating Vulkan device passed asVmaAllocatorCreateInfo::device
.When this flag is used,
VmaAllocationCreateInfo::priority
andVmaPoolCreateInfo::priority
are used to set priorities of allocated Vulkan memory. Without it, these variables are ignored.A priority must be a floating-point value between 0 and 1, indicating the priority of the allocation relative to other memory allocations. Larger values are higher priority. The granularity of the priorities is implementation-dependent. It is automatically passed to every call to
vkAllocateMemory
done by the library using structureVkMemoryPriorityAllocateInfoEXT
. The value to be used for default priority is 0.5. For more details, see the documentation of theVK_EXT_memory_priority
extension.
- See Also:
-
VMA_ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
public static final int VMA_ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BITFlags for createdVmaAllocator
. (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 ofVK_KHR_dedicated_allocation
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_API_VERSION_1_1
, the flag is ignored because the extension has been promoted to Vulkan 1.1.Using this extension will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used
ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
flag) when it is recommended by the driver. It may improve performance on some GPUs.You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as
VmaAllocatorCreateInfo
::device
, and you want them to be used internally by this library:VK_KHR_get_memory_requirements2
(device extension)VK_KHR_dedicated_allocation
(device extension)
When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them.
> vkBindBufferMemory(): Binding memory to buffer 0x2d but vkGetBufferMemoryRequirements() has not been called on that buffer.
ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
- Enables usage ofVK_KHR_bind_memory2
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_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
andvkBindImageMemory2KHR
, which allow to pass a chain ofpNext
structures while binding. This flag is required if you usepNext
parameter inBindBufferMemory2
orBindImageMemory2
.ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
- Enables usage ofVK_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 extensionVK_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.
ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
- Enables usage ofVK_AMD_device_coherent_memory
extension.You may set this flag only if you:
- found out that this device extension is supported and enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,
- checked that `VkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory` is true and set it while creating the Vulkan device,
- want it to be used internally by this library.
The extension and accompanying device feature provide access to memory types with `VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD` and `VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD` flags. They are useful mostly for writing breadcrumb markers - a common method for debugging GPU crash/hang/TDR.
When the extension is not enabled, such memory types are still enumerated, but their usage is illegal. To protect from this error, if you don't create the allocator with this flag, it will refuse to allocate any memory or create a custom pool in such memory type, returning `VK_ERROR_FEATURE_NOT_PRESENT`.
ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
- Enables usage of "buffer device address" feature, which allows you to use functionvkGetBufferDeviceAddress*
to get raw GPU pointer to a buffer and pass it for usage inside a shader.You may set this flag only if you:
- (For Vulkan version < 1.2) Found as available and enabled device extension
VK_KHR_buffer_device_address
. This extension is promoted to core Vulkan 1.2. - Found as available and enabled device feature
VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress
.
When this flag is set, you can create buffers with
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT
using VMA. The library automatically addsVK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT
to allocated memory blocks wherever it might be needed.- (For Vulkan version < 1.2) Found as available and enabled device extension
ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
- Enables usage ofVK_EXT_memory_priority
extension in the library.You may set this flag only if you found available and enabled this device extension, along with
VkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority == VK_TRUE
, while creating Vulkan device passed asVmaAllocatorCreateInfo::device
.When this flag is used,
VmaAllocationCreateInfo::priority
andVmaPoolCreateInfo::priority
are used to set priorities of allocated Vulkan memory. Without it, these variables are ignored.A priority must be a floating-point value between 0 and 1, indicating the priority of the allocation relative to other memory allocations. Larger values are higher priority. The granularity of the priorities is implementation-dependent. It is automatically passed to every call to
vkAllocateMemory
done by the library using structureVkMemoryPriorityAllocateInfoEXT
. The value to be used for default priority is 0.5. For more details, see the documentation of theVK_EXT_memory_priority
extension.
- See Also:
-
VMA_ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
public static final int VMA_ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BITFlags for createdVmaAllocator
. (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 ofVK_KHR_dedicated_allocation
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_API_VERSION_1_1
, the flag is ignored because the extension has been promoted to Vulkan 1.1.Using this extension will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used
ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
flag) when it is recommended by the driver. It may improve performance on some GPUs.You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as
VmaAllocatorCreateInfo
::device
, and you want them to be used internally by this library:VK_KHR_get_memory_requirements2
(device extension)VK_KHR_dedicated_allocation
(device extension)
When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them.
> vkBindBufferMemory(): Binding memory to buffer 0x2d but vkGetBufferMemoryRequirements() has not been called on that buffer.
ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
- Enables usage ofVK_KHR_bind_memory2
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_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
andvkBindImageMemory2KHR
, which allow to pass a chain ofpNext
structures while binding. This flag is required if you usepNext
parameter inBindBufferMemory2
orBindImageMemory2
.ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
- Enables usage ofVK_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 extensionVK_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.
ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
- Enables usage ofVK_AMD_device_coherent_memory
extension.You may set this flag only if you:
- found out that this device extension is supported and enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,
- checked that `VkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory` is true and set it while creating the Vulkan device,
- want it to be used internally by this library.
The extension and accompanying device feature provide access to memory types with `VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD` and `VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD` flags. They are useful mostly for writing breadcrumb markers - a common method for debugging GPU crash/hang/TDR.
When the extension is not enabled, such memory types are still enumerated, but their usage is illegal. To protect from this error, if you don't create the allocator with this flag, it will refuse to allocate any memory or create a custom pool in such memory type, returning `VK_ERROR_FEATURE_NOT_PRESENT`.
ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
- Enables usage of "buffer device address" feature, which allows you to use functionvkGetBufferDeviceAddress*
to get raw GPU pointer to a buffer and pass it for usage inside a shader.You may set this flag only if you:
- (For Vulkan version < 1.2) Found as available and enabled device extension
VK_KHR_buffer_device_address
. This extension is promoted to core Vulkan 1.2. - Found as available and enabled device feature
VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress
.
When this flag is set, you can create buffers with
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT
using VMA. The library automatically addsVK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT
to allocated memory blocks wherever it might be needed.- (For Vulkan version < 1.2) Found as available and enabled device extension
ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
- Enables usage ofVK_EXT_memory_priority
extension in the library.You may set this flag only if you found available and enabled this device extension, along with
VkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority == VK_TRUE
, while creating Vulkan device passed asVmaAllocatorCreateInfo::device
.When this flag is used,
VmaAllocationCreateInfo::priority
andVmaPoolCreateInfo::priority
are used to set priorities of allocated Vulkan memory. Without it, these variables are ignored.A priority must be a floating-point value between 0 and 1, indicating the priority of the allocation relative to other memory allocations. Larger values are higher priority. The granularity of the priorities is implementation-dependent. It is automatically passed to every call to
vkAllocateMemory
done by the library using structureVkMemoryPriorityAllocateInfoEXT
. The value to be used for default priority is 0.5. For more details, see the documentation of theVK_EXT_memory_priority
extension.
- See Also:
-
VMA_ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
public static final int VMA_ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BITFlags for createdVmaAllocator
. (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 ofVK_KHR_dedicated_allocation
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_API_VERSION_1_1
, the flag is ignored because the extension has been promoted to Vulkan 1.1.Using this extension will automatically allocate dedicated blocks of memory for some buffers and images instead of suballocating place for them out of bigger memory blocks (as if you explicitly used
ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
flag) when it is recommended by the driver. It may improve performance on some GPUs.You may set this flag only if you found out that following device extensions are supported, you enabled them while creating Vulkan device passed as
VmaAllocatorCreateInfo
::device
, and you want them to be used internally by this library:VK_KHR_get_memory_requirements2
(device extension)VK_KHR_dedicated_allocation
(device extension)
When this flag is set, you can experience following warnings reported by Vulkan validation layer. You can ignore them.
> vkBindBufferMemory(): Binding memory to buffer 0x2d but vkGetBufferMemoryRequirements() has not been called on that buffer.
ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
- Enables usage ofVK_KHR_bind_memory2
extension.The flag works only if
VmaAllocatorCreateInfo
::vulkanApiVersion == VK_API_VERSION_1_0
. When it isVK_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
andvkBindImageMemory2KHR
, which allow to pass a chain ofpNext
structures while binding. This flag is required if you usepNext
parameter inBindBufferMemory2
orBindImageMemory2
.ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT
- Enables usage ofVK_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 extensionVK_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.
ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT
- Enables usage ofVK_AMD_device_coherent_memory
extension.You may set this flag only if you:
- found out that this device extension is supported and enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,
- checked that `VkPhysicalDeviceCoherentMemoryFeaturesAMD::deviceCoherentMemory` is true and set it while creating the Vulkan device,
- want it to be used internally by this library.
The extension and accompanying device feature provide access to memory types with `VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD` and `VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD` flags. They are useful mostly for writing breadcrumb markers - a common method for debugging GPU crash/hang/TDR.
When the extension is not enabled, such memory types are still enumerated, but their usage is illegal. To protect from this error, if you don't create the allocator with this flag, it will refuse to allocate any memory or create a custom pool in such memory type, returning `VK_ERROR_FEATURE_NOT_PRESENT`.
ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT
- Enables usage of "buffer device address" feature, which allows you to use functionvkGetBufferDeviceAddress*
to get raw GPU pointer to a buffer and pass it for usage inside a shader.You may set this flag only if you:
- (For Vulkan version < 1.2) Found as available and enabled device extension
VK_KHR_buffer_device_address
. This extension is promoted to core Vulkan 1.2. - Found as available and enabled device feature
VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress
.
When this flag is set, you can create buffers with
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT
using VMA. The library automatically addsVK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT
to allocated memory blocks wherever it might be needed.- (For Vulkan version < 1.2) Found as available and enabled device extension
ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT
- Enables usage ofVK_EXT_memory_priority
extension in the library.You may set this flag only if you found available and enabled this device extension, along with
VkPhysicalDeviceMemoryPriorityFeaturesEXT::memoryPriority == VK_TRUE
, while creating Vulkan device passed asVmaAllocatorCreateInfo::device
.When this flag is used,
VmaAllocationCreateInfo::priority
andVmaPoolCreateInfo::priority
are used to set priorities of allocated Vulkan memory. Without it, these variables are ignored.A priority must be a floating-point value between 0 and 1, indicating the priority of the allocation relative to other memory allocations. Larger values are higher priority. The granularity of the priorities is implementation-dependent. It is automatically passed to every call to
vkAllocateMemory
done by the library using structureVkMemoryPriorityAllocateInfoEXT
. The value to be used for default priority is 0.5. For more details, see the documentation of theVK_EXT_memory_priority
extension.
- See Also:
-
VMA_MEMORY_USAGE_UNKNOWN
public static final int VMA_MEMORY_USAGE_UNKNOWNVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_GPU_ONLY
public static final int VMA_MEMORY_USAGE_GPU_ONLYVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_CPU_ONLY
public static final int VMA_MEMORY_USAGE_CPU_ONLYVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_CPU_TO_GPU
public static final int VMA_MEMORY_USAGE_CPU_TO_GPUVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_GPU_TO_CPU
public static final int VMA_MEMORY_USAGE_GPU_TO_CPUVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_CPU_COPY
public static final int VMA_MEMORY_USAGE_CPU_COPYVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_GPU_LAZILY_ALLOCATED
public static final int VMA_MEMORY_USAGE_GPU_LAZILY_ALLOCATEDVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_AUTO
public static final int VMA_MEMORY_USAGE_AUTOVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_AUTO_PREFER_DEVICE
public static final int VMA_MEMORY_USAGE_AUTO_PREFER_DEVICEVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_MEMORY_USAGE_AUTO_PREFER_HOST
public static final int VMA_MEMORY_USAGE_AUTO_PREFER_HOSTVmaMemoryUsage
Enum values:
MEMORY_USAGE_UNKNOWN
- No intended memory usage specified.Use other members of
VmaAllocationCreateInfo
to specify your requirements.MEMORY_USAGE_GPU_ONLY
- Obsolete, preserved for backward compatibility.Prefers
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_CPU_ONLY
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
andVK_MEMORY_PROPERTY_HOST_COHERENT_BIT
.MEMORY_USAGE_CPU_TO_GPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_TO_CPU
- Obsolete, preserved for backward compatibility.Guarantees
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
, prefersVK_MEMORY_PROPERTY_HOST_CACHED_BIT
.MEMORY_USAGE_CPU_COPY
- Obsolete, preserved for backward compatibility.Prefers not
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
.MEMORY_USAGE_GPU_LAZILY_ALLOCATED
- Lazily allocated GPU memory havingVK_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
.MEMORY_USAGE_AUTO
- Selects best memory type automatically. This flag is recommended for most common use cases.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_DEVICE
- Selects best memory type automatically with preference for GPU (device) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.MEMORY_USAGE_AUTO_PREFER_HOST
- Selects best memory type automatically with preference for CPU (host) memory.When using this flag, if you want to map the allocation (using
MapMemory
orALLOCATION_CREATE_MAPPED_BIT
), you must pass one of the flags:ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
inVmaAllocationCreateInfo
::flags
.It can be used only with functions that let the library know
VkBufferCreateInfo
orVkImageCreateInfo
, e.g.CreateBuffer
,CreateImage
,FindMemoryTypeIndexForBufferInfo
,FindMemoryTypeIndexForImageInfo
and not with generic memory allocation functions.
- See Also:
-
VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
public static final int VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
public static final int VMA_ALLOCATION_CREATE_NEVER_ALLOCATE_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_MAPPED_BIT
public static final int VMA_ALLOCATION_CREATE_MAPPED_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
public static final int VMA_ALLOCATION_CREATE_USER_DATA_COPY_STRING_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_UPPER_ADDRESS_BIT
public static final int VMA_ALLOCATION_CREATE_UPPER_ADDRESS_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_DONT_BIND_BIT
public static final int VMA_ALLOCATION_CREATE_DONT_BIND_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BIT
public static final int VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_CAN_ALIAS_BIT
public static final int VMA_ALLOCATION_CREATE_CAN_ALIAS_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
public static final int VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
public static final int VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
public static final int VMA_ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
public static final int VMA_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
public static final int VMA_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
public static final int VMA_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
public static final int VMA_ALLOCATION_CREATE_STRATEGY_BEST_FIT_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
public static final int VMA_VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BITFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_ALLOCATION_CREATE_STRATEGY_MASK
public static final int VMA_ALLOCATION_CREATE_STRATEGY_MASKFlags to be passed asVmaAllocationCreateInfo
::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.
ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
- Set this flag to only try to allocate from existingVkDeviceMemory
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
andALLOCATION_CREATE_NEVER_ALLOCATE_BIT
at the same time. It makes no sense.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
.It is valid to use this flag for allocation made from memory type that is not
HOST_VISIBLE
. This flag is then ignored and memory is not mapped. This is useful if you need an allocation that is efficient to use on GPU (DEVICE_LOCAL
) and still want to map it directly if possible on platforms that support it (e.g. Intel GPU).ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
- Preserved for backward compatibility. Consider usingSetAllocationName
instead.Set this flag to treat
VmaAllocationCreateInfo
::pUserData
as pointer to a null-terminated string. Instead of copying pointer value, a local copy of the string is made and stored in allocation'spName
. The string is automatically freed together with the allocation. It is also used inBuildStatsString
.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.If you want to make sure the new buffer/image is not tied to the new memory allocation through
VkMemoryDedicatedAllocateInfoKHR
structure in case the allocation ends up in its own memory block, use also flagALLOCATION_CREATE_CAN_ALIAS_BIT
.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_CAN_ALIAS_BIT
- Set this flag if the allocated memory will have aliasing resources.Usage of this flag prevents supplying
VkMemoryDedicatedAllocateInfoKHR
whenALLOCATION_CREATE_DEDICATED_MEMORY_BIT
is specified. Otherwise created dedicated memory will not be suitable for aliasing resources, resulting in Vulkan Validation Layer errors.ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
- Requests possibility to map the allocation (usingMapMemory
orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory will only be written sequentially, e.g. using
memcpy()
or a loop writing number-by-number, never read or accessed randomly, so a memory type can be selected that is uncached and write-combined.Warning: Violating this declaration may work correctly, but will likely be very slow. Watch out for implicit reads introduced by doing e.g.
pMappedData[i] += x;
. Better prepare your data in a local variable andmemcpy()
it to the mapped pointer all at once.- If you use
ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
- Requests possibility to map the allocation (using MapMemory() orALLOCATION_CREATE_MAPPED_BIT
).- If you use
MEMORY_USAGE_AUTO
or otherVMA_MEMORY_USAGE_AUTO*
value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect. - If you use other value of
VmaMemoryUsage
, this flag is ignored and mapping is always possible in memory types that areHOST_VISIBLE
. This includes allocations created in custom memory pools.
Declares that mapped memory can be read, written, and accessed in random order, so a
HOST_CACHED
memory type is required.- If you use
ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT
- Together withALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT
orALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
, it says that despite request for host access, a not-HOST_VISIBLE
memory type can be selected if it may improve performance.By using this flag, you declare that you will check if the allocation ended up in a
HOST_VISIBLE
memory type (e.g. usingGetAllocationMemoryProperties
) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags likeVK_BUFFER_USAGE_TRANSFER_DST_BIT
,VK_BUFFER_USAGE_TRANSFER_SRC_BIT
to the parameters of created buffer or image.ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that chooses smallest possible free range for the allocation to minimize memory usage and fragmentation, possibly at the expense of allocation time.ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that chooses first suitable free range for the allocation - not necessarily in terms of the smallest offset but the one that is easiest and fastest to find to minimize allocation time, possibly at the expense of allocation quality.ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data. Used internally by defragmentation, not recommended in typical usage.
ALLOCATION_CREATE_STRATEGY_BEST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
.VMA_ALLOCATION_CREATE_STRATEGY_FIRST_FIT_BIT
- Alias toALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
.ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.
- See Also:
-
VMA_POOL_CREATE_IGNORE_BUFFER_IMAGE_GRANULARITY_BIT
public static final int VMA_POOL_CREATE_IGNORE_BUFFER_IMAGE_GRANULARITY_BITFlags to be passed asVmaPoolCreateInfo
::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
orAllocateMemory
, 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.
POOL_CREATE_ALGORITHM_MASK
- Bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_POOL_CREATE_LINEAR_ALGORITHM_BIT
public static final int VMA_POOL_CREATE_LINEAR_ALGORITHM_BITFlags to be passed asVmaPoolCreateInfo
::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
orAllocateMemory
, 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.
POOL_CREATE_ALGORITHM_MASK
- Bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_POOL_CREATE_ALGORITHM_MASK
public static final int VMA_POOL_CREATE_ALGORITHM_MASKFlags to be passed asVmaPoolCreateInfo
::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
orAllocateMemory
, 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.
POOL_CREATE_ALGORITHM_MASK
- Bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_DEFRAGMENTATION_FLAG_ALGORITHM_FAST_BIT
public static final int VMA_DEFRAGMENTATION_FLAG_ALGORITHM_FAST_BITFlags to be passed asVmaDefragmentationInfo
::flags
.VmaDefragmentationFlagBits
Enum values:
DEFRAGMENTATION_FLAG_ALGORITHM_FAST_BIT
- Use simple but fast algorithm for defragmentation.May not achieve best results but will require least time to compute and least allocations to copy.
DEFRAGMENTATION_FLAG_ALGORITHM_BALANCED_BIT
- Default defragmentation algorithm, applied also when noALGORITHM
flag is specified.Offers a balance between defragmentation quality and the amount of allocations and bytes that need to be moved.
DEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
- Perform full defragmentation of memory.Can result in notably more time to compute and allocations to copy, but will achieve best memory packing.
DEFRAGMENTATION_FLAG_ALGORITHM_EXTENSIVE_BIT
- Use the most roboust algorithm at the cost of time to compute and number of copies to make.Only available when
bufferImageGranularity
is greater than 1, since it aims to reduce alignment issues between different types of resources. Otherwise falls back to same behavior asDEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
.DEFRAGMENTATION_FLAG_ALGORITHM_MASK
- A bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_DEFRAGMENTATION_FLAG_ALGORITHM_BALANCED_BIT
public static final int VMA_DEFRAGMENTATION_FLAG_ALGORITHM_BALANCED_BITFlags to be passed asVmaDefragmentationInfo
::flags
.VmaDefragmentationFlagBits
Enum values:
DEFRAGMENTATION_FLAG_ALGORITHM_FAST_BIT
- Use simple but fast algorithm for defragmentation.May not achieve best results but will require least time to compute and least allocations to copy.
DEFRAGMENTATION_FLAG_ALGORITHM_BALANCED_BIT
- Default defragmentation algorithm, applied also when noALGORITHM
flag is specified.Offers a balance between defragmentation quality and the amount of allocations and bytes that need to be moved.
DEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
- Perform full defragmentation of memory.Can result in notably more time to compute and allocations to copy, but will achieve best memory packing.
DEFRAGMENTATION_FLAG_ALGORITHM_EXTENSIVE_BIT
- Use the most roboust algorithm at the cost of time to compute and number of copies to make.Only available when
bufferImageGranularity
is greater than 1, since it aims to reduce alignment issues between different types of resources. Otherwise falls back to same behavior asDEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
.DEFRAGMENTATION_FLAG_ALGORITHM_MASK
- A bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_DEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
public static final int VMA_DEFRAGMENTATION_FLAG_ALGORITHM_FULL_BITFlags to be passed asVmaDefragmentationInfo
::flags
.VmaDefragmentationFlagBits
Enum values:
DEFRAGMENTATION_FLAG_ALGORITHM_FAST_BIT
- Use simple but fast algorithm for defragmentation.May not achieve best results but will require least time to compute and least allocations to copy.
DEFRAGMENTATION_FLAG_ALGORITHM_BALANCED_BIT
- Default defragmentation algorithm, applied also when noALGORITHM
flag is specified.Offers a balance between defragmentation quality and the amount of allocations and bytes that need to be moved.
DEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
- Perform full defragmentation of memory.Can result in notably more time to compute and allocations to copy, but will achieve best memory packing.
DEFRAGMENTATION_FLAG_ALGORITHM_EXTENSIVE_BIT
- Use the most roboust algorithm at the cost of time to compute and number of copies to make.Only available when
bufferImageGranularity
is greater than 1, since it aims to reduce alignment issues between different types of resources. Otherwise falls back to same behavior asDEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
.DEFRAGMENTATION_FLAG_ALGORITHM_MASK
- A bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_DEFRAGMENTATION_FLAG_ALGORITHM_EXTENSIVE_BIT
public static final int VMA_DEFRAGMENTATION_FLAG_ALGORITHM_EXTENSIVE_BITFlags to be passed asVmaDefragmentationInfo
::flags
.VmaDefragmentationFlagBits
Enum values:
DEFRAGMENTATION_FLAG_ALGORITHM_FAST_BIT
- Use simple but fast algorithm for defragmentation.May not achieve best results but will require least time to compute and least allocations to copy.
DEFRAGMENTATION_FLAG_ALGORITHM_BALANCED_BIT
- Default defragmentation algorithm, applied also when noALGORITHM
flag is specified.Offers a balance between defragmentation quality and the amount of allocations and bytes that need to be moved.
DEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
- Perform full defragmentation of memory.Can result in notably more time to compute and allocations to copy, but will achieve best memory packing.
DEFRAGMENTATION_FLAG_ALGORITHM_EXTENSIVE_BIT
- Use the most roboust algorithm at the cost of time to compute and number of copies to make.Only available when
bufferImageGranularity
is greater than 1, since it aims to reduce alignment issues between different types of resources. Otherwise falls back to same behavior asDEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
.DEFRAGMENTATION_FLAG_ALGORITHM_MASK
- A bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_DEFRAGMENTATION_FLAG_ALGORITHM_MASK
public static final int VMA_DEFRAGMENTATION_FLAG_ALGORITHM_MASKFlags to be passed asVmaDefragmentationInfo
::flags
.VmaDefragmentationFlagBits
Enum values:
DEFRAGMENTATION_FLAG_ALGORITHM_FAST_BIT
- Use simple but fast algorithm for defragmentation.May not achieve best results but will require least time to compute and least allocations to copy.
DEFRAGMENTATION_FLAG_ALGORITHM_BALANCED_BIT
- Default defragmentation algorithm, applied also when noALGORITHM
flag is specified.Offers a balance between defragmentation quality and the amount of allocations and bytes that need to be moved.
DEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
- Perform full defragmentation of memory.Can result in notably more time to compute and allocations to copy, but will achieve best memory packing.
DEFRAGMENTATION_FLAG_ALGORITHM_EXTENSIVE_BIT
- Use the most roboust algorithm at the cost of time to compute and number of copies to make.Only available when
bufferImageGranularity
is greater than 1, since it aims to reduce alignment issues between different types of resources. Otherwise falls back to same behavior asDEFRAGMENTATION_FLAG_ALGORITHM_FULL_BIT
.DEFRAGMENTATION_FLAG_ALGORITHM_MASK
- A bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_DEFRAGMENTATION_MOVE_OPERATION_COPY
public static final int VMA_DEFRAGMENTATION_MOVE_OPERATION_COPYVmaDefragmentationMoveOperationEnum values:
DEFRAGMENTATION_MOVE_OPERATION_COPY
- Buffer/image has been recreated atdstTmpAllocation
, data has been copied, old buffer/image has been destroyed.srcAllocation
should be changed to point to the new place. This is the default value set byBeginDefragmentationPass
.DEFRAGMENTATION_MOVE_OPERATION_IGNORE
- Set this value if you cannot move the allocation.New place reserved at
dstTmpAllocation
will be freed.srcAllocation
will remain unchanged.DEFRAGMENTATION_MOVE_OPERATION_DESTROY
- Set this value if you decide to abandon the allocation and you destroyed the buffer/image.New place reserved at
dstTmpAllocation
will be freed, along withsrcAllocation
, which will be destroyed.
- See Also:
-
VMA_DEFRAGMENTATION_MOVE_OPERATION_IGNORE
public static final int VMA_DEFRAGMENTATION_MOVE_OPERATION_IGNOREVmaDefragmentationMoveOperationEnum values:
DEFRAGMENTATION_MOVE_OPERATION_COPY
- Buffer/image has been recreated atdstTmpAllocation
, data has been copied, old buffer/image has been destroyed.srcAllocation
should be changed to point to the new place. This is the default value set byBeginDefragmentationPass
.DEFRAGMENTATION_MOVE_OPERATION_IGNORE
- Set this value if you cannot move the allocation.New place reserved at
dstTmpAllocation
will be freed.srcAllocation
will remain unchanged.DEFRAGMENTATION_MOVE_OPERATION_DESTROY
- Set this value if you decide to abandon the allocation and you destroyed the buffer/image.New place reserved at
dstTmpAllocation
will be freed, along withsrcAllocation
, which will be destroyed.
- See Also:
-
VMA_DEFRAGMENTATION_MOVE_OPERATION_DESTROY
public static final int VMA_DEFRAGMENTATION_MOVE_OPERATION_DESTROYVmaDefragmentationMoveOperationEnum values:
DEFRAGMENTATION_MOVE_OPERATION_COPY
- Buffer/image has been recreated atdstTmpAllocation
, data has been copied, old buffer/image has been destroyed.srcAllocation
should be changed to point to the new place. This is the default value set byBeginDefragmentationPass
.DEFRAGMENTATION_MOVE_OPERATION_IGNORE
- Set this value if you cannot move the allocation.New place reserved at
dstTmpAllocation
will be freed.srcAllocation
will remain unchanged.DEFRAGMENTATION_MOVE_OPERATION_DESTROY
- Set this value if you decide to abandon the allocation and you destroyed the buffer/image.New place reserved at
dstTmpAllocation
will be freed, along withsrcAllocation
, which will be destroyed.
- See Also:
-
VMA_VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
public static final int VMA_VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BITFlags to be passed asVmaVirtualBlockCreateInfo
::flags
. (VmaVirtualBlockCreateFlagBits
)Enum values:
VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
- Enables alternative, linear allocation algorithm in this virtual block.Specify this flag to enable linear allocation algorithm, which always creates new allocations after last one and doesn't reuse space from allocations freed in between. It trades memory consumption for simplified algorithm and data structure, which has better performance and uses less memory for metadata.
By using this flag, you can achieve behavior of free-at-once, stack, ring buffer, and double stack.
VIRTUAL_BLOCK_CREATE_ALGORITHM_MASK
- Bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_VIRTUAL_BLOCK_CREATE_ALGORITHM_MASK
public static final int VMA_VIRTUAL_BLOCK_CREATE_ALGORITHM_MASKFlags to be passed asVmaVirtualBlockCreateInfo
::flags
. (VmaVirtualBlockCreateFlagBits
)Enum values:
VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
- Enables alternative, linear allocation algorithm in this virtual block.Specify this flag to enable linear allocation algorithm, which always creates new allocations after last one and doesn't reuse space from allocations freed in between. It trades memory consumption for simplified algorithm and data structure, which has better performance and uses less memory for metadata.
By using this flag, you can achieve behavior of free-at-once, stack, ring buffer, and double stack.
VIRTUAL_BLOCK_CREATE_ALGORITHM_MASK
- Bit mask to extract onlyALGORITHM
bits from entire set of flags.
- See Also:
-
VMA_VIRTUAL_ALLOCATION_CREATE_UPPER_ADDRESS_BIT
public static final int VMA_VIRTUAL_ALLOCATION_CREATE_UPPER_ADDRESS_BITFlags to be passed asVmaVirtualAllocationCreateInfo
::flags
. (VmaVirtualAllocationCreateFlagBits
)Enum values:
VIRTUAL_ALLOCATION_CREATE_UPPER_ADDRESS_BIT
- Allocation will be created from upper stack in a double stack pool.This flag is only allowed for virtual blocks created with
VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
flag.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that tries to minimize memory usage.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that tries to minimize allocation time.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data.
VIRTUAL_ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.These stategy flags are binary compatible with equivalent flags in
VmaAllocationCreateFlagBits
.
- See Also:
-
VMA_VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
public static final int VMA_VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BITFlags to be passed asVmaVirtualAllocationCreateInfo
::flags
. (VmaVirtualAllocationCreateFlagBits
)Enum values:
VIRTUAL_ALLOCATION_CREATE_UPPER_ADDRESS_BIT
- Allocation will be created from upper stack in a double stack pool.This flag is only allowed for virtual blocks created with
VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
flag.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that tries to minimize memory usage.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that tries to minimize allocation time.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data.
VIRTUAL_ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.These stategy flags are binary compatible with equivalent flags in
VmaAllocationCreateFlagBits
.
- See Also:
-
VMA_VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
public static final int VMA_VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BITFlags to be passed asVmaVirtualAllocationCreateInfo
::flags
. (VmaVirtualAllocationCreateFlagBits
)Enum values:
VIRTUAL_ALLOCATION_CREATE_UPPER_ADDRESS_BIT
- Allocation will be created from upper stack in a double stack pool.This flag is only allowed for virtual blocks created with
VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
flag.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that tries to minimize memory usage.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that tries to minimize allocation time.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data.
VIRTUAL_ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.These stategy flags are binary compatible with equivalent flags in
VmaAllocationCreateFlagBits
.
- See Also:
-
VMA_VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
public static final int VMA_VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BITFlags to be passed asVmaVirtualAllocationCreateInfo
::flags
. (VmaVirtualAllocationCreateFlagBits
)Enum values:
VIRTUAL_ALLOCATION_CREATE_UPPER_ADDRESS_BIT
- Allocation will be created from upper stack in a double stack pool.This flag is only allowed for virtual blocks created with
VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
flag.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that tries to minimize memory usage.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that tries to minimize allocation time.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data.
VIRTUAL_ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.These stategy flags are binary compatible with equivalent flags in
VmaAllocationCreateFlagBits
.
- See Also:
-
VMA_VIRTUAL_ALLOCATION_CREATE_STRATEGY_MASK
public static final int VMA_VIRTUAL_ALLOCATION_CREATE_STRATEGY_MASKFlags to be passed asVmaVirtualAllocationCreateInfo
::flags
. (VmaVirtualAllocationCreateFlagBits
)Enum values:
VIRTUAL_ALLOCATION_CREATE_UPPER_ADDRESS_BIT
- Allocation will be created from upper stack in a double stack pool.This flag is only allowed for virtual blocks created with
VIRTUAL_BLOCK_CREATE_LINEAR_ALGORITHM_BIT
flag.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_MEMORY_BIT
- Allocation strategy that tries to minimize memory usage.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_TIME_BIT
- Allocation strategy that tries to minimize allocation time.VIRTUAL_ALLOCATION_CREATE_STRATEGY_MIN_OFFSET_BIT
- Allocation strategy that chooses always the lowest offset in available space.This is not the most efficient strategy but achieves highly packed data.
VIRTUAL_ALLOCATION_CREATE_STRATEGY_MASK
- A bit mask to extract onlySTRATEGY
bits from entire set of flags.These stategy flags are binary compatible with equivalent flags in
VmaAllocationCreateFlagBits
.
- See Also:
-
-
Method Details
-
nvmaCreateAllocator
public static int nvmaCreateAllocator(long pCreateInfo, long pAllocator) Unsafe version of:CreateAllocator
-
vmaCreateAllocator
Creates Allocator object.LWJGL: Use
VmaVulkanFunctions
::set(VkInstance, VkDevice)
to populate theVmaAllocatorCreateInfo
::pVulkanFunctions
struct. -
nvmaDestroyAllocator
public static void nvmaDestroyAllocator(long allocator) Unsafe version of:DestroyAllocator
-
vmaDestroyAllocator
public static void vmaDestroyAllocator(long allocator) Destroys allocator object. -
nvmaGetAllocatorInfo
public static void nvmaGetAllocatorInfo(long allocator, long pAllocatorInfo) Unsafe version of:GetAllocatorInfo
-
vmaGetAllocatorInfo
Returns information about existingVmaAllocator
object - handle to Vulkan device etc.It might be useful if you want to keep just the
VmaAllocator
handle and fetch other required handles toVkPhysicalDevice
,VkDevice
etc. every time using this function. -
nvmaGetPhysicalDeviceProperties
public static void nvmaGetPhysicalDeviceProperties(long allocator, long ppPhysicalDeviceProperties) Unsafe version of:GetPhysicalDeviceProperties
-
vmaGetPhysicalDeviceProperties
public static void vmaGetPhysicalDeviceProperties(long allocator, PointerBuffer ppPhysicalDeviceProperties) PhysicalDeviceProperties
are fetched fromphysicalDevice
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, PointerBuffer ppPhysicalDeviceMemoryProperties) PhysicalDeviceMemoryProperties
are fetched fromphysicalDevice
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, 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. -
nvmaCalculateStatistics
public static void nvmaCalculateStatistics(long allocator, long pStats) Unsafe version of:CalculateStatistics
-
vmaCalculateStatistics
Retrieves statistics from current state of the Allocator.This function is called "calculate" not "get" because it has to traverse all internal data structures, so it may be quite slow. Use it for debugging purposes. For faster but more brief statistics suitable to be called every frame or every allocation, use
GetHeapBudgets
.Note that when using allocator from multiple threads, returned information may immediately become outdated.
-
nvmaGetHeapBudgets
public static void nvmaGetHeapBudgets(long allocator, long pBudget) Unsafe version of:GetHeapBudgets
-
vmaGetHeapBudgets
Retrieves information about current memory usage and 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
CalculateStatistics
.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
-
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, IntBuffer pMemoryTypeIndex) Helps to findmemoryTypeIndex
, givenmemoryTypeBits
andVmaAllocationCreateInfo
.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.
- Is allowed by
-
nvmaFindMemoryTypeIndexForBufferInfo
public static int nvmaFindMemoryTypeIndexForBufferInfo(long allocator, long pBufferCreateInfo, long pAllocationCreateInfo, long pMemoryTypeIndex) Unsafe version of:FindMemoryTypeIndexForBufferInfo
-
vmaFindMemoryTypeIndexForBufferInfo
public static int vmaFindMemoryTypeIndexForBufferInfo(long allocator, VkBufferCreateInfo pBufferCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, IntBuffer pMemoryTypeIndex) Helps to findmemoryTypeIndex
, givenVkBufferCreateInfo
andVmaAllocationCreateInfo
.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. -
nvmaFindMemoryTypeIndexForImageInfo
public static int nvmaFindMemoryTypeIndexForImageInfo(long allocator, long pImageCreateInfo, long pAllocationCreateInfo, long pMemoryTypeIndex) Unsafe version of:FindMemoryTypeIndexForImageInfo
-
vmaFindMemoryTypeIndexForImageInfo
public static int vmaFindMemoryTypeIndexForImageInfo(long allocator, VkImageCreateInfo pImageCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, IntBuffer pMemoryTypeIndex) Helps to findmemoryTypeIndex
, givenVkImageCreateInfo
andVmaAllocationCreateInfo
.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. -
nvmaCreatePool
public static int nvmaCreatePool(long allocator, long pCreateInfo, long pPool) Unsafe version of:CreatePool
-
vmaCreatePool
Allocates Vulkan device memory and createsVmaPool
object.- Parameters:
allocator
- allocator objectpCreateInfo
- parameters of pool to createpPool
- 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) DestroysVmaPool
object and frees Vulkan device memory. -
nvmaGetPoolStatistics
public static void nvmaGetPoolStatistics(long allocator, long pool, long pPoolStats) Unsafe version of:GetPoolStatistics
-
vmaGetPoolStatistics
Retrieves statistics of existing VmaPool object.- Parameters:
allocator
- allocator objectpool
- pool objectpPoolStats
- statistics of specified pool
-
nvmaCalculatePoolStatistics
public static void nvmaCalculatePoolStatistics(long allocator, long pool, long pPoolStats) Unsafe version of:CalculatePoolStatistics
-
vmaCalculatePoolStatistics
public static void vmaCalculatePoolStatistics(long allocator, long pool, VmaDetailedStatistics pPoolStats) Retrieves detailed statistics of existingVmaPool
object.- Parameters:
allocator
- allocator objectpool
- pool objectpPoolStats
- statistics of specified 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 isHOST_VISIBLE
andHOST_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_UNKNOWN
- corruption detection has been performed and found memory corruptions around one of the allocations.VMA_ASSERT
is also fired in that case.- Other value: Error returned by Vulkan, e.g. memory mapping failure.
-
nvmaGetPoolName
public static void nvmaGetPoolName(long allocator, long pool, long ppName) Unsafe version of:GetPoolName
-
vmaGetPoolName
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 usingSetPoolName
. -
nvmaSetPoolName
public static void nvmaSetPoolName(long allocator, long pool, long pName) Unsafe version of:SetPoolName
-
vmaSetPoolName
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
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, VkMemoryRequirements pVkMemoryRequirements, VmaAllocationCreateInfo pCreateInfo, PointerBuffer pAllocation, @Nullable VmaAllocationInfo pAllocationInfo) General purpose memory allocation.You should free the memory using
FreeMemory
orFreeMemoryPages
.It is recommended to use
AllocateMemoryForBuffer
,AllocateMemoryForImage
,CreateBuffer
,CreateImage
instead whenever possible.- Parameters:
pAllocation
- handle to allocated memorypAllocationInfo
- information about allocated memory. Optional. It can be later fetched using functionGetAllocationInfo
.
-
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, VkMemoryRequirements pVkMemoryRequirements, VmaAllocationCreateInfo pCreateInfo, PointerBuffer pAllocations, @Nullable VmaAllocationInfo.Buffer pAllocationInfo) General purpose memory allocation for multiple allocation objects at once.You should free the memory using
FreeMemory
orFreeMemoryPages
.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 withVK_NULL_HANDLE
.- Parameters:
allocator
- allocator objectpVkMemoryRequirements
- memory requirements for each allocationpCreateInfo
- creation parameters for each allocationpAllocations
- pointer to array that will be filled with handles to created allocationspAllocationInfo
- 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, PointerBuffer pAllocation, @Nullable VmaAllocationInfo pAllocationInfo) Allocates memory suitable for givenVkBuffer
.It only creates
VmaAllocation
. To bind the memory to the buffer, useBindBufferMemory
.This is a special-purpose function. In most cases you should use
CreateBuffer
.You must free the allocation using
FreeMemory
when no longer needed.- Parameters:
pAllocation
- handle to allocated memorypAllocationInfo
- information about allocated memory. Optional. It can be later fetched using functionGetAllocationInfo
.
-
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, PointerBuffer pAllocation, @Nullable VmaAllocationInfo pAllocationInfo) Allocates memory suitable for givenVkImage
.It only creates
VmaAllocation
. To bind the memory to the buffer, useBindImageMemory
.This is a special-purpose function. In most cases you should use
CreateImage
.You must free the allocation using
FreeMemory
when no longer needed.- Parameters:
pAllocation
- handle to allocated memorypAllocationInfo
- information about allocated memory. Optional. It can be later fetched using functionGetAllocationInfo
.
-
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 usingAllocateMemory
,AllocateMemoryForBuffer
, orAllocateMemoryForImage
.Passing
VK_NULL_HANDLE
asallocation
is valid. Such function call is just skipped. -
nvmaFreeMemoryPages
public static void nvmaFreeMemoryPages(long allocator, long allocationCount, long pAllocations) Unsafe version of:FreeMemoryPages
-
vmaFreeMemoryPages
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 callingFreeMemory
allocationCount
times.Allocations in
pAllocations
array can come from any memory pools and types. PassingVK_NULL_HANDLE
as elements ofpAllocations
array is valid. Such entries are just skipped. -
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.Current parameters of given allocation are returned in
pAllocationInfo
.Although this function doesn't lock any mutex, so it should be quite efficient, you should avoid calling it too often. You can retrieve same
VmaAllocationInfo
structure while creating your resource, from functionCreateBuffer
,CreateImage
. You can remember it if you are sure parameters don't change (e.g. due to defragmentation). -
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) SetspUserData
in given allocation to new value.The value of pointer
pUserData
is copied to allocation'spUserData
. 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. -
nvmaSetAllocationName
public static void nvmaSetAllocationName(long allocator, long allocation, long pName) Unsafe version of:SetAllocationName
-
vmaSetAllocationName
public static void vmaSetAllocationName(long allocator, long allocation, @Nullable ByteBuffer pName) SetspName
in given allocation to new value.- Parameters:
pName
- must be either null, or pointer to a null-terminated string.The function makes local copy of the string and sets it as allocation's
pName
. String passed aspName
doesn't need to be valid for whole lifetime of the allocation - you can free it after this call. String previously pointed by allocation'spName
is freed from memory.
-
vmaSetAllocationName
public static void vmaSetAllocationName(long allocator, long allocation, @Nullable CharSequence pName) SetspName
in given allocation to new value.- Parameters:
pName
- must be either null, or pointer to a null-terminated string.The function makes local copy of the string and sets it as allocation's
pName
. String passed aspName
doesn't need to be valid for whole lifetime of the allocation - you can free it after this call. String previously pointed by allocation'spName
is freed from memory.
-
nvmaGetAllocationMemoryProperties
public static void nvmaGetAllocationMemoryProperties(long allocator, long allocation, long pFlags) Unsafe version of:GetAllocationMemoryProperties
-
vmaGetAllocationMemoryProperties
public static void vmaGetAllocationMemoryProperties(long allocator, long allocation, IntBuffer pFlags) Given an allocation, returns Property Flags of its memory type.This is just a convenience function. Same information can be obtained using
GetAllocationInfo
+GetMemoryProperties
. -
nvmaMapMemory
public static int nvmaMapMemory(long allocator, long allocation, long ppData) Unsafe version of:MapMemory
-
vmaMapMemory
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 a bigger
VkDeviceMemory
block, returned pointer is correctly offsetted to the beginning of region assigned to this particular allocation. Unlike the result ofvkMapMemory
, it points to the allocation, not to the beginning of the whole block. You should not addVmaAllocationInfo::offset
to it!Mapping is internally reference-counted and synchronized, so despite raw Vulkan function
vkMapMemory()
cannot be used to map same block ofVkDeviceMemory
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 calledvmaMapMemory()
.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 callvmaUnmapMemory()
same number of times as you calledvmaMapMemory()
. You must not callvmaUnmapMemory()
additional time to free the "0-th" mapping made automatically due toALLOCATION_CREATE_MAPPED_BIT
flag.This function fails when used on allocation made in memory type that is not
HOST_VISIBLE
.This function doesn't automatically flush or invalidate caches. If the allocation is made from a memory types that is not
HOST_COHERENT
, you also need to useInvalidateAllocation
/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 usingMapMemory
.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 useInvalidateAllocation
/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 notHOST_COHERENT
. Unmap operation doesn't do that automatically.offset
must be relative to the beginning of allocation.size
can beVK_WHOLE_SIZE
. It means all memory fromoffset
the the end of given allocation.offset
andsize
don't have to be aligned. They are internally rounded down/up to multiply ofnonCoherentAtomSize
.- If
size
is 0, this call is ignored. - If memory type that the
allocation
belongs to is notHOST_VISIBLE
or it isHOST_COHERENT
, this call is ignored.
Warning!
offset
andsize
are relative to the contents of givenallocation
. If you mean whole allocation, you can pass 0 andVK_WHOLE_SIZE
, respectively. Do not pass allocation's offset asoffset
!!! -
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 notHOST_COHERENT
. Map operation doesn't do that automatically.offset
must be relative to the beginning of allocation.size
can beVK_WHOLE_SIZE
. It means all memory fromoffset
the the end of given allocation.offset
andsize
don't have to be aligned. They are internally rounded down/up to multiply ofnonCoherentAtomSize
.- If
size
is 0, this call is ignored. - If memory type that the
allocation
belongs to is notHOST_VISIBLE
or it isHOST_COHERENT
, this call is ignored.
Warning!
offset
andsize
are relative to the contents of givenallocation
. If you mean whole allocation, you can pass 0 andVK_WHOLE_SIZE
, respectively. Do not pass allocation's offset asoffset
!!!This function returns the
VkResult
fromvkFlushMappedMemoryRanges
if it is called, otherwiseVK_SUCCESS
. -
nvmaFlushAllocations
public static int nvmaFlushAllocations(long allocator, int allocationCount, long allocations, long offsets, long sizes) Unsafe version of:FlushAllocations
-
vmaFlushAllocations
public static int vmaFlushAllocations(long allocator, PointerBuffer allocations, @Nullable LongBuffer offsets, @Nullable LongBuffer sizes) Flushes memory of given set of allocations.Calls
vkFlushMappedMemoryRanges()
for memory associated with given ranges of given allocations. For more information, see documentation ofFlushAllocation
.This function returns the
VkResult
fromvkFlushMappedMemoryRanges
if it is called, otherwiseVK_SUCCESS
.- Parameters:
offsets
- If not null, it must point to an array of offsets of regions to flush, relative to the beginning of respective allocations. Null means all ofsets are zero.sizes
- If not null, it must point to an array of sizes of regions to flush in respective allocations. Null means `VK_WHOLE_SIZE` for all allocations.
-
nvmaInvalidateAllocations
public static int nvmaInvalidateAllocations(long allocator, int allocationCount, long allocations, long offsets, long sizes) Unsafe version of:InvalidateAllocations
-
vmaInvalidateAllocations
public static int vmaInvalidateAllocations(long allocator, PointerBuffer allocations, @Nullable LongBuffer offsets, @Nullable LongBuffer sizes) Invalidates memory of given set of allocations.Calls
vkInvalidateMappedMemoryRanges()
for memory associated with given ranges of given allocations. For more information, see documentation ofInvalidateAllocation
.This function returns the
VkResult
fromvkInvalidateMappedMemoryRanges
if it is called, otherwiseVK_SUCCESS
.- Parameters:
offsets
- if not null, it must point to an array of offsets of regions to flush, relative to the beginning of respective allocations. Null means all ofsets are zero.sizes
- if not null, it must point to an array of sizes of regions to flush in respective allocations. Null meansVK_WHOLE_SIZE
for all allocations.
-
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 areHOST_VISIBLE
andHOST_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_UNKNOWN
- corruption detection has been performed and found memory corruptions around one of the allocations.VMA_ASSERT
is also fired in that case.- Other value: Error returned by Vulkan, e.g. memory mapping failure.
-
nvmaBeginDefragmentation
public static int nvmaBeginDefragmentation(long allocator, long pInfo, long pContext) Unsafe version of:BeginDefragmentation
-
vmaBeginDefragmentation
public static int vmaBeginDefragmentation(long allocator, VmaDefragmentationInfo pInfo, PointerBuffer pContext) Begins defragmentation process.- Parameters:
allocator
- allocator objectpInfo
- structure filled with parameters of defragmentationpContext
- context object that must be passed toEndDefragmentation
to finish defragmentation- Returns:
VK_SUCCESS
if defragmentation can begin.VK_ERROR_FEATURE_NOT_PRESENT
if defragmentation is not supported.
-
nvmaEndDefragmentation
public static void nvmaEndDefragmentation(long allocator, long context, long pStats) Unsafe version of:EndDefragmentation
-
vmaEndDefragmentation
public static void vmaEndDefragmentation(long allocator, long context, @Nullable VmaDefragmentationStats pStats) Ends defragmentation process.Use this function to finish defragmentation started by
BeginDefragmentation
.- Parameters:
allocator
- allocator objectcontext
- context object that has been created byBeginDefragmentation
pStats
- optional stats for the defragmentation. Can be null.
-
nvmaBeginDefragmentationPass
public static int nvmaBeginDefragmentationPass(long allocator, long context, long pInfo) Unsafe version of:BeginDefragmentationPass
-
vmaBeginDefragmentationPass
public static int vmaBeginDefragmentationPass(long allocator, long context, VmaDefragmentationPassMoveInfo pInfo) Starts single defragmentation pass.- Parameters:
allocator
- allocator objectcontext
- context object that has been created byBeginDefragmentation
pInfo
- computed information for current pass- Returns:
VK_SUCCESS
if no more moves are possible. Then you can omit call toEndDefragmentationPass
and simply end whole defragmentation.VK_INCOMPLETE
if there are pending moves returned inpPassInfo
. You need to perform them, callvmaEndDefragmentationPass()
, and then preferably try another pass withvmaBeginDefragmentationPass()
.
-
nvmaEndDefragmentationPass
public static int nvmaEndDefragmentationPass(long allocator, long context, long pPassInfo) Unsafe version of:EndDefragmentationPass
-
vmaEndDefragmentationPass
public static int vmaEndDefragmentationPass(long allocator, long context, VmaDefragmentationPassMoveInfo pPassInfo) Ends single defragmentation pass.Ends incremental defragmentation pass and commits all defragmentation moves from
pPassInfo
. After this call:- Allocations at
pPassInfo[i].srcAllocation
that hadpPassInfo[i].operation ==
DEFRAGMENTATION_MOVE_OPERATION_COPY
(which is the default) will be pointing to the new destination place. - Allocation at
pPassInfo[i].srcAllocation
that hadpPassInfo[i].operation ==
DEFRAGMENTATION_MOVE_OPERATION_DESTROY
will be freed.
If no more moves are possible you can end whole defragmentation.
- Parameters:
allocator
- allocator objectcontext
- context object that has been created byBeginDefragmentation
pPassInfo
- computed information for current pass filled byBeginDefragmentationPass
and possibly modified by you
- Allocations at
-
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 standardvkBindBufferMemory()
, because it ensures proper synchronization so that when aVkDeviceMemory
object is used by multiple allocations, calls tovkBind*Memory()
orvkMapMemory()
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 withALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
flag or withVmaAllocatorCreateInfo
::vulkanApiVersion >= VK_API_VERSION_1_1
. Otherwise the call fails.- Parameters:
allocationLocalOffset
- additional offset to be added while binding, relative to the beginning of theallocation
. Normally it should be 0.pNext
- a chain of structures to be attached toVkBindBufferMemoryInfoKHR
structure used internally. Normally it should benull
.
-
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 standardvkBindImageMemory()
, because it ensures proper synchronization so that when aVkDeviceMemory
object is used by multiple allocations, calls tovkBind*Memory()
orvkMapMemory()
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 withALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT
flag or withVmaAllocatorCreateInfo
::vulkanApiVersion >= VK_API_VERSION_1_1
. Otherwise the call fails.- Parameters:
allocationLocalOffset
- additional offset to be added while binding, relative to the beginning of theallocation
. Normally it should be 0.pNext
- a chain of structures to be attached toVkBindImageMemoryInfoKHR
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, VkBufferCreateInfo pBufferCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, LongBuffer pBuffer, PointerBuffer pAllocation, @Nullable VmaAllocationInfo pAllocationInfo) Creates a newVkBuffer
, allocates and binds memory for it.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, usingvkDestroyBuffer()
andFreeMemory
.If
ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT
flag was used,VK_KHR_dedicated_allocation
extension is used internally to query driver whether it requires or prefers the new buffer to have dedicated allocation. If yes, and if dedicated allocation is possible (ALLOCATION_CREATE_NEVER_ALLOCATE_BIT
is not used), it creates dedicated allocation for this buffer, just like when usingALLOCATION_CREATE_DEDICATED_MEMORY_BIT
.Note
This function creates a new
VkBuffer
. Sub-allocation of parts of one large buffer, although recommended as a good practice, is out of scope of this library and could be implemented by the user as a higher-level logic on top of VMA.- Parameters:
pBuffer
- buffer that was createdpAllocation
- allocation that was createdpAllocationInfo
- information about allocated memory. Optional. It can be later fetched using functionGetAllocationInfo
.
-
nvmaCreateBufferWithAlignment
public static int nvmaCreateBufferWithAlignment(long allocator, long pBufferCreateInfo, long pAllocationCreateInfo, long minAlignment, long pBuffer, long pAllocation, long pAllocationInfo) Unsafe version of:CreateBufferWithAlignment
-
vmaCreateBufferWithAlignment
public static int vmaCreateBufferWithAlignment(long allocator, VkBufferCreateInfo pBufferCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, long minAlignment, LongBuffer pBuffer, PointerBuffer pAllocation, @Nullable VmaAllocationInfo pAllocationInfo) Similar toCreateBuffer
but provides additional parameterminAlignment
which allows to specify custom, minimum alignment to be used when placing the buffer inside a larger memory block, which may be needed e.g. for interop with OpenGL.- Parameters:
minAlignment
- custom, minimum alignment to be used when placing the buffer inside a larger memory blockpBuffer
- buffer that was createdpAllocation
- allocation that was createdpAllocationInfo
- information about allocated memory. Optional. It can be later fetched using functionGetAllocationInfo
.
-
nvmaCreateAliasingBuffer
public static int nvmaCreateAliasingBuffer(long allocator, long allocation, long pBufferCreateInfo, long pBuffer) Unsafe version of:CreateAliasingBuffer
-
vmaCreateAliasingBuffer
public static int vmaCreateAliasingBuffer(long allocator, long allocation, VkBufferCreateInfo pBufferCreateInfo, LongBuffer pBuffer) Creates a newVkBuffer
, binds already created memory for it.This function automatically:
- Creates buffer.
- Binds the buffer with the supplied memory.
If any of these operations fail, buffer is not created, returned value is negative error code and
*pBuffer
is null.If the function succeeded, you must destroy the buffer when you no longer need it using
vkDestroyBuffer()
. If you want to also destroy the corresponding allocation you can use convenience functionDestroyBuffer
.Note: There is a new version of this function augmented with parameter
allocationLocalOffset
- seeCreateAliasingBuffer2
.- Parameters:
allocator
- allocatorallocation
- allocation that provides memory to be used for binding new buffer to itpBuffer
- buffer that was created
-
nvmaCreateAliasingBuffer2
public static int nvmaCreateAliasingBuffer2(long allocator, long allocation, long allocationLocalOffset, long pBufferCreateInfo, long pBuffer) Unsafe version of:CreateAliasingBuffer2
-
vmaCreateAliasingBuffer2
public static int vmaCreateAliasingBuffer2(long allocator, long allocation, long allocationLocalOffset, VkBufferCreateInfo pBufferCreateInfo, LongBuffer pBuffer) Creates a newVkBuffer
, binds already created memory for it.This function automatically:
- Creates buffer.
- Binds the buffer with the supplied memory.
If any of these operations fail, buffer is not created, returned value is negative error code and
*pBuffer
is null.If the function succeeded, you must destroy the buffer when you no longer need it using
vkDestroyBuffer()
. If you want to also destroy the corresponding allocation you can use convenience functionDestroyBuffer
.Note: This is a new version of the function augmented with parameter
allocationLocalOffset
.- Parameters:
allocator
- allocatorallocation
- allocation that provides memory to be used for binding new buffer to itallocationLocalOffset
- additional offset to be added while binding, relative to the beginning of the allocation. Normally it should be 0.pBuffer
- buffer that was created
-
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 is 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, VkImageCreateInfo pImageCreateInfo, VmaAllocationCreateInfo pAllocationCreateInfo, LongBuffer pImage, PointerBuffer pAllocation, @Nullable VmaAllocationInfo pAllocationInfo) Function similar toCreateBuffer
.- Parameters:
pImage
- image that was createdpAllocation
- allocation that was createdpAllocationInfo
- information about allocated memory. Optional. It can be later fetched using functionGetAllocationInfo
.
-
nvmaCreateAliasingImage
public static int nvmaCreateAliasingImage(long allocator, long allocation, long pImageCreateInfo, long pImage) Unsafe version of:CreateAliasingImage
-
vmaCreateAliasingImage
public static int vmaCreateAliasingImage(long allocator, long allocation, VkImageCreateInfo pImageCreateInfo, LongBuffer pImage) Function similar toCreateAliasingBuffer
but for images. -
nvmaCreateAliasingImage2
public static int nvmaCreateAliasingImage2(long allocator, long allocation, long allocationLocalOffset, long pImageCreateInfo, long pImage) Unsafe version of:CreateAliasingImage2
-
vmaCreateAliasingImage2
public static int vmaCreateAliasingImage2(long allocator, long allocation, long allocationLocalOffset, VkImageCreateInfo pImageCreateInfo, LongBuffer pImage) Function similar toCreateAliasingBuffer2
but for images. -
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 is safe to pass null as image and/or allocation.
-
nvmaCreateVirtualBlock
public static int nvmaCreateVirtualBlock(long pCreateInfo, long pVirtualBlock) Unsafe version of:CreateVirtualBlock
-
vmaCreateVirtualBlock
public static int vmaCreateVirtualBlock(VmaVirtualBlockCreateInfo pCreateInfo, PointerBuffer pVirtualBlock) Creates newVmaVirtualBlock
object.- Parameters:
pCreateInfo
- parameters for creationpVirtualBlock
- returned virtual block object orNULL
if creation failed
-
nvmaDestroyVirtualBlock
public static void nvmaDestroyVirtualBlock(long virtualBlock) Unsafe version of:DestroyVirtualBlock
-
vmaDestroyVirtualBlock
public static void vmaDestroyVirtualBlock(long virtualBlock) DestroysVmaVirtualBlock
object.Please note that you should consciously handle virtual allocations that could remain unfreed in the block. You should either free them individually using
VirtualFree
or callClearVirtualBlock
if you are sure this is what you want. If you do neither, an assert is called.If you keep pointers to some additional metadata associated with your virtual allocations in their
pUserData
, don't forget to free them. -
nvmaIsVirtualBlockEmpty
public static int nvmaIsVirtualBlockEmpty(long virtualBlock) Unsafe version of:IsVirtualBlockEmpty
-
vmaIsVirtualBlockEmpty
public static boolean vmaIsVirtualBlockEmpty(long virtualBlock) Returns true of theVmaVirtualBlock
is empty - contains 0 virtual allocations and has all its space available for new allocations. -
nvmaGetVirtualAllocationInfo
public static void nvmaGetVirtualAllocationInfo(long virtualBlock, long allocation, long pVirtualAllocInfo) Unsafe version of:GetVirtualAllocationInfo
-
vmaGetVirtualAllocationInfo
public static void vmaGetVirtualAllocationInfo(long virtualBlock, long allocation, VmaVirtualAllocationInfo pVirtualAllocInfo) Returns information about a specific virtual allocation within a virtual block, like its size andpUserData
pointer. -
nvmaVirtualAllocate
public static int nvmaVirtualAllocate(long virtualBlock, long pCreateInfo, long pAllocation, long pOffset) Unsafe version of:VirtualAllocate
-
vmaVirtualAllocate
public static int vmaVirtualAllocate(long virtualBlock, VmaVirtualAllocationCreateInfo pCreateInfo, PointerBuffer pAllocation, @Nullable LongBuffer pOffset) Allocates new virtual allocation inside givenVmaVirtualBlock
.If the allocation fails due to not enough free space available,
VK_ERROR_OUT_OF_DEVICE_MEMORY
is returned (despite the function doesn't ever allocate actual GPU memory).pAllocation
is then set toVK_NULL_HANDLE
andpOffset
, if not null, it set toUINT64_MAX
.- Parameters:
virtualBlock
- virtual blockpCreateInfo
- parameters for the allocationpOffset
- returned offset of the new allocation. Optional, can be null.
-
nvmaVirtualFree
public static void nvmaVirtualFree(long virtualBlock, long allocation) Unsafe version of:VirtualFree
-
vmaVirtualFree
public static void vmaVirtualFree(long virtualBlock, long allocation) Frees virtual allocation inside givenVmaVirtualBlock
.It is correct to call this function with
allocation == VK_NULL_HANDLE
- it does nothing. -
nvmaClearVirtualBlock
public static void nvmaClearVirtualBlock(long virtualBlock) Unsafe version of:ClearVirtualBlock
-
vmaClearVirtualBlock
public static void vmaClearVirtualBlock(long virtualBlock) Frees all virtual allocations inside givenVmaVirtualBlock
.You must either call this function or free each virtual allocation individually with
VirtualFree
before destroying a virtual block. Otherwise, an assert is called.If you keep pointer to some additional metadata associated with your virtual allocation in its
pUserData
, don't forget to free it as well. -
nvmaSetVirtualAllocationUserData
public static void nvmaSetVirtualAllocationUserData(long virtualBlock, long allocation, long pUserData) Unsafe version of:SetVirtualAllocationUserData
-
vmaSetVirtualAllocationUserData
public static void vmaSetVirtualAllocationUserData(long virtualBlock, long allocation, long pUserData) Changes custom pointer associated with given virtual allocation. -
nvmaGetVirtualBlockStatistics
public static void nvmaGetVirtualBlockStatistics(long virtualBlock, long pStats) Unsafe version of:GetVirtualBlockStatistics
-
vmaGetVirtualBlockStatistics
Calculates and returns statistics about virtual allocations and memory usage in givenVmaVirtualBlock
.This function is fast to call. For more detailed statistics, see
CalculateVirtualBlockStatistics
. -
nvmaCalculateVirtualBlockStatistics
public static void nvmaCalculateVirtualBlockStatistics(long virtualBlock, long pStats) Unsafe version of:CalculateVirtualBlockStatistics
-
vmaCalculateVirtualBlockStatistics
public static void vmaCalculateVirtualBlockStatistics(long virtualBlock, VmaDetailedStatistics pStats) Calculates and returns detailed statistics about virtual allocations and memory usage in givenVmaVirtualBlock
.This function is slow to call. Use for debugging purposes. For less detailed statistics, see
GetVirtualBlockStatistics
. -
nvmaBuildVirtualBlockStatsString
public static void nvmaBuildVirtualBlockStatsString(long virtualBlock, long ppStatsString, int detailedMap) Unsafe version of:BuildVirtualBlockStatsString
-
vmaBuildVirtualBlockStatsString
public static void vmaBuildVirtualBlockStatsString(long virtualBlock, PointerBuffer ppStatsString, boolean detailedMap) Builds and returns a null-terminated string in JSON format with information about givenVmaVirtualBlock
.Returned string must be freed using
FreeVirtualBlockStatsString
.- Parameters:
virtualBlock
- virtual blockppStatsString
- returned stringdetailedMap
- passVK_FALSE
to only obtain statistics as returned byCalculateVirtualBlockStatistics
. PassVK_TRUE
to also obtain full list of allocations and free spaces.
-
nvmaFreeVirtualBlockStatsString
public static void nvmaFreeVirtualBlockStatsString(long virtualBlock, long pStatsString) Unsafe version of:FreeVirtualBlockStatsString
-
vmaFreeVirtualBlockStatsString
Frees a string returned byBuildVirtualBlockStatsString
. -
nvmaBuildStatsString
public static void nvmaBuildStatsString(long allocator, long ppStatsString, int detailedMap) Unsafe version of:BuildStatsString
-
vmaBuildStatsString
public static void vmaBuildStatsString(long allocator, PointerBuffer ppStatsString, boolean detailedMap) Builds and returns statistics as a null-terminated string in JSON format.- Parameters:
ppStatsString
- must be freed usingFreeStatsString
function
-
nvmaFreeStatsString
public static void nvmaFreeStatsString(long allocator, long pStatsString) -
vmaFreeStatsString
-