diff --git a/docs/html/memory_mapping.html b/docs/html/memory_mapping.html index 58da591..f4e37a0 100644 --- a/docs/html/memory_mapping.html +++ b/docs/html/memory_mapping.html @@ -86,7 +86,8 @@ Cache control
It may happen that your allocation ends up in memory that is HOST_VISIBLE
(available for mapping) despite it wasn't explicitly requested. For example, application may work on integrated graphics with unified memory (like Intel) or allocation from video memory might have failed, so the library chose system memory as fallback.
You can detect this case and map such allocation to access its memory on CPU directly, instead of launching a transfer operation. You can even use VMA_ALLOCATION_CREATE_MAPPED_BIT
flag while creating allocations that are not necessarily HOST_VISIBLE
(e.g. using VMA_MEMORY_USAGE_GPU_ONLY
). If the allocation ends up in memory type that is HOST_VISIBLE
, it will be persistently mapped and you can use it directly. If not, the flag is just ignored. Example:
You can detect this case and map such allocation to access its memory on CPU directly, instead of launching a transfer operation. In order to do that: inspect allocInfo.memoryType
, call vmaGetMemoryTypeProperties(), and look for VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
flag in properties of that memory type.
You can even use VMA_ALLOCATION_CREATE_MAPPED_BIT
flag while creating allocations that are not necessarily HOST_VISIBLE
(e.g. using VMA_MEMORY_USAGE_GPU_ONLY
). If the allocation ends up in memory type that is HOST_VISIBLE
, it will be persistently mapped and you can use it directly. If not, the flag is just ignored. Example: