eden-emu/VulkanMemoryAllocator
14
0
Fork 0
mirror of https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator.git synced 2025-05-14 16:58:34 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Minor fix in documentation

Browse source 
Regenerated the documentation using Doxygen 1.9.5.
This commit is contained in:
Adam Sawicki 2022-11-04 17:02:24 +01:00
parent d2767622a6
commit cb5bf6452c
104 changed files with 2474 additions and 1758 deletions
Download patch file Download diff file Expand all files Collapse all files

27
docs/html/usage_patterns.html
View file

@ -1,9 +1,9 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="generator" content="Doxygen 1.9.5"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Vulkan Memory Allocator: Recommended usage patterns</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
@ -29,10 +29,10 @@
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<!-- Generated by Doxygen 1.9.5 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
var searchBox = new SearchBox("searchBox", "search/",'.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
@ -55,9 +55,16 @@ $(function() {
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
<div id="MSearchResults">
<div class="SRPage">
<div id="SRIndex">
<div id="SRResults"></div>
<div class="SRStatus" id="Loading">Loading...</div>
<div class="SRStatus" id="Searching">Searching...</div>
<div class="SRStatus" id="NoMatches">No Matches</div>
</div>
</div>
</div>
</div>
<div id="nav-path" class="navpath">
@ -107,7 +114,7 @@ GPU-only resource</h1>
</div><!-- fragment --><p ><b>Also consider:</b> Consider creating them as dedicated allocations using <a class="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>
<h1><a class="anchor" id="usage_patterns_staging_copy_upload"></a>
Staging copy for upload</h1>
<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>When:</b> A "staging" buffer than you want to map and fill from CPU code, then use as a source of transfer to some GPU resource.</p>
<p ><b>What to do:</b> Use flag <a class="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>
<div class="fragment"><div class="line">VkBufferCreateInfo bufCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO };</div>
<div class="line">bufCreateInfo.size = 65536;</div>
@ -156,7 +163,7 @@ Readback</h1>
<div class="ttc" id="agroup__group__alloc_html_ggad9889c10c798b040d59c92f257cae597add61238d98e20917b9a06c617763f492"><div class="ttname"><a href="group__group__alloc.html#ggad9889c10c798b040d59c92f257cae597add61238d98e20917b9a06c617763f492">VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT</a></div><div class="ttdeci">@ VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT</div><div class="ttdef"><b>Definition:</b> vk_mem_alloc.h:607</div></div>
</div><!-- fragment --><h1><a class="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>
<p >For resources that you frequently write on CPU via mapped pointer and frequently read on GPU e.g. as a uniform buffer (also called "dynamic"), multiple options are possible:</p>
<ol type="1">
<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 performance 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>
@ -249,7 +256,7 @@ Other use cases</h1>
</div><!-- PageDoc -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
Generated by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.5
</small></address>
</body>
</html>