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

Rebuilt the documentation

Browse source
This commit is contained in:
Adam Sawicki 2024-02-13 11:56:59 +01:00
parent 6c296d3c61
commit d802b362c6
22 changed files with 385 additions and 402 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/html/debugging_memory_usage.html
View file

@ -111,7 +111,11 @@ Corruption detection</h1>
</div><!-- fragment --><p>When this feature is enabled, number of bytes specified as <code>VMA_DEBUG_MARGIN</code> (it must be multiply of 4) after every allocation is filled with a magic number. This idea is also know as "canary". Memory is automatically mapped and unmapped if necessary.</p>
<p>This number is validated automatically when the allocation is destroyed. If it is not equal to the expected value, <code>VMA_ASSERT()</code> is executed. It clearly means that either CPU or GPU overwritten the memory outside of boundaries of the allocation, which indicates a serious bug.</p>
<p>You can also explicitly request checking margins of all allocations in all memory blocks that belong to specified memory types by using function <a class="el" href="group__group__alloc.html#ga49329a7f030dafcf82f7b73334c22e98" title="Checks magic number in margins around all allocations in given memory types (in both default and cust...">vmaCheckCorruption()</a>, or in memory blocks that belong to specified custom pool, by using function <a class="el" href="group__group__alloc.html#gad535935619c7a549bf837e1bb0068f89" title="Checks magic number in margins around all allocations in given memory pool in search for corruptions.">vmaCheckPoolCorruption()</a>.</p>
<p>Margin validation (corruption detection) works only for memory types that are <code>HOST_VISIBLE</code> and <code>HOST_COHERENT</code>. </p>
<p>Margin validation (corruption detection) works only for memory types that are <code>HOST_VISIBLE</code> and <code>HOST_COHERENT</code>.</p>
<h1><a class="anchor" id="debugging_memory_usage_leak_detection"></a>
Leak detection features</h1>
<p>At allocation and allocator destruction time VMA checks for unfreed and unmapped blocks using <code>VMA_ASSERT_LEAK()</code>. This macro defaults to an assertion, triggering a typically fatal error in Debug builds, and doing nothing in Release builds. You can provide your own definition of <code>VMA_ASSERT_LEAK()</code> to change this behavior.</p>
<p>At memory block destruction time VMA lists out all unfreed allocations using the <code>VMA_LEAK_LOG_FORMAT()</code> macro, which defaults to <code>VMA_DEBUG_LOG_FORMAT</code>, which in turn defaults to a no-op. If you're having trouble with leaks - for example, the aforementioned assertion triggers, but you don't quite know <em>why</em> -, overriding this macro to print out the the leaking blocks, combined with assigning individual names to allocations using <a class="el" href="group__group__alloc.html#gabe02cbb0cd913b3f125958179f2020fc" title="Sets pName in given allocation to new value.">vmaSetAllocationName()</a>, can greatly aid in fixing them. </p>
</div></div><!-- contents -->
</div><!-- PageDoc -->
<!-- start footer part -->