Vulkan-Docs/doc/specs/vulkan/chapters/memory.txt

// Copyright (c) 2015-2016 The Khronos Group Inc.
// Copyright notice at https://www.khronos.org/registry/speccopyright.html

[[memory]]
= Memory Allocation

Vulkan memory is broken up into two categories, _host memory_ and
_device memory_.


[[memory-host]]
== Host Memory

Host memory is memory needed by the Vulkan implementation for
non-device-visible storage. This storage may: be used for e.g. internal
software structures.

[[memory-allocation]]
Vulkan provides applications the opportunity to perform host memory
allocations on behalf of the Vulkan implementation. If this feature is
not used, the implementation will perform its own memory allocations. Since
most memory allocations are off the critical path, this is not meant as a
performance feature. Rather, this can: be useful for certain embedded
systems, for debugging purposes (e.g. putting a guard page after all host
allocations), or for memory allocation logging.

Allocators are provided by the application as a pointer to a
sname:VkAllocationCallbacks structure:

include::../structs/VkAllocationCallbacks.txt[]

  * pname:pUserData is a value to be interpreted by the implementation of
    the callbacks. When any of the callbacks in sname:VkAllocationCallbacks
    are called, the Vulkan implementation will pass this value as the
    first parameter to the callback. This value can: vary each time an
    allocator is passed into a command, even when the same object takes an
    allocator in multiple commands.
  * pname:pfnAllocation is a pointer to an application-defined memory
    allocation function of type tlink:PFN_vkAllocationFunction.
  * pname:pfnReallocation is a pointer to an application-defined memory
    reallocation function of type tlink:PFN_vkReallocationFunction.
  * pname:pfnFree is a pointer to an application-defined memory free
    function of type tlink:PFN_vkFreeFunction.
  * pname:pfnInternalAllocation is a pointer to an application-defined
    function that is called by the implementation when the implementation
    makes internal allocations, and it is of type
    tlink:PFN_vkInternalAllocationNotification.
  * pname:pfnInternalFree is a pointer to an application-defined function
    that is called by the implementation when the implementation frees
    internal allocations, and it is of type
    tlink:PFN_vkInternalFreeNotification.

include::../validity/structs/VkAllocationCallbacks.txt[]

The type of pname:pfnAllocation is:

include::../funcpointers/PFN_vkAllocationFunction.txt[]

  * pname:pUserData is the value specified for
    slink:VkAllocationCallbacks.pUserData in the allocator specified by the
    application.
  * pname:size is the size in bytes of the requested allocation.
  * pname:alignment is the requested alignment of the allocation in bytes
    and must: be a power of two.
  * pname:allocationScope is a elink:VkSystemAllocationScope value
    specifying the scope of the lifetime of the allocation, as described
    <<memory-host-allocation-scope,here>>.

[[vkAllocationFunction_return_rules]]
If pname:pfnAllocation is unable to allocate the requested memory,
it must: return `NULL`. If the allocation was successful, it must: return a
valid pointer to memory allocation containing at least pname:size bytes, and
with the pointer value being a multiple of pname:alignment.

[NOTE]
.Note
====
Correct Vulkan operation cannot: be assumed if the application doesn't
follow these rules.

For example, pname:pfnAllocation (or pname:pfnReallocation) could cause
termination of running Vulkan instance(s) on a failed allocation for
debugging purposes, either directly or indirectly. In these circumstances,
it cannot: be assumed that any part of any affected VkInstance objects are
going to operate correctly (even flink:vkDestroyInstance), and the
application must: ensure it cleans up properly via other means (e.g.
process termination).
====

If pname:pfnAllocation returns `NULL`, and if the implementation is unable
to continue correct processing of the current command without the requested
allocation, it must: treat this as a run-time error, and generate
ename:VK_ERROR_OUT_OF_HOST_MEMORY at the appropriate time for the command
in which the condition was detected, as described in
<<fundamentals-errorcodes, Return Codes>>.

If the implementation is able to continue correct processing of the current
command without the requested allocation, then it may: do so, and must:
not generate ename:VK_ERROR_OUT_OF_HOST_MEMORY as a result of this failed
allocation.

The type of pname:pfnReallocation is:

include::../funcpointers/PFN_vkReallocationFunction.txt[]

  * pname:pUserData is the value specified for
    slink:VkAllocationCallbacks.pUserData in the allocator specified by the
    application.
  * pname:pOriginal must: be either `NULL` or a pointer previously returned
    by pname:pfnReallocation or pname:pfnAllocation of the same allocator.
  * pname:size is the size in bytes of the requested allocation.
  * pname:alignment is the requested alignment of the allocation in bytes
    and must: be a power of two.
  * pname:allocationScope is a elink:VkSystemAllocationScope value
    specifying the scope of the lifetime of the allocation, as described
    <<memory-host-allocation-scope,here>>.

pname:pfnReallocation must: return an allocation with enough space for
pname:size bytes, and the contents of the original allocation from bytes
zero to latexmath:[$\min(\textrm{original size, new size})-1$] must: be
preserved in the returned allocation. If pname:size is larger than the old
size, the contents of the additional space are undefined. If satisfying
these requirements involves creating a new allocation, then the old
allocation should: be freed.

If pname:pOriginal is `NULL`, then pname:pfnReallocation must: behave
equivalently to a call to tlink:PFN_vkAllocationFunction with the same
parameter values (without pname:pOriginal).

If pname:size is zero, then pname:pfnReallocation must: behave
equivalently to a call to tlink:PFN_vkFreeFunction with the same
pname:pUserData parameter value, and pname:pMemory equal to pname:pOriginal.

If pname:pOriginal is non-`NULL`, the implementation must: ensure that
pname:alignment is equal to the pname:alignment used to originally allocate
pname:pOriginal.

If this function fails and pname:pOriginal is non-`NULL` the application
must: not free the old allocation.

pname:pfnReallocation must: follow the same <<vkAllocationFunction_return_rules,
rules for return values as tname:PFN_vkAllocationFunction>>.

The type of pname:pfnFree is:

include::../funcpointers/PFN_vkFreeFunction.txt[]

  * pname:pUserData is the value specified for
    slink:VkAllocationCallbacks.pUserData in the allocator specified by the
    application.
  * pname:pMemory is the allocation to be freed.

pname:pMemory may: be `NULL`, which the callback must: handle safely. If
pname:pMemory is non-`NULL`, it must: be a pointer previously allocated by
pname:pfnAllocation or pname:pfnReallocation. The application should: free
this memory.

The type of pname:pfnInternalAllocation is:

include::../funcpointers/PFN_vkInternalAllocationNotification.txt[]

  * pname:pUserData is the value specified for
    slink:VkAllocationCallbacks.pUserData in the allocator specified by the
    application.
  * pname:size is the requested size of an allocation.
  * pname:allocationType is the requested type of an allocation.
  * pname:allocationScope is a elink:VkSystemAllocationScope value
    specifying the scope of the lifetime of the allocation, as described
    <<memory-host-allocation-scope,here>>.

This is a purely informational callback.

The type of pname:pfnInternalFree is:

include::../funcpointers/PFN_vkInternalFreeNotification.txt[]

  * pname:pUserData is the value specified for
    slink:VkAllocationCallbacks.pUserData in the allocator specified by the
    application.
  * pname:size is the requested size of an allocation.
  * pname:allocationType is the requested type of an allocation.
  * pname:allocationScope is a elink:VkSystemAllocationScope value
    specifying the scope of the lifetime of the allocation, as described
    <<memory-host-allocation-scope,here>>.

[[memory-host-allocation-scope]]
Each allocation has a _scope_ which defines its lifetime and which object it
is associated with. The scope is provided in the pname:allocationScope
parameter and takes a value of type elink:VkSystemAllocationScope:

include::../enums/VkSystemAllocationScope.txt[]

  * ename:VK_SYSTEM_ALLOCATION_SCOPE_COMMAND - The allocation is scoped to
    the duration of the Vulkan command.
  * ename:VK_SYSTEM_ALLOCATION_SCOPE_OBJECT - The allocation is scoped to
    the lifetime of the Vulkan object that is being created or used.
  * ename:VK_SYSTEM_ALLOCATION_SCOPE_CACHE - The allocation is scoped to the
    lifetime of a sname:VkPipelineCache object.
  * ename:VK_SYSTEM_ALLOCATION_SCOPE_DEVICE - The allocation is scoped to
    the lifetime of the Vulkan device.
  * ename:VK_SYSTEM_ALLOCATION_SCOPE_INSTANCE - The allocation is scoped to
    the lifetime of the Vulkan instance.

