You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Memory allocation and resource (buffer and image) creation in Vulkan is difficult (comparing to older graphics API-s, like D3D11 or OpenGL) for several reasons:
22
+
Memory allocation and resource (buffer and image) creation in Vulkan is difficult (comparing to older graphics APIs, like D3D11 or OpenGL) for several reasons:
23
23
24
24
- It requires a lot of boilerplate code, just like everything else in Vulkan, because it is a low-level and high-performance API.
25
25
- There is additional level of indirection: `VkDeviceMemory` is allocated separately from creating `VkBuffer`/`VkImage` and they must be bound together.
26
-
- Driver must be queried for supported memory heaps and memory types. Different IHVs provide different types of it.
27
-
- It is recommended practice to allocate bigger chunks of memory and assign parts of them to particular resources.
26
+
- Driver must be queried for supported memory heaps and memory types. Different GPU vendors provide different types of it.
27
+
- It is recommended to allocate bigger chunks of memory and assign parts of them to particular resources, as there is a limit on maximum number of memory blocks that can be allocated.
28
28
29
29
# Features
30
30
@@ -41,8 +41,8 @@ Additional features:
41
41
- Well-documented - description of all functions and structures provided, along with chapters that contain general description and example code.
42
42
- Thread-safety: Library is designed to be used in multithreaded code. Access to a single device memory block referred by different buffers and textures (binding, mapping) is synchronized internally. Memory mapping is reference-counted.
43
43
- Configuration: Fill optional members of `VmaAllocatorCreateInfo` structure to provide custom CPU memory allocator, pointers to Vulkan functions and other parameters.
44
-
- Customization: Predefine appropriate macros to provide your own implementation of all external facilities used by the library like assert, mutex, atomic.
45
-
- Support for memory mapping, reference-counted internally. Support for persistently mapped memory: Just allocate with appropriate flag and you get access to mapped pointer.
44
+
- Customization and integration with custom engines: Predefine appropriate macros to provide your own implementation of all external facilities used by the library like assert, mutex, atomic.
45
+
- Support for memory mapping, reference-counted internally. Support for persistently mapped memory: Just allocate with appropriate flag and access the pointer to already mapped memory.
46
46
- Support for non-coherent memory. Functions that flush/invalidate memory. `nonCoherentAtomSize` is respected automatically.
47
47
- Support for resource aliasing (overlap).
48
48
- Support for sparse binding and sparse residency: Convenience functions that allocate or free multiple memory pages at once.
@@ -56,17 +56,17 @@ Additional features:
56
56
- VK_EXT_memory_priority: Set `priority` of allocations or custom pools and it will be set automatically using this extension.
57
57
- VK_AMD_device_coherent_memory
58
58
- Defragmentation of GPU and CPU memory: Let the library move data around to free some memory blocks and make your allocations better compacted.
59
-
- Statistics: Obtain detailed statistics about the amount of memory used, unused, number of allocated blocks, number of allocations etc. - globally, per memory heap, and per memory type.
60
-
- Debug annotations: Associate string with name or opaque pointer to your own data with every allocation.
61
-
- JSON dump: Obtain a string in JSON format with detailed map of internal state, including list of allocations and gaps between them.
59
+
- Statistics: Obtain brief or detailed statistics about the amount of memory used, unused, number of allocated blocks, number of allocations etc. - globally, per memory heap, and per memory type.
60
+
- Debug annotations: Associate custom `void* pUserData` and debug `char* pName`with each allocation.
61
+
- JSON dump: Obtain a string in JSON format with detailed map of internal state, including list of allocations, their string names, and gaps between them.
62
62
- Convert this JSON dump into a picture to visualize your memory. See [tools/VmaDumpVis](tools/VmaDumpVis/README.md).
63
63
- Debugging incorrect memory usage: Enable initialization of all allocated memory with a bit pattern to detect usage of uninitialized or freed memory. Enable validation of a magic number after every allocation to detect out-of-bounds memory corruption.
64
64
- Support for interoperability with OpenGL.
65
65
- Virtual allocator: Interface for using core allocation algorithm to allocate any custom data, e.g. pieces of one large buffer.
66
66
67
67
# Prequisites
68
68
69
-
- Self-contained C++ library in single header file. No external dependencies other than standard C and C++ library and of course Vulkan. Some features of C++14 used. STL containers or C++ exceptions are not used.
69
+
- Self-contained C++ library in single header file. No external dependencies other than standard C and C++ library and of course Vulkan. Some features of C++14 used. STL containers, RTTI, or C++ exceptions are not used.
70
70
- Public interface in C, in same convention as Vulkan API. Implementation in C++.
71
71
- Error handling implemented by returning `VkResult` error codes - same way as in Vulkan.
72
72
- Interface documented using Doxygen-style comments.
0 commit comments