2828<b>Version 3.1.0-development</b>
2929
3030Copyright (c) 2017-2024 Advanced Micro Devices, Inc. All rights reserved. \n
31- License: MIT
31+ License: MIT \n
32+ See also: [product page on GPUOpen](https://gpuopen.com/gaming-product/vulkan-memory-allocator/),
33+ [repository on GitHub](https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator)
3234
33- <b>API documentation divided into groups:</b> [Modules](modules.html)
3435
35- \section main_table_of_contents Table of contents
36+ <b>API documentation divided into groups:</b> [Topics](topics.html)
37+
38+ <b>General documentation chapters:</b>
3639
3740- <b>User guide</b>
3841 - \subpage quick_start
@@ -97,11 +100,6 @@ License: MIT
97100 - [Allocation algorithm](@ref general_considerations_allocation_algorithm)
98101 - [Features not supported](@ref general_considerations_features_not_supported)
99102
100- \section main_see_also See also
101-
102- - [**Product page on GPUOpen**](https://gpuopen.com/gaming-product/vulkan-memory-allocator/)
103- - [**Source repository on GitHub**](https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator)
104-
105103\defgroup group_init Library initialization
106104
107105\brief API elements related to the initialization and management of the entire library, especially #VmaAllocator object.
@@ -16195,13 +16193,14 @@ VMA_CALL_PRE void VMA_CALL_POST vmaFreeVirtualBlockStatsString(VmaVirtualBlock V
1619516193\section quick_start_project_setup Project setup
1619616194
1619716195Vulkan Memory Allocator comes in form of a "stb-style" single header file.
16198- You don't need to build it as a separate library project.
16199- You can add this file directly to your project and submit it to code repository next to your other source files.
16196+ While you can pull the entire repository e.g. as Git module, there is also Cmake script provided,
16197+ you don't need to build it as a separate library project.
16198+ You can add file "vk_mem_alloc.h" directly to your project and submit it to code repository next to your other source files.
1620016199
1620116200"Single header" doesn't mean that everything is contained in C/C++ declarations,
1620216201like it tends to be in case of inline functions or C++ templates.
1620316202It means that implementation is bundled with interface in a single file and needs to be extracted using preprocessor macro.
16204- If you don't do it properly, you will get linker errors.
16203+ If you don't do it properly, it will result in linker errors.
1620516204
1620616205To do it properly:
1620716206
@@ -16215,33 +16214,46 @@ To do it properly:
1621516214#include "vk_mem_alloc.h"
1621616215\endcode
1621716216
16218- It may be a good idea to create dedicated CPP file just for this purpose.
16217+ It may be a good idea to create dedicated CPP file just for this purpose, e.g. "VmaUsage.cpp" .
1621916218
1622016219This library includes header `<vulkan/vulkan.h>`, which in turn
1622116220includes `<windows.h>` on Windows. If you need some specific macros defined
1622216221before including these headers (like `WIN32_LEAN_AND_MEAN` or
1622316222`WINVER` for Windows, `VK_USE_PLATFORM_WIN32_KHR` for Vulkan), you must define
1622416223them before every `#include` of this library.
16224+ It may be a good idea to create a dedicate header file for this purpose, e.g. "VmaUsage.h",
16225+ that will be included in other source files instead of VMA header directly.
1622516226
1622616227This library is written in C++, but has C-compatible interface.
16227- Thus you can include and use vk_mem_alloc.h in C or C++ code, but full
16228+ Thus, you can include and use " vk_mem_alloc.h" in C or C++ code, but full
1622816229implementation with `VMA_IMPLEMENTATION` macro must be compiled as C++, NOT as C.
16229- Some features of C++14 are used. STL containers, RTTI, or C++ exceptions are not used.
16230+ Some features of C++14 are used and required. Features of C++20 are used optionally when available.
16231+ Some headers of standard C and C++ library are used, but STL containers, RTTI, or C++ exceptions are not used.
1623016232
1623116233
1623216234\section quick_start_initialization Initialization
1623316235
16236+ VMA offers library interface in a style similar to Vulkan, with object handles like #VmaAllocation,
16237+ structures describing parameters of objects to be created like #VmaAllocationCreateInfo,
16238+ and errors codes returned from functions using `VkResult` type.
16239+
16240+ The first and the main object that needs to be created is #VmaAllocator.
16241+ It represents the initialization of the entire library.
16242+ Only one such object should be created per `VkDevice`.
16243+ You should create it at program startup, after `VkDevice` was created, and before any device memory allocator needs to be made.
16244+ It must be destroyed before `VkDevice` is destroyed.
16245+
1623416246At program startup:
1623516247
16236- -# Initialize Vulkan to have `VkPhysicalDevice`, `VkDevice` and `VkInstance` object.
16237- -# Fill VmaAllocatorCreateInfo structure and create #VmaAllocator object by
16238- calling vmaCreateAllocator().
16248+ -# Initialize Vulkan to have `VkInstance`, `VkPhysicalDevice`, `VkDevice` object.
16249+ -# Fill VmaAllocatorCreateInfo structure and call vmaCreateAllocator() to create #VmaAllocator object.
1623916250
1624016251Only members `physicalDevice`, `device`, `instance` are required.
1624116252However, you should inform the library which Vulkan version do you use by setting
1624216253VmaAllocatorCreateInfo::vulkanApiVersion and which extensions did you enable
16243- by setting VmaAllocatorCreateInfo::flags (like #VMA_ALLOCATOR_CREATE_BUFFER_DEVICE_ADDRESS_BIT for VK_KHR_buffer_device_address) .
16254+ by setting VmaAllocatorCreateInfo::flags.
1624416255Otherwise, VMA would use only features of Vulkan 1.0 core with no extensions.
16256+ See below for details.
1624516257
1624616258\subsection quick_start_initialization_selecting_vulkan_version Selecting Vulkan version
1624716259
@@ -16326,9 +16338,24 @@ allocatorCreateInfo.pVulkanFunctions = &vulkanFunctions;
1632616338
1632716339VmaAllocator allocator;
1632816340vmaCreateAllocator(&allocatorCreateInfo, &allocator);
16341+
16342+ // Entire program...
16343+
16344+ // At the end, don't forget to:
16345+ vmaDestroyAllocator(allocator);
1632916346\endcode
1633016347
1633116348
16349+ \subsection quick_start_initialization_other_config Other configuration options
16350+
16351+ There are additional configuration options available through preprocessor macros that you can define
16352+ before including VMA header and through parameters passed in #VmaAllocatorCreateInfo.
16353+ They include a possibility to use your own callbacks for host memory allocations (`VkAllocationCallbacks`),
16354+ callbacks for device memory allocations (instead of `vkAllocateMemory`, `vkFreeMemory`),
16355+ or your custom `VMA_ASSERT` macro, among others.
16356+ For more information, see: @ref configuration.
16357+
16358+
1633216359\section quick_start_resource_allocation Resource allocation
1633316360
1633416361When you want to create a buffer or image:
@@ -16351,13 +16378,19 @@ VmaAllocation allocation;
1635116378vmaCreateBuffer(allocator, &bufferInfo, &allocInfo, &buffer, &allocation, nullptr);
1635216379\endcode
1635316380
16354- Don't forget to destroy your objects when no longer needed:
16381+ Don't forget to destroy your buffer and allocation objects when no longer needed:
1635516382
1635616383\code
1635716384vmaDestroyBuffer(allocator, buffer, allocation);
16358- vmaDestroyAllocator(allocator);
1635916385\endcode
1636016386
16387+ If you need to map the buffer, you must set flag
16388+ #VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT or #VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT
16389+ in VmaAllocationCreateInfo::flags.
16390+ There are many additional parameters that can control the choice of memory type to be used for the allocation
16391+ and other features.
16392+ For more information, see documentation chapters: @ref choosing_memory_type, @ref memory_mapping.
16393+
1636116394
1636216395\page choosing_memory_type Choosing memory type
1636316396
@@ -16380,10 +16413,10 @@ You can also combine multiple methods.
1638016413 vmaAllocateMemoryForBuffer(), vmaAllocateMemoryForImage().
1638116414 For binding you should use functions: vmaBindBufferMemory(), vmaBindImageMemory()
1638216415 or their extended versions: vmaBindBufferMemory2(), vmaBindImageMemory2().
16383- -# **This is the easiest and recommended way to use this library:**
16384- If you want to create a buffer or an image, allocate memory for it and bind
16416+ -# If you want to create a buffer or an image, allocate memory for it, and bind
1638516417 them together, all in one call, you can use function vmaCreateBuffer(),
1638616418 vmaCreateImage().
16419+ <b>This is the easiest and recommended way to use this library!</b>
1638716420
1638816421When using 3. or 4., the library internally queries Vulkan for memory types
1638916422supported for that buffer or image (function `vkGetBufferMemoryRequirements()`)
@@ -16451,6 +16484,7 @@ vmaCreateBuffer(allocator, &stagingBufferInfo, &stagingAllocInfo, &stagingBuffer
1645116484\endcode
1645216485
1645316486For more examples of creating different kinds of resources, see chapter \ref usage_patterns.
16487+ See also: @ref memory_mapping.
1645416488
1645516489Usage values `VMA_MEMORY_USAGE_AUTO*` are legal to use only when the library knows
1645616490about the resource being created by having `VkBufferCreateInfo` / `VkImageCreateInfo` passed,
@@ -16462,7 +16496,7 @@ memory type, as described below.
1646216496Old usage values (`VMA_MEMORY_USAGE_GPU_ONLY`, `VMA_MEMORY_USAGE_CPU_ONLY`,
1646316497`VMA_MEMORY_USAGE_CPU_TO_GPU`, `VMA_MEMORY_USAGE_GPU_TO_CPU`, `VMA_MEMORY_USAGE_CPU_COPY`)
1646416498are still available and work same way as in previous versions of the library
16465- for backward compatibility, but they are not recommended .
16499+ for backward compatibility, but they are deprecated .
1646616500
1646716501\section choosing_memory_type_required_preferred_flags Required and preferred flags
1646816502
@@ -16492,8 +16526,8 @@ plus some extra "magic" (heuristics).
1649216526
1649316527\section choosing_memory_type_explicit_memory_types Explicit memory types
1649416528
16495- If you inspected memory types available on the physical device and you have
16496- a preference for memory types that you want to use, you can fill member
16529+ If you inspected memory types available on the physical device and <b> you have
16530+ a preference for memory types that you want to use</b> , you can fill member
1649716531VmaAllocationCreateInfo::memoryTypeBits. It is a bit mask, where each bit set
1649816532means that a memory type with that index is allowed to be used for the
1649916533allocation. Special value 0, just like `UINT32_MAX`, means there are no
@@ -16515,6 +16549,21 @@ VmaAllocation allocation;
1651516549vmaCreateBuffer(allocator, &bufferInfo, &allocInfo, &buffer, &allocation, nullptr);
1651616550\endcode
1651716551
16552+ You can also use this parameter to <b>exclude some memory types</b>.
16553+ If you inspect memory heaps and types available on the current physical device and
16554+ you determine that for some reason you don't want to use a specific memory type for the allocation,
16555+ you can enable automatic memory type selection but exclude certain memory type or types
16556+ by setting all bits of `memoryTypeBits` to 1 except the ones you choose.
16557+
16558+ \code
16559+ // ...
16560+ uint32_t excludedMemoryTypeIndex = 2;
16561+ VmaAllocationCreateInfo allocInfo = {};
16562+ allocInfo.usage = VMA_MEMORY_USAGE_AUTO;
16563+ allocInfo.memoryTypeBits = ~(1u << excludedMemoryTypeIndex);
16564+ // ...
16565+ \endcode
16566+
1651816567
1651916568\section choosing_memory_type_custom_memory_pools Custom memory pools
1652016569
0 commit comments