Most Vulkan commands operate on a single object, or there is a sole
object that is being created or manipulated. When an allocation uses a scope
of ename:VK_SYSTEM_ALLOCATION_SCOPE_OBJECT or
ename:VK_SYSTEM_ALLOCATION_SCOPE_CACHE, the allocation is scoped to the
object being created or manipulated.

When an implementation requires host memory, it will make callbacks to the
application using the most specific allocator and scope available:

  * If an allocation is scoped to the duration of a command, the allocator
    will use the ename:VK_SYSTEM_ALLOCATION_SCOPE_COMMAND scope. The most
    specific allocator available is used: if the object being created or
    manipulated has an allocator, that object's allocator will be used, else
    if the parent sname:VkDevice has an allocator it will be used, else if
    the parent sname:VkInstance has an allocator it will be used. Else,
  * If an allocation is associated with an object of type
    sname:VkPipelineCache, the allocator will use the
    ename:VK_SYSTEM_ALLOCATION_SCOPE_CACHE scope. The most specific
    allocator available is used (pipeline cache, else device, else
    instance). Else,
  * If an allocation is scoped to the lifetime of an object, that object is
    being created or manipulated by the command, and that object's type is
    not sname:VkDevice or sname:VkInstance, the allocator will use a scope
    of ename:VK_SYSTEM_ALLOCATION_SCOPE_OBJECT. The most specific allocator
    available is used (object, else device, else instance). Else,
  * If an allocation is scoped to the lifetime of a device, the allocator
    will use scope of ename:VK_SYSTEM_ALLOCATION_SCOPE_DEVICE. The most
    specific allocator available is used (device, else instance). Else,
  * If the allocation is scoped to the lifetime of an instance and the
    instance has an allocator, its allocator will be used with a scope of
    ename:VK_SYSTEM_ALLOCATION_SCOPE_INSTANCE.
  * Otherwise an implementation will allocate memory through an alternative
    mechanism that is unspecified.

Objects that are allocated from pools do not specify their own allocator.
When an implementation requires host memory for such an object, that memory
is sourced from the object's parent pool's allocator.

The application is not expected to handle allocating memory that is intended
for execution by the host due to the complexities of differing security
implementations across multiple platforms. The implementation will allocate
such memory internally and invoke an application provided informational
callback when these _internal allocations_ are allocated and freed. Upon
allocation of executable memory, pname:pfnInternalAllocation will be called.
Upon freeing executable memory, pname:pfnInternalFree will be called. An
implementation will only call an informational callback for executable
memory allocations and frees.

The pname:allocationType parameter to the pname:pfnInternalAllocation and
pname:pfnInternalFree functions may: be one of the following values:

include::../enums/VkInternalAllocationType.txt[]

  * ename:VK_INTERNAL_ALLOCATION_TYPE_EXECUTABLE - The allocation is
    intended for execution by the host.

An implementation must: only make calls into an application-provided
allocator from within the scope of an API command. An implementation must:
only make calls into an application-provided allocator from the same thread
that called the provoking API command. The implementation shouldnot:
synchronize calls to any of the callbacks. If synchronization is needed, the
callbacks must: provide it themselves. The informational callbacks are
subject to the same restrictions as the allocation callbacks.

If an implementation intends to make calls through an
sname:VkAllocationCallbacks structure between the time a ftext:vkCreate*
command returns and the time a corresponding ftext:vkDestroy* command
begins, that implementation must: save a copy of the allocator before the
ftext:vkCreate* command returns. The callback functions and any data
structures they rely upon must: remain valid for the lifetime of the object
they are associated with.

If an allocator is provided to a ftext:vkCreate* command, a _compatible_
allocator must: be provided to the corresponding ftext:vkDestroy* command.
Two sname:VkAllocationCallbacks structures are compatible if memory created
with pname:pfnAllocation or pname:pfnReallocation in each can: be freed with
pname:pfnReallocation or pname:pfnFree in the other. An allocator must: not
be provided to a ftext:vkDestroy* command if an allocator was not provided
to the corresponding ftext:vkCreate* command.

If a non-`NULL` allocator is used, the pname:pfnAllocation,
pname:pfnReallocation and pname:pfnFree members must: be non-`NULL` and
point to valid implementations of the callbacks. An application can: choose
to not provide informational callbacks by setting both
pname:pfnInternalAllocation and pname:pfnInternalFree to `NULL`.
pname:pfnInternalAllocation and pname:pfnInternalFree must: either both be
`NULL` or both be non-`NULL`.

If pname:pfnAllocation or pname:pfnReallocation fail, the implementation
may: fail object creation and/or generate an
ename:VK_ERROR_OUT_OF_HOST_MEMORY error, as appropriate.

Allocation callbacks must: not call any Vulkan commands.

The following sets of rules define when an implementation is permitted to
call the allocator callbacks.

pname:pfnAllocation or pname:pfnReallocation may: be called in the following
situations:

  * Host memory scoped to the lifetime of a sname:VkDevice or
    sname:VkInstance may: be allocated from any API command.
  * Host memory scoped to the duration of a command may: be allocated from
    any API command.
  * Host memory scoped to the lifetime of a sname:VkPipelineCache may: only
    be allocated from:
  ** fname:vkCreatePipelineCache
  ** fname:vkMergePipelineCaches for pname:dstCache
  ** fname:vkCreateGraphicsPipelines for pname:pPipelineCache
  ** fname:vkCreateComputePipelines for pname:pPipelineCache
  * Host memory scoped to the lifetime of a sname:VkDescriptorPool may: only
    be allocated from:
  ** any command that takes the pool as a direct argument
  ** fname:vkAllocateDescriptorSets for the pname:descriptorPool member of
    its pname:pAllocateInfo parameter
  ** fname:vkCreateDescriptorPool
  * Host memory scoped to the lifetime of a sname:VkCommandPool may: only be
    allocated from:
  ** any command that takes the pool as a direct argument
  ** fname:vkCreateCommandPool
  ** fname:vkAllocateCommandBuffers for the pname:commandPool member of its
     pname:pAllocateInfo parameter
  ** any ftext:vkCmd* command whose pname:commandBuffer was created from
     that sname:VkCommandPool
  * Host memory scoped to the lifetime of any other object may: only be
    allocated in that object's ftext:vkCreate* command.

pname:pfnFree may: be called in the following situations:

  * Host memory scoped to the lifetime of a sname:VkDevice or
    sname:VkInstance may: be freed from any API command.
  * Host memory scoped to the duration of a command must: be freed by any
    API command which allocates such memory.
  * Host memory scoped to the lifetime of a sname:VkPipelineCache may: be
    freed from fname:vkDestroyPipelineCache.
  * Host memory scoped to the lifetime of a sname:VkDescriptorPool may: be
    freed from
  ** any command that takes the pool as a direct argument
  * Host memory scoped to the lifetime of a sname:VkCommandPool may: be
    freed from:
  ** any command that takes the pool as a direct argument
  ** fname:vkResetCommandBuffer whose pname:commandBuffer was created from
     that sname:VkCommandPool
  * Host memory scoped to the lifetime of any other object may: be freed in
    that object's ftext:vkDestroy* command.
  * Any command that allocates host memory may: also free host memory of the
    same scope.


[[memory-device]]
== Device Memory

Device memory is memory that is visible to the device, for example the
contents of opaque images that can: be natively used by the device, or
uniform buffer objects that reside in on-device memory.

The memory properties of the physical device describe the memory heaps and
memory types available to a physical device. These can: be queried by
calling:

include::../protos/vkGetPhysicalDeviceMemoryProperties.txt[]

  * pname:physicalDevice is the handle to the device to query.
  * pname:pMemoryProperties points to an instance of
    sname:VkPhysicalDeviceMemoryProperties structure in which the properties
    are returned.

include::../validity/protos/vkGetPhysicalDeviceMemoryProperties.txt[]

The sname:VkPhysicalDeviceMemoryProperties structure is defined as:

include::../structs/VkPhysicalDeviceMemoryProperties.txt[]

ifdef::editing-notes[]
[NOTE]
.editing-note
====
TODO (Jon) - Need to restructure description like other structures.
====
endif::editing-notes[]

include::../validity/structs/VkPhysicalDeviceMemoryProperties.txt[]

The sname:VkPhysicalDeviceMemoryProperties structure describes a number of
_memory heaps_ as well as a number of _memory types_ that can: be used to
access memory allocated in those heaps. Each heap describes a memory
resource of a particular size, and each memory type describes a set of
memory properties (e.g. host cached vs uncached) that can: be used with a
given memory heap. Allocations using a particular memory type will consume
resources from the heap indicated by that memory type's heap index. More
than one memory type may: share each heap, and the heaps and memory types
provide a mechanism to advertise an accurate size of the physical memory
resources while allowing the memory to be used with a variety of different
properties.

