diff --git a/bin/VulkanSample_Release_2015.exe b/bin/VulkanSample_Release_2015.exe index 1fd8967..ae08c33 100644 Binary files a/bin/VulkanSample_Release_2015.exe and b/bin/VulkanSample_Release_2015.exe differ diff --git a/docs/html/choosing_memory_type.html b/docs/html/choosing_memory_type.html new file mode 100644 index 0000000..60b761b --- /dev/null +++ b/docs/html/choosing_memory_type.html @@ -0,0 +1,103 @@ + + +
+ + + + +
+ Vulkan Memory Allocator
+
+ |
+
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.
+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.
+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.
For example, if you want to create a uniform buffer that will be filled using transfer only once or infrequently and used for rendering every frame, you can do it using following code:
+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:
A memory type is chosen that has all the required flags and as many preferred flags set as possible.
+If you use VmaAllocationCreateInfo::usage, it is just internally converted to a set of required and preferred flags.
+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:
+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.
+This is the complete list of members for VmaAllocationCreateInfo, including all inherited members.
Use VmaAllocationCreateFlagBits enum.
+ + + +uint32_t VmaAllocationCreateInfo::memoryTypeBits | +
Bitmask containing one bit set for every memory type acceptable for this allocation.
+Value 0 is equivalent to UINT32_MAX
- it means any memory type is accepted if it meets other requirements specified by this structure, with no further restrictions on memory type index.
+If pool
is not null, this member is ignored.
Pool that this allocation should be created in.
-Leave VK_NULL_HANDLE
to allocate from general memory.
Leave VK_NULL_HANDLE
to allocate from default pool. If not null, members: usage
, requiredFlags
, preferredFlags
, memoryTypeBits
are ignored.
Flags that preferably should be set in a Memory Type chosen for an allocation.
-Set to 0 if no additional flags are prefered and only requiredFlags
should be used.
-If not 0, it must be a superset or equal to requiredFlags
.
+
Flags that preferably should be set in a memory type chosen for an allocation.
+Set to 0 if no additional flags are prefered.
If pool
is not null, this member is ignored.
pool
is not null, this member is ignored.
Custom general-purpose pointer that will be stored in VmaAllocation, can be read as VmaAllocationInfo::pUserData and changed using vmaSetAllocationUserData().
+If VMA_ALLOCATION_CREATE_USER_DATA_COPY_STRING_BIT
is used, it must be either null or pointer to a null-terminated string. The string will be then copied to internal buffer, so it doesn't need to be valid after allocation call.
pool
is not null, this member is ignored.
Flags that must be set in a Memory Type chosen for an allocation.
-Leave 0 if you specify requirement via usage.
+
Leave 0 if you specify memory requirements in other way.
If pool
is not null, this member is ignored.
pool
is not null, this member is ignored.
Intended usage of memory.
-Leave VMA_MEMORY_USAGE_UNKNOWN
if you specify requiredFlags
. You can also use both.
+
You can leave VMA_MEMORY_USAGE_UNKNOWN
if you specify memory requirements in other way.
If pool
is not null, this member is ignored.
Enumerator | |
---|---|
VMA_MEMORY_USAGE_UNKNOWN | No intended memory usage specified. Use other members of VmaAllocationCreateInfo to specify your requirements. |
VMA_MEMORY_USAGE_GPU_ONLY | Memory will be used on device only, so faster access from the device is preferred. No need to be mappable on host. + |
VMA_MEMORY_USAGE_GPU_ONLY | Memory will be used on device only, so faster access from the device is preferred. It usually means device-local GPU memory. No need to be mappable on host. Good e.g. for images to be used as attachments, images containing textures to be sampled, buffers used as vertex buffer, index buffer, uniform buffer and majority of other types of resources used by device. You can still do transfers from/to such resource to/from host memory. +The allocation may still end up in |
VMA_MEMORY_USAGE_CPU_ONLY | Memory will be mapped on host. Could be used for transfer to/from device. + |
VMA_MEMORY_USAGE_CPU_ONLY | Memory will be mapped and used on host. It usually means CPU system memory. Could be used for transfer to/from device. Good e.g. for "staging" copy of buffers and images, used as transfer source or destination. Resources created in this pool may still be accessible to the device, but access to them can be slower. Guarantees to be |
VMA_MEMORY_USAGE_CPU_TO_GPU | Memory will be used for frequent (dynamic) updates from host and reads on device (upload). + |
VMA_MEMORY_USAGE_CPU_TO_GPU | Memory will be used for frequent (dynamic) updates from host and reads on device (upload). Good e.g. for vertex buffers or uniform buffers updated every frame. Guarantees to be |
VMA_MEMORY_USAGE_GPU_TO_CPU | Memory will be used for frequent writing on device and readback on host (download). + |
VMA_MEMORY_USAGE_GPU_TO_CPU | Memory will be used for frequent writing on device and readback on host (download). Guarantees to be |
VMA_MEMORY_USAGE_MAX_ENUM |