<divclass="textblock"><p>Vulkan gives great flexibility in memory allocation. This chapter shows the most common patterns.</p>
<p>See also slides from talk: <ahref="https://www.gdcvault.com/play/1025458/Advanced-Graphics-Techniques-Tutorial-New">Sawicki, Adam. Advanced Graphics Techniques Tutorial: Memory management in Vulkan and DX12. Game Developers Conference, 2018</a></p>
<p><b>When:</b> Any resources that you frequently write and read on GPU, e.g. images used as color attachments (aka "render targets"), depth-stencil attachments, images/buffers used as storage image/buffer (aka "Unordered Access View (UAV)").</p>
<divclass="ttc"id="agroup__group__alloc_html_ggad9889c10c798b040d59c92f257cae597a3fc311d855c2ff53f1090ef5c722b38f"><divclass="ttname"><ahref="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597a3fc311d855c2ff53f1090ef5c722b38f">VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT</a></div><divclass="ttdeci">@ VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT</div><divclass="ttdoc">Set this flag if the allocation should have its own memory block.</div><divclass="ttdef"><b>Definition:</b> vk_mem_alloc.h:525</div></div>
<divclass="ttc"id="astruct_vma_allocation_create_info_html"><divclass="ttname"><ahref="struct_vma_allocation_create_info.html">VmaAllocationCreateInfo</a></div><divclass="ttdoc">Parameters of new VmaAllocation.</div><divclass="ttdef"><b>Definition:</b> vk_mem_alloc.h:1219</div></div>
<divclass="ttc"id="astruct_vma_allocation_create_info_html_a983d39e1a2e63649d78a960aa2fdd0f7"><divclass="ttname"><ahref="struct_vma_allocation_create_info.html#a983d39e1a2e63649d78a960aa2fdd0f7">VmaAllocationCreateInfo::priority</a></div><divclass="ttdeci">float priority</div><divclass="ttdoc">A floating-point value between 0 and 1, indicating the priority of the allocation relative to other m...</div><divclass="ttdef"><b>Definition:</b> vk_mem_alloc.h:1265</div></div>
<divclass="ttc"id="astruct_vma_allocation_create_info_html_accb8b06b1f677d858cb9af20705fa910"><divclass="ttname"><ahref="struct_vma_allocation_create_info.html#accb8b06b1f677d858cb9af20705fa910">VmaAllocationCreateInfo::usage</a></div><divclass="ttdeci">VmaMemoryUsage usage</div><divclass="ttdoc">Intended usage of memory.</div><divclass="ttdef"><b>Definition:</b> vk_mem_alloc.h:1227</div></div>
<divclass="ttc"id="astruct_vma_allocation_html"><divclass="ttname"><ahref="struct_vma_allocation.html">VmaAllocation</a></div><divclass="ttdoc">Represents single memory allocation.</div></div>
</div><!-- fragment --><p><b>Also consider:</b> Consider creating them as dedicated allocations using <aclass="el"href="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597a3fc311d855c2ff53f1090ef5c722b38f"title="Set this flag if the allocation should have its own memory block.">VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT</a>, especially if they are large or if you plan to destroy and recreate them with different sizes e.g. when display resolution changes. Prefer to create such resources first and all other GPU resources (like textures and vertex buffers) later. When VK_EXT_memory_priority extension is enabled, it is also worth setting high priority to such allocation to decrease chances to be evicted to system memory by the operating system.</p>
<p><b>When:</b> A "staging" buffer than you want to map and fill from CPU code, then use as a source od transfer to some GPU resource.</p>
<p><b>What to do:</b> Use flag <aclass="el"href="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597a9be224df3bfc1cfa06203aed689a30c5">VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT</a>. Let the library select the optimal memory type, which will always have <code>VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT</code>.</p>
<divclass="ttc"id="agroup__group__alloc_html_ggad9889c10c798b040d59c92f257cae597a11da372cc3a82931c5e5d6146cd9dd1f"><divclass="ttname"><ahref="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597a11da372cc3a82931c5e5d6146cd9dd1f">VMA_ALLOCATION_CREATE_MAPPED_BIT</a></div><divclass="ttdeci">@ VMA_ALLOCATION_CREATE_MAPPED_BIT</div><divclass="ttdoc">Set this flag to use a memory that will be persistently mapped and retrieve pointer to it.</div><divclass="ttdef"><b>Definition:</b> vk_mem_alloc.h:546</div></div>
<divclass="ttc"id="astruct_vma_allocation_info_html"><divclass="ttname"><ahref="struct_vma_allocation_info.html">VmaAllocationInfo</a></div><divclass="ttdoc">Parameters of VmaAllocation objects, that can be retrieved using function vmaGetAllocationInfo().</div><divclass="ttdef"><b>Definition:</b> vk_mem_alloc.h:1334</div></div>
<divclass="ttc"id="astruct_vma_allocation_info_html_a5eeffbe2d2f30f53370ff14aefbadbe2"><divclass="ttname"><ahref="struct_vma_allocation_info.html#a5eeffbe2d2f30f53370ff14aefbadbe2">VmaAllocationInfo::pMappedData</a></div><divclass="ttdeci">void * pMappedData</div><divclass="ttdoc">Pointer to the beginning of this allocation as mapped data.</div><divclass="ttdef"><b>Definition:</b> vk_mem_alloc.h:1376</div></div>
</div><!-- fragment --><p><b>Also consider:</b> You can map the allocation using <aclass="el"href="group__group__alloc.html#gad5bd1243512d099706de88168992f069"title="Maps memory represented by given allocation and returns pointer to it.">vmaMapMemory()</a> or you can create it as persistenly mapped using <aclass="el"href="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597a11da372cc3a82931c5e5d6146cd9dd1f"title="Set this flag to use a memory that will be persistently mapped and retrieve pointer to it.">VMA_ALLOCATION_CREATE_MAPPED_BIT</a>, as in the example above.</p>
<p><b>When:</b> Buffers for data written by or transferred from the GPU that you want to read back on the CPU, e.g. results of some computations.</p>
<p><b>What to do:</b> Use flag <aclass="el"href="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597add61238d98e20917b9a06c617763f492">VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT</a>. Let the library select the optimal memory type, which will always have <code>VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT</code> and <code>VK_MEMORY_PROPERTY_HOST_CACHED_BIT</code>.</p>
</div><!-- fragment --><h1><aclass="anchor"id="usage_patterns_advanced_data_uploading"></a>
Advanced data uploading</h1>
<p>For resources that you frequently write on CPU via mapped pointer and freqnently read on GPU e.g. as a uniform buffer (also called "dynamic"), multiple options are possible:</p>
<li>Easiest solution is to have one copy of the resource in <code>HOST_VISIBLE</code> memory, even if it means system RAM (not <code>DEVICE_LOCAL</code>) on systems with a discrete graphics card, and make the device reach out to that resource directly.<ul>
<li>Reads performed by the device will then go through PCI Express bus. The performace of this access may be limited, but it may be fine depending on the size of this resource (whether it is small enough to quickly end up in GPU cache) and the sparsity of access.</li>
</ul>
</li>
<li>On systems with unified memory (e.g. AMD APU or Intel integrated graphics, mobile chips), a memory type may be available that is both <code>HOST_VISIBLE</code> (available for mapping) and <code>DEVICE_LOCAL</code> (fast to access from the GPU). Then, it is likely the best choice for such type of resource.</li>
<li>Systems with a discrete graphics card and separate video memory may or may not expose a memory type that is both <code>HOST_VISIBLE</code> and <code>DEVICE_LOCAL</code>, also known as Base Address Register (BAR). If they do, it represents a piece of VRAM (or entire VRAM, if ReBAR is enabled in the motherboard BIOS) that is available to CPU for mapping.<ul>
<li>Writes performed by the host to that memory go through PCI Express bus. The performance of these writes may be limited, but it may be fine, especially on PCIe 4.0, as long as rules of using uncached and write-combined memory are followed - only sequential writes and no reads.</li>
</ul>
</li>
<li>Finally, you may need or prefer to create a separate copy of the resource in <code>DEVICE_LOCAL</code> memory, a separate "staging" copy in <code>HOST_VISIBLE</code> memory and perform an explicit transfer command between them.</li>
<p>Thankfully, VMA offers an aid to create and use such resources in the the way optimal for the current Vulkan device. To help the library make the best choice, use flag <aclass="el"href="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597a9be224df3bfc1cfa06203aed689a30c5">VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT</a> together with <aclass="el"href="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597a11337f96eacf34c1016c339eac165cad">VMA_ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT</a>. It will then prefer a memory type that is both <code>DEVICE_LOCAL</code> and <code>HOST_VISIBLE</code> (integrated memory or BAR), but if no such memory type is available or allocation from it fails (PC graphics cards have only 256 MB of BAR by default, unless ReBAR is supported and enabled in BIOS), it will fall back to <code>DEVICE_LOCAL</code> memory for fast GPU access. It is then up to you to detect that the allocation ended up in a memory type that is not <code>HOST_VISIBLE</code>, so you need to create another "staging" allocation and perform explicit transfers.</p>
<li>An image that is used only as transfer source and destination, but it should stay on the device, as it is used to temporarily store a copy of some texture, e.g. from the current to the next frame, for temporal antialiasing or other temporal effects.<ul>
<li>Use <aclass="el"href="struct_vma_allocation_create_info.html#accb8b06b1f677d858cb9af20705fa910"title="Intended usage of memory.">VmaAllocationCreateInfo::usage</a> = <aclass="el"href="group__group__alloc.html#ggaa5846affa1e9da3800e3e78fae2305cca27cde9026a84d34d525777baa41fce6e">VMA_MEMORY_USAGE_AUTO</a></li>
</ul>
</li>
<li>An image that is used only as transfer source and destination, but it should be placed in the system RAM despite it doesn't need to be mapped, because it serves as a "swap" copy to evict least recently used textures from VRAM.<ul>
<li>Use <aclass="el"href="struct_vma_allocation_create_info.html#accb8b06b1f677d858cb9af20705fa910"title="Intended usage of memory.">VmaAllocationCreateInfo::usage</a> = <aclass="el"href="group__group__alloc.html#ggaa5846affa1e9da3800e3e78fae2305cca9b422585242160b8ed3418310ee6664d">VMA_MEMORY_USAGE_AUTO_PREFER_HOST</a>, as VMA needs a hint here to differentiate from the previous case.</li>
</ul>
</li>
<li>A buffer that you want to map and write from the CPU, directly read from the GPU (e.g. as a uniform or vertex buffer), but you have a clear preference to place it in device or host memory due to its large size.<ul>
<li>Use <aclass="el"href="struct_vma_allocation_create_info.html#accb8b06b1f677d858cb9af20705fa910"title="Intended usage of memory.">VmaAllocationCreateInfo::usage</a> = <aclass="el"href="group__group__alloc.html#ggaa5846affa1e9da3800e3e78fae2305ccae2adb696d6a73c18bb20c23666661327">VMA_MEMORY_USAGE_AUTO_PREFER_DEVICE</a> or <aclass="el"href="group__group__alloc.html#ggaa5846affa1e9da3800e3e78fae2305cca9b422585242160b8ed3418310ee6664d">VMA_MEMORY_USAGE_AUTO_PREFER_HOST</a></li>