The number of memory heaps is given by pname:memoryHeapCount and is less
than or equal to ename:VK_MAX_MEMORY_HEAPS. Each heap is described by an
element of the pname:memoryHeaps array, as a sname:VkMemoryHeap structure.
The number of memory types available across all memory heaps is given by
pname:memoryTypeCount and is less than or equal to
ename:VK_MAX_MEMORY_TYPES. Each memory type is described by an element of
the pname:memoryTypes array, as a sname:VkMemoryType structure.

The sname:VkMemoryHeap structure is defined as:

include::../structs/VkMemoryHeap.txt[]

  * pname:size is the total memory size in bytes in the heap.
  * pname:flags is a bitmask of attribute flags for the heap. The bits
    specified in pname:flags are:
+
include::../enums/VkMemoryHeapFlagBits.txt[]

  ** if pname:flags contains ename:VK_MEMORY_HEAP_DEVICE_LOCAL_BIT, it means
     the heap corresponds to device local memory. Device local memory may:
     have different performance characteristics than host local memory, and
     may: support different memory property flags.

include::../validity/structs/VkMemoryHeap.txt[]

At least one heap must: include ename:VK_MEMORY_HEAP_DEVICE_LOCAL_BIT in
pname:flags. If there are multiple heaps that all have similar performance
characteristics, they may: all include ename:VK_MEMORY_HEAP_DEVICE_LOCAL_BIT.
In a unified memory architecture (UMA) system, there is often only a single
memory heap which is considered to be equally ``local'' to the host and to the
device, and such an implementation must: advertise the heap as device-local.

The sname:VkMemoryType structure is defined as:

include::../structs/VkMemoryType.txt[]

  * pname:heapIndex describes which memory heap this memory type
    corresponds to, and must: be less than pname:memoryHeapCount from the
    sname:VkPhysicalDeviceMemoryProperties structure.
  * pname:propertyFlags is a bitmask of properties for this memory type. The
    bits specified in pname:propertyFlags are:
+
include::../enums/VkMemoryPropertyFlagBits.txt[]

  ** if pname:propertyFlags has the
     ename:VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT bit set, memory allocated
     with this type is the most efficient for device access. This property
     will only be set for memory types belonging to heaps with the
     ename:VK_MEMORY_HEAP_DEVICE_LOCAL_BIT set.
  ** if pname:propertyFlags has the
     ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT bit set, memory allocated
     with this type can: be mapped using flink:vkMapMemory so that it can:
     be accessed on the host.
  ** if pname:propertyFlags has the
     ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT bit set, host cache
     management commands fname:vkFlushMappedMemoryRanges and
     fname:vkInvalidateMappedMemoryRanges are not needed to make host writes
     visible to the device or device writes visible to the host,
     respectively.
  ** if pname:propertyFlags has the
     ename:VK_MEMORY_PROPERTY_HOST_CACHED_BIT bit set, memory allocated
     with this type is cached on the host. Host memory accesses to
     uncached memory are slower than to cached memory, however uncached
     memory is always host coherent.
  ** if pname:propertyFlags has the
     ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT bit set, the memory type
     only allows device access to the memory. Memory types must: not have
     both ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT and
     ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT set. Additionally,
     the object's backing memory may: be provided by the implementation
     lazily as specified in <<memory-device-lazy_allocation, Lazily
     Allocated Memory>>.

include::../validity/structs/VkMemoryType.txt[]

Each memory type returned by flink:vkGetPhysicalDeviceMemoryProperties must:
have its pname:propertyFlags set to one of the following values:

  * 0
  * ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
  * ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | ename:VK_MEMORY_PROPERTY_HOST_CACHED_BIT
  * ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | ename:VK_MEMORY_PROPERTY_HOST_CACHED_BIT | ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
  * ename:VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
  * ename:VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
  * ename:VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | ename:VK_MEMORY_PROPERTY_HOST_CACHED_BIT
  * ename:VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | ename:VK_MEMORY_PROPERTY_HOST_CACHED_BIT | ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
  * ename:VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT

There must: be at least one memory type with both the
ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT and
ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT bits set in its pname:propertyFlags.
There must: be at least one memory type with the
ename:VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT bit set in its pname:propertyFlags.

