Vulkan Memory Allocator
|
Vulkan Memory Allocator comes in form of a "stb-style" single header file. While you can pull the entire repository e.g. as Git module, there is also Cmake script provided, you don't need to build it as a separate library project. You can add file "vk_mem_alloc.h" directly to your project and submit it to code repository next to your other source files.
"Single header" doesn't mean that everything is contained in C/C++ declarations, like it tends to be in case of inline functions or C++ templates. It means that implementation is bundled with interface in a single file and needs to be extracted using preprocessor macro. If you don't do it properly, it will result in linker errors.
To do it properly:
It may be a good idea to create dedicated CPP file just for this purpose, e.g. "VmaUsage.cpp".
This library includes header <vulkan/vulkan.h>
, which in turn includes <windows.h>
on Windows. If you need some specific macros defined before including these headers (like WIN32_LEAN_AND_MEAN
or WINVER
for Windows, VK_USE_PLATFORM_WIN32_KHR
for Vulkan), you must define them before every #include
of this library. It may be a good idea to create a dedicate header file for this purpose, e.g. "VmaUsage.h", that will be included in other source files instead of VMA header directly.
This library is written in C++, but has C-compatible interface. Thus, you can include and use "vk_mem_alloc.h" in C or C++ code, but full implementation with VMA_IMPLEMENTATION
macro must be compiled as C++, NOT as C. Some features of C++14 are used and required. Features of C++20 are used optionally when available. Some headers of standard C and C++ library are used, but STL containers, RTTI, or C++ exceptions are not used.
VMA offers library interface in a style similar to Vulkan, with object handles like VmaAllocation, structures describing parameters of objects to be created like VmaAllocationCreateInfo, and errors codes returned from functions using VkResult
type.
The first and the main object that needs to be created is VmaAllocator. It represents the initialization of the entire library. Only one such object should be created per VkDevice
. You should create it at program startup, after VkDevice
was created, and before any device memory allocator needs to be made. It must be destroyed before VkDevice
is destroyed.
At program startup:
VkInstance
, VkPhysicalDevice
, VkDevice
object.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. Otherwise, VMA would use only features of Vulkan 1.0 core with no extensions. See below for details.
VMA supports Vulkan version down to 1.0, for backward compatibility. If you want to use higher version, you need to inform the library about it. This is a two-step process.
Step 1: Compile time. By default, VMA compiles with code supporting the highest Vulkan version found in the included <vulkan/vulkan.h>
that is also supported by the library. If this is OK, you don't need to do anything. However, if you want to compile VMA as if only some lower Vulkan version was available, define macro VMA_VULKAN_VERSION
before every #include "vk_mem_alloc.h"
. It should have decimal numeric value in form of ABBBCCC, where A = major, BBB = minor, CCC = patch Vulkan version. For example, to compile against Vulkan 1.2:
Step 2: Runtime. Even when compiled with higher Vulkan version available, VMA can use only features of a lower version, which is configurable during creation of the VmaAllocator object. By default, only Vulkan 1.0 is used. To initialize the allocator with support for higher Vulkan version, you need to set member VmaAllocatorCreateInfo::vulkanApiVersion to an appropriate value, e.g. using constants like VK_API_VERSION_1_2
. See code sample below.
You may need to configure importing Vulkan functions. There are 3 ways to do this:
VMA_STATIC_VULKAN_FUNCTIONS
is defined to 1 by default.vkGetInstanceProcAddr
, vkGetDeviceProcAddr
(this is the option presented in the example below):VMA_STATIC_VULKAN_FUNCTIONS
to 0, VMA_DYNAMIC_VULKAN_FUNCTIONS
to 1.VMA_STATIC_VULKAN_FUNCTIONS
and VMA_DYNAMIC_VULKAN_FUNCTIONS
to 0.VMA can automatically use following Vulkan extensions. If you found them availeble on the selected physical device and you enabled them while creating VkInstance
/ VkDevice
object, inform VMA about their availability by setting appropriate flags in VmaAllocatorCreateInfo::flags.
Vulkan extension | VMA flag |
---|---|
VK_KHR_dedicated_allocation | VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT |
VK_KHR_bind_memory2 | VMA_ALLOCATOR_CREATE_KHR_BIND_MEMORY2_BIT |
VK_KHR_maintenance4 | VMA_ALLOCATOR_CREATE_KHR_MAINTENANCE4_BIT |
VK_KHR_maintenance5 | VMA_ALLOCATOR_CREATE_KHR_MAINTENANCE5_BIT |
VK_EXT_memory_budget | VMA_ALLOCATOR_CREATE_EXT_MEMORY_BUDGET_BIT |
VK_KHR_buffer_device_address | VMA_ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT |
VK_EXT_memory_priority | VMA_ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT |
VK_AMD_device_coherent_memory | VMA_ALLOCATOR_CREATE_AMD_DEVICE_COHERENT_MEMORY_BIT |
Example with fetching pointers to Vulkan functions dynamically:
There are additional configuration options available through preprocessor macros that you can define before including VMA header and through parameters passed in VmaAllocatorCreateInfo. They include a possibility to use your own callbacks for host memory allocations (VkAllocationCallbacks
), callbacks for device memory allocations (instead of vkAllocateMemory
, vkFreeMemory
), or your custom VMA_ASSERT
macro, among others. For more information, see: Configuration.
When you want to create a buffer or image:
VkBufferCreateInfo
/ VkImageCreateInfo
structure.VkBuffer
/VkImage
with memory already allocated and bound to it, plus VmaAllocation objects that represents its underlying memory.Don't forget to destroy your buffer and allocation objects when no longer needed:
If you need to map the buffer, you must set flag VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT or VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT in VmaAllocationCreateInfo::flags. There are many additional parameters that can control the choice of memory type to be used for the allocation and other features. For more information, see documentation chapters: Choosing memory type, Memory mapping.