mirror of
https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator.git
synced 2024-11-22 07:04:34 +00:00
Minor fix in the documentation
This commit is contained in:
parent
b5456bb4e5
commit
ddbd93dcd8
@ -713,7 +713,7 @@ Functions</h2></td></tr>
|
||||
<li>If you use <a class="el" href="#ggaa5846affa1e9da3800e3e78fae2305cca27cde9026a84d34d525777baa41fce6e">VMA_MEMORY_USAGE_AUTO</a> or other <code>VMA_MEMORY_USAGE_AUTO*</code> value, you must use this flag to be able to map the allocation. Otherwise, mapping is incorrect.</li>
|
||||
<li>If you use other value of <a class="el" href="#gaa5846affa1e9da3800e3e78fae2305cc" title="Intended usage of the allocated memory.">VmaMemoryUsage</a>, this flag is ignored and mapping is always possible in memory types that are <code>HOST_VISIBLE</code>. This includes allocations created in <a class="el" href="custom_memory_pools.html">Custom memory pools</a>.</li>
|
||||
</ul>
|
||||
<p>Declares that mapped memory can be read, written, and accessed in random order, so a <code>HOST_CACHED</code> memory type is required. </p>
|
||||
<p>Declares that mapped memory can be read, written, and accessed in random order, so a <code>HOST_CACHED</code> memory type is preferred. </p>
|
||||
</td></tr>
|
||||
<tr><td class="fieldname"><a id="ggad9889c10c798b040d59c92f257cae597a11337f96eacf34c1016c339eac165cad" name="ggad9889c10c798b040d59c92f257cae597a11337f96eacf34c1016c339eac165cad"></a>VMA_ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT </td><td class="fielddoc"><p>Together with <a class="el" href="#ggad9889c10c798b040d59c92f257cae597a9be224df3bfc1cfa06203aed689a30c5">VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT</a> or <a class="el" href="#ggad9889c10c798b040d59c92f257cae597add61238d98e20917b9a06c617763f492">VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT</a>, it says that despite request for host access, a not-<code>HOST_VISIBLE</code> memory type can be selected if it may improve performance.</p>
|
||||
<p>By using this flag, you declare that you will check if the allocation ended up in a <code>HOST_VISIBLE</code> memory type (e.g. using <a class="el" href="#ga571e87dd38e552249b56b1b0b982fad1" title="Given an allocation, returns Property Flags of its memory type.">vmaGetAllocationMemoryProperties()</a>) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data. To prepare for this possibility, don't forget to add appropriate flags like <code>VK_BUFFER_USAGE_TRANSFER_DST_BIT</code>, <code>VK_BUFFER_USAGE_TRANSFER_SRC_BIT</code> to the parameters of created buffer or image. </p>
|
||||
|
@ -626,7 +626,7 @@ typedef enum VmaAllocationCreateFlagBits
|
||||
This includes allocations created in \ref custom_memory_pools.
|
||||
|
||||
Declares that mapped memory can be read, written, and accessed in random order,
|
||||
so a `HOST_CACHED` memory type is required.
|
||||
so a `HOST_CACHED` memory type is preferred.
|
||||
*/
|
||||
VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT = 0x00000800,
|
||||
/**
|
||||
|
Loading…
Reference in New Issue
Block a user