The memory types are sorted according to a preorder which serves to aid
in easily selecting an appropriate memory type. Given two memory types X and
Y, the preorder defines latexmath:[$X \leq Y$] if:

  * the memory property bits set for X are a strict subset of the memory
    property bits set for Y. Or,
  * the memory property bits set for X are the same as the memory property
    bits set for Y, and X uses a memory heap with greater or equal
    performance (as determined in an implementation-specific manner).

Memory types are ordered in the list such that X is assigned a lesser
pname:memoryTypeIndex than Y if latexmath:[$X \leq Y \land \neg(Y \leq X)$] according to the
preorder. Note that the list of all allowed memory property flag
combinations above satisfies this preorder, but other orders would as
well. The goal of this ordering is to enable applications to use a simple
search loop in selecting the proper memory type, along the lines of:

[source,{basebackend@docbook:c++:cpp}]
---------------------------------------------------
// Find a memory type in "memoryTypeBits" that includes all of "properties"
int32_t FindProperties(uint32_t memoryTypeBits, VkMemoryPropertyFlags properties)
{
    for (int32_t i = 0; i < memoryTypeCount; ++i)
    {
        if ((memoryTypeBits & (1 << i)) &&
            ((memoryTypes[i].propertyFlags & properties) == properties))
            return i;
    }
    return -1;
}

// Try to find an optimal memory type, or if it does not exist
// find any compatible memory type
VkMemoryRequirements memoryRequirements;
vkGetImageMemoryRequirements(device, image, &memoryRequirements);
int32_t memoryType = FindProperties(memoryRequirements.memoryTypeBits, optimalProperties);
if (memoryType == -1)
    memoryType = FindProperties(memoryRequirements.memoryTypeBits, requiredProperties);
---------------------------------------------------

The loop will find the first supported memory type that has all bits requested in
code:properties set. If there is no exact match, it will find a closest
match (i.e. a memory type with the fewest additional bits set), which has
some additional bits set but which are not detrimental to the behaviors
requested by code:properties. The application can: first search for the optimal
properties, e.g. a memory type that is device-local or supports coherent cached
accesses, as appropriate for the intended usage, and if such a memory type is
not present can: fallback to searching for a less optimal but guaranteed set of
properties such as "0" or "host-visible and coherent".

A Vulkan device operates on data in device memory via memory objects that
are represented in the API by a sname:VkDeviceMemory handle. Memory objects
are allocated by calling fname:vkAllocateMemory:

include::../protos/vkAllocateMemory.txt[]

  * pname:device is the logical device that owns the memory.
  * pname:pAllocateInfo is a pointer to an instance of the
    slink:VkMemoryAllocateInfo structure describing parameters of the
    allocation. A successful returned allocation must: use the requested
    parameters -- no substitution is permitted by the implementation.
  * pname:pAllocator controls host memory allocation as described in
    the <<memory-allocation, Memory Allocation>> chapter.
  * pname:pMemory is a pointer to a sname:VkDeviceMemory handle in which
    information about the allocated memory is returned.

include::../validity/protos/vkAllocateMemory.txt[]

The sname:VkMemoryAllocateInfo structure is defined as:

include::../structs/VkMemoryAllocateInfo.txt[]

  * pname:sType is the type of this structure.
  * pname:pNext is `NULL` or a pointer to an extension-specific structure.
  * pname:allocationSize is the size of the allocation in bytes
  * pname:memoryTypeIndex is the memory type index, which selects the
    properties of the memory to be allocated, as well as the heap the memory
    will come from.

include::../validity/structs/VkMemoryAllocateInfo.txt[]

Allocations returned by fname:vkAllocateMemory are guaranteed to meet any
alignment requirement by the implementation. For example, if an
implementation requires 128 byte alignment for images and 64 byte alignment
for buffers, the device memory returned through this mechanism would be
128-byte aligned. This ensures that applications can: correctly suballocate
objects of different types (with potentially different alignment
requirements) in the same memory object.

When memory is allocated, its contents are undefined.

There is an implementation-dependent maximum number of memory allocations
which can: be simultaneously created on a device. This is specified by the
<<features-limits-maxMemoryAllocationCount,pname:maxMemoryAllocationCount>>
member of the sname:VkPhysicalDeviceLimits structure. If
pname:maxMemoryAllocationCount is exceeded, fname:vkAllocateMemory will
return ename:VK_ERROR_TOO_MANY_OBJECTS.

[NOTE]
.Note
====
Some platforms may: have a limit on the maximum size of a single allocation.
For example, certain systems may: fail to create allocations with a size
greater than or equal to 4GB. Such a limit is implementation-dependent, and
if such a failure occurs then the error ename:VK_ERROR_OUT_OF_DEVICE_MEMORY
should: be returned.
====

