Class diagram
Following class diagram shows internal structure of the library:
- All class names have "Vma" prefix, which is omitted on the diagram for clarity.
- Classes shown in blue are part of public interface. They are actually defined as pointer (handle) type using Vulkan-provided macro, e.g.
VK_DEFINE_HANDLE(VmaPool), and implemented as a structure likestruct VmaPool_T. Classes shown in orange are internal and implemented as normal classes, e.g.class VmaDefragmentationAlgorithm. - The diagram doesn't show simple data-only structures used to pass information to and from the library interface (e.g.
VmaAllocationCreateInfo,VmaStats) or used internally (e.g.VmaSuballocation). - The diagram doesn't show basic facilities used internally, e.g.
VmaMutex, data structures likeVmaVectoretc. - The diagram doesn't show classes used only temporarily during some algorithm (e.g.
VmaJsonWriter), only those that are persistent in memory. - This document was created based on VMA version 2.2.0. It may go out-of-sync with the latest code.
Represents the main object of the library initialized for specific VkDevice. It holds all "global" state, owns and should outlive all other objects.
Object optionally owned by VmaAllocator to support recording of library function calls to a CSV file during its whole lifetime.
Represents custom memory pool created explicitly by the user. It's just a thin, public wrapper over internal class VmaBlockVector. A collection of those is owned by VmaAllocator - one for each custom pool. User is responsible for destroying them.
Represents a collection of memory blocks that belong to some "pool".
- Single such object is owned by each
VmaPoolto implement custom pool. - A fixed number "n" of such objects is owned directly by
VmaAllocatorto implement "default pools", one per each memory type available in the Vulkan device.
Represents a single Vulkan memory block. It owns handle to VkDeviceMemory. It also contains reference counter, mutex, and other data needed to manage and protect mapping, binding, and other operations on that block. A set of these objects is owned by VmaBlockVector.
A base, abstract class that represents data structure containing information about the allocations made out of a specific memory block and free space between them, along with algorithm for allocation and deallocation. Contains references to VmaAllocation objects. Single object of this class is owned by each VmaDeviceMemoryBlock.
The main implementation of VmaBlockMetadata that supports the most generic algorithm, used as the default and always used by default pools. It supports all the features (e.g. debug margins, lost allocations). The algorithm is optimized for general cases, when all kinds of Vulkan resources go into a single pool. It is balanced between speed of allocation/deallocation, memory usage, and fragmentation.
Alternative allocation algorithms that can be explicitly requested when creating a custom pool. They have different properties and behavior. They can impose additional limitations on features supported, as well as support some additional features (e.g. double-stack in linear algorithm offers allocation from lower or upper address).
A small object that represents single allocation. It holds data needed to fetch information about the allocation, e.g. VkDeviceMemory block, offset, size, user data. It refers to VkDeviceMemoryBlock if made out of some pool, and to VmaPool if made out of a custom pool.
- Referred by
VmaBlockMetadataif allocation is made out of some pool. - Referred directly by
VmaAllocatorif this is a dedicated allocation.
The root, user-visible object that represents ongoing defragmentation process. Its purpose is mainly to remember data needed until the defragmentation finishes on the GPU, e.g. VkBuffers created temporarily to issue vkCmdCopyBuffer commands.
Represents defragmentation context for a specific pool. Refers to VmaBlockVector and (in case of custom pools) to VmaPool. Cooperates with VmaBlockVector to do actual data movement, whether on CPU or GPU. A collection of these objects is owned by VmaDefragmentationContext - up to "n" for default pools representing Vulkan memory types and up to the number of custom pools that exist.
Abstract base class that represents specific defragmentation algorithm. Implementations must cooperate closely with VmaBlockMetadata of certain kind to update its data structure and contained allocations, but they don't need to move actual data, only return the list of required moves. Single object of this type is owned by each VmaBlockVectorDefragmentationContext.
The main implementation of VmaDefragmentationAlgorithm that supports the most generic algorithm, used by defragmentation as the default. It supports all the features (e.g. non-movable allocations, debug margins, buffer/image granularity). The algorithm is optimized for general cases, when all kinds of Vulkan resources are into a single pool. It uses the main allocation function VmaBlockMetadata::CreateAllocationRequest to find new place for moved allocations.
Alternative defragmentation algorithm which may provide faster defragmentation by going sequentially over allocations and trying to compact them as tightly as possible. It is chosen internally only when certain conditions are met, e.g. there are no non-movable allocations and no chance of buffer/image granularity conflict.