A memory object is freed by calling:

include::../protos/vkFreeMemory.txt[]

  * pname:device is the logical device that owns the memory.
  * pname:memory is the sname:VkDeviceMemory object to be freed.
  * pname:pAllocator controls host memory allocation as described in
    the <<memory-allocation, Memory Allocation>> chapter.

include::../validity/protos/vkFreeMemory.txt[]

Before freeing a memory object, an application must: ensure the
memory object is no longer in use by the device--for example by command
buffers queued for execution. The memory can: remain bound to images or
buffers at the time the memory object is freed, but any further use of them
(on host or device) for anything other than destroying those objects will
result in undefined behavior. If there are still any bound images or
buffers, the memory may: not be immediately released by the implementation,
but must: be released by the time all bound images and buffers have been
destroyed. Once memory is released, it is returned to the heap from which it
was allocated.

How memory objects are bound to Images and Buffers is described in detail in
the <<resources-association, Resource Memory Association>> section.

If a memory object is mapped at the time it is freed, it is implicitly
unmapped.

[[memory-device-hostaccess]]
=== Host Access to Device Memory Objects

Memory objects created with fname:vkAllocateMemory are not directly host
accessible.

Memory objects created with the memory property
ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT are considered _mappable_. Memory
objects must: be mappable in order to be successfully mapped on the host. An
application retrieves a host virtual address pointer to a region of a
mappable memory object by calling:

include::../protos/vkMapMemory.txt[]

  * pname:device is the logical device that owns the memory.
  * pname:memory is the sname:VkDeviceMemory object to be mapped.
  * pname:offset is a zero-based byte offset from the beginning of the
    memory object.
  * pname:size is the size of the memory range to map, or
    ename:VK_WHOLE_SIZE to map from pname:offset to the end of the
    allocation.
  * pname:flags is reserved for future use, and must: be zero.
  * pname:ppData points to a pointer in which is returned a host-accessible
    pointer to the beginning of the mapped range. This pointer minus
    pname:offset must: be aligned to at least
    sname:VkPhysicalDeviceLimits::pname:minMemoryMapAlignment.

include::../validity/protos/vkMapMemory.txt[]

It is an application error to call fname:vkMapMemory on a memory object that
is already mapped.

[[memory-device-hostaccess-hazards]]
fname:vkMapMemory does not check whether the device memory is currently in
use before returning the host-accessible pointer. The application
must: guarantee that any previously submitted command that writes to this
range has completed before the host reads from or writes to that
range, and that any previously submitted command that reads from that
range has completed before the host writes to that region (see
<<synchronization-fences-devicewrites, here>>
for details on fulfilling such a guarantee). If the device memory was
allocated without the ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT set,
these guarantees must: be made for an extended range: the application
must: round down the start of the range to the nearest multiple of
sname:VkPhysicalDeviceLimits::pname:nonCoherentAtomSize, and round the end
of the range up to the nearest multiple of
sname:VkPhysicalDeviceLimits::pname:nonCoherentAtomSize.

While a range of device memory is mapped for host access, the application
is responsible for synchronizing both device and host access to that memory
range.

[NOTE]
.Note
====
It is important for the application developer to become meticulously
familiar with all of the mechanisms described in the chapter on
<<synchronization, Synchronization and Cache Control>> as they are crucial
to maintaining memory access ordering.
====

Two commands are provided to enable applications to work with
non-coherent memory allocations: fname:vkFlushMappedMemoryRanges and
fname:vkInvalidateMappedMemoryRanges.

To flush ranges of non-coherent memory from the host caches, call:

include::../protos/vkFlushMappedMemoryRanges.txt[]

  * pname:device is the logical device that owns the memory ranges.
  * pname:memoryRangeCount is the length of the pname:pMemoryRanges array.
  * pname:pMemoryRanges is a pointer to an array of
    slink:VkMappedMemoryRange structures describing the memory ranges to
    flush.

include::../validity/protos/vkFlushMappedMemoryRanges.txt[]

fname:vkFlushMappedMemoryRanges must: be used to guarantee that host writes to
non-coherent memory are visible to the device. It must: be called after the host
writes to non-coherent memory have completed and before command buffers that will
read or write any of those memory locations are submitted to a queue.

To invalidate ranges of non-coherent memory from the host caches, call:

include::../protos/vkInvalidateMappedMemoryRanges.txt[]

  * pname:device is the logical device that owns the memory ranges.
  * pname:memoryRangeCount is the length of the pname:pMemoryRanges array.
  * pname:pMemoryRanges is a pointer to an array of
    slink:VkMappedMemoryRange structures describing the memory ranges to
    invalidate.

include::../validity/protos/vkInvalidateMappedMemoryRanges.txt[]

The sname:VkMappedMemoryRange structure is defined as:

include::../structs/VkMappedMemoryRange.txt[]

  * pname:sType is the type of this structure.
  * pname:pNext is `NULL` or a pointer to an extension-specific structure.
  * pname:memory is the memory object to which this range belongs.
  * pname:offset is the zero-based byte offset from the beginning of the
    memory object.
  * pname:size is either the size of range, or ename:VK_WHOLE_SIZE to affect
    the range from pname:offset to the end of the current mapping of the
    allocation.

include::../validity/structs/VkMappedMemoryRange.txt[]

[NOTE]
.Note
====
If the memory object was created with the
ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT set,
fname:vkFlushMappedMemoryRanges and fname:vkInvalidateMappedMemoryRanges are
unnecessary and may: have performance cost.
====

fname:vkInvalidateMappedMemoryRanges must: be used to guarantee that device writes to
non-coherent memory are visible to the host. It must: be called after command buffers
that execute and flush (via memory barriers) the device writes have completed, and
before the host will read or write any of those locations. If a range of non-coherent
memory is written by the host and then invalidated without first being flushed, its
contents are undefined.

ifdef::editing-notes[]
[NOTE]
.editing-note
====
TODO (Tobias) - There's a circular section reference between this next section
and the <<synchronization-fences-devicewrites,synchronization section>>. The
information is all covered by both places, but it seems a bit weird to have them
reference each other. Not sure how to resolve it.
====
endif::editing-notes[]

Host-visible memory types that advertise the
ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT property still require
<<synchronization-pipeline-barriers,memory barriers>> between host and device
in order to be coherent, but do not require additional cache management
operations to achieve coherency. For host writes to
be seen by subsequent command buffer operations, a pipeline barrier from
a source of ename:VK_ACCESS_HOST_WRITE_BIT and ename:VK_PIPELINE_STAGE_HOST_BIT
to a destination of the relevant device pipeline stages and access types must:
be performed. Note that such a barrier is performed
<<synchronization-implicit-ordering-hostwrites,implicitly>> upon each
command buffer submission, so an explicit barrier is only rarely needed
(e.g. if a command buffer waits upon an event signaled by the host, where
the host wrote some data after submission). For device writes to be seen by
subsequent host reads, a pipeline barrier is required: to
<<synchronization-fences-devicewrites,make the writes visible>>.

Once host access to a memory object is no longer needed by the application,
it can: be unmapped by calling:

include::../protos/vkUnmapMemory.txt[]

  * pname:device is the logical device that owns the memory.
  * pname:memory is the memory object to be unmapped.

include::../validity/protos/vkUnmapMemory.txt[]


[[memory-device-lazy_allocation]]
=== Lazily Allocated Memory

If the memory object is allocated from a heap with the
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT bit set, that object's backing
memory may: be provided by the implementation lazily. The actual committed
size of the memory may: initially be as small as zero (or as large as the
requested size), and monotonically increases as additional memory is
needed.

A memory type with this flag set is only allowed to be bound to a
sname:VkImage whose usage flags include
ename:VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT.

[NOTE]
.Note
====
Using lazily allocated memory objects for framebuffer attachments that
are not needed once a render pass instance has completed may: allow some
implementations to never allocate memory for such attachments.
====

Determining the amount of lazily-allocated memory that is currently
committed for a memory object is achieved by calling:

include::../protos/vkGetDeviceMemoryCommitment.txt[]

  * pname:device is the logical device that owns the memory.
  * pname:memory is the memory object being queried.
  * pname:pCommittedMemoryInBytes is a pointer to a basetype:VkDeviceSize
    value in which the number of bytes currently committed is returned, on
    success.

include::../validity/protos/vkGetDeviceMemoryCommitment.txt[]

The implementation may: update the commitment at any time, and the
value returned by this query may: be out of date.

The implementation guarantees to allocate any committed memory from the
heapIndex indicated by the memory type that the memory object was created
with.