12. Resource Creation
Vulkan supports two primary resource types: buffers and images. Resources are views of memory with associated formatting and dimensionality. Buffers are essentially unformatted arrays of bytes whereas images contain format information, can be multidimensional and may have associated metadata.
12.1. Buffers
Buffers represent linear arrays of data which are used for various purposes by binding them to a graphics or compute pipeline via descriptor sets or via certain commands, or by directly specifying them as parameters to certain commands.
Buffers are represented by VkBuffer handles:
// Provided by VK_VERSION_1_0
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkBuffer)To create buffers, call:
// Provided by VK_VERSION_1_0
VkResult vkCreateBuffer(
VkDevice device,
const VkBufferCreateInfo* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkBuffer* pBuffer);-
deviceis the logical device that creates the buffer object. -
pCreateInfois a pointer to a VkBufferCreateInfo structure containing parameters affecting creation of the buffer. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter. -
pBufferis a pointer to a VkBuffer handle in which the resulting buffer object is returned.
The VkBufferCreateInfo structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkBufferCreateInfo {
VkStructureType sType;
const void* pNext;
VkBufferCreateFlags flags;
VkDeviceSize size;
VkBufferUsageFlags usage;
VkSharingMode sharingMode;
uint32_t queueFamilyIndexCount;
const uint32_t* pQueueFamilyIndices;
} VkBufferCreateInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis a bitmask of VkBufferCreateFlagBits specifying additional parameters of the buffer. -
sizeis the size in bytes of the buffer to be created. -
usageis a bitmask of VkBufferUsageFlagBits specifying allowed usages of the buffer. -
sharingModeis a VkSharingMode value specifying the sharing mode of the buffer when it will be accessed by multiple queue families. -
queueFamilyIndexCountis the number of entries in thepQueueFamilyIndicesarray. -
pQueueFamilyIndicesis a pointer to an array of queue families that will access this buffer. It is ignored ifsharingModeis notVK_SHARING_MODE_CONCURRENT.
Bits which can be set in VkBufferCreateInfo::usage, specifying
usage behavior of a buffer, are:
// Provided by VK_VERSION_1_0
typedef enum VkBufferUsageFlagBits {
VK_BUFFER_USAGE_TRANSFER_SRC_BIT = 0x00000001,
VK_BUFFER_USAGE_TRANSFER_DST_BIT = 0x00000002,
VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT = 0x00000004,
VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT = 0x00000008,
VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT = 0x00000010,
VK_BUFFER_USAGE_STORAGE_BUFFER_BIT = 0x00000020,
VK_BUFFER_USAGE_INDEX_BUFFER_BIT = 0x00000040,
VK_BUFFER_USAGE_VERTEX_BUFFER_BIT = 0x00000080,
VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT = 0x00000100,
} VkBufferUsageFlagBits;-
VK_BUFFER_USAGE_TRANSFER_SRC_BITspecifies that the buffer can be used as the source of a transfer command (see the definition ofVK_PIPELINE_STAGE_TRANSFER_BIT). -
VK_BUFFER_USAGE_TRANSFER_DST_BITspecifies that the buffer can be used as the destination of a transfer command. -
VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BITspecifies that the buffer can be used to create aVkBufferViewsuitable for occupying aVkDescriptorSetslot of typeVK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER. -
VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BITspecifies that the buffer can be used to create aVkBufferViewsuitable for occupying aVkDescriptorSetslot of typeVK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER. -
VK_BUFFER_USAGE_UNIFORM_BUFFER_BITspecifies that the buffer can be used in aVkDescriptorBufferInfosuitable for occupying aVkDescriptorSetslot either of typeVK_DESCRIPTOR_TYPE_UNIFORM_BUFFERorVK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC. -
VK_BUFFER_USAGE_STORAGE_BUFFER_BITspecifies that the buffer can be used in aVkDescriptorBufferInfosuitable for occupying aVkDescriptorSetslot either of typeVK_DESCRIPTOR_TYPE_STORAGE_BUFFERorVK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC. -
VK_BUFFER_USAGE_INDEX_BUFFER_BITspecifies that the buffer is suitable for passing as thebufferparameter to vkCmdBindIndexBuffer. -
VK_BUFFER_USAGE_VERTEX_BUFFER_BITspecifies that the buffer is suitable for passing as an element of thepBuffersarray to vkCmdBindVertexBuffers. -
VK_BUFFER_USAGE_INDIRECT_BUFFER_BITspecifies that the buffer is suitable for passing as thebufferparameter to vkCmdDrawIndirect, vkCmdDrawIndexedIndirect, or vkCmdDispatchIndirect.
// Provided by VK_VERSION_1_0
typedef VkFlags VkBufferUsageFlags;VkBufferUsageFlags is a bitmask type for setting a mask of zero or
more VkBufferUsageFlagBits.
Bits which can be set in VkBufferCreateInfo::flags, specifying
additional parameters of a buffer, are:
// Provided by VK_VERSION_1_0
typedef enum VkBufferCreateFlagBits {
VK_BUFFER_CREATE_SPARSE_BINDING_BIT = 0x00000001,
VK_BUFFER_CREATE_SPARSE_RESIDENCY_BIT = 0x00000002,
VK_BUFFER_CREATE_SPARSE_ALIASED_BIT = 0x00000004,
// Provided by VK_VERSION_1_1
VK_BUFFER_CREATE_PROTECTED_BIT = 0x00000008,
} VkBufferCreateFlagBits;-
VK_BUFFER_CREATE_SPARSE_BINDING_BITspecifies that the buffer will be backed using sparse memory binding. -
VK_BUFFER_CREATE_SPARSE_RESIDENCY_BITspecifies that the buffer can be partially backed using sparse memory binding. Buffers created with this flag must also be created with theVK_BUFFER_CREATE_SPARSE_BINDING_BITflag. -
VK_BUFFER_CREATE_SPARSE_ALIASED_BITspecifies that the buffer will be backed using sparse memory binding with memory ranges that might also simultaneously be backing another buffer (or another portion of the same buffer). Buffers created with this flag must also be created with theVK_BUFFER_CREATE_SPARSE_BINDING_BITflag. -
VK_BUFFER_CREATE_PROTECTED_BITspecifies that the buffer is a protected buffer.
See Sparse Resource Features and Physical Device Features for details of the sparse memory features supported on a device.
// Provided by VK_VERSION_1_0
typedef VkFlags VkBufferCreateFlags;VkBufferCreateFlags is a bitmask type for setting a mask of zero or
more VkBufferCreateFlagBits.
To define a set of external memory handle types that may be used as backing
store for a buffer, add a VkExternalMemoryBufferCreateInfo structure
to the pNext chain of the VkBufferCreateInfo structure.
The VkExternalMemoryBufferCreateInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkExternalMemoryBufferCreateInfo {
VkStructureType sType;
const void* pNext;
VkExternalMemoryHandleTypeFlags handleTypes;
} VkExternalMemoryBufferCreateInfo;|
Note
A |
-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
handleTypesis zero, or a bitmask of VkExternalMemoryHandleTypeFlagBits specifying one or more external memory handle types.
To destroy a buffer, call:
// Provided by VK_VERSION_1_0
void vkDestroyBuffer(
VkDevice device,
VkBuffer buffer,
const VkAllocationCallbacks* pAllocator);-
deviceis the logical device that destroys the buffer. -
bufferis the buffer to destroy. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter.
12.2. Buffer Views
A buffer view represents a contiguous range of a buffer and a specific format to be used to interpret the data. Buffer views are used to enable shaders to access buffer contents interpreted as formatted data. In order to create a valid buffer view, the buffer must have been created with at least one of the following usage flags:
-
VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT -
VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT
Buffer views are represented by VkBufferView handles:
// Provided by VK_VERSION_1_0
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkBufferView)To create a buffer view, call:
// Provided by VK_VERSION_1_0
VkResult vkCreateBufferView(
VkDevice device,
const VkBufferViewCreateInfo* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkBufferView* pView);-
deviceis the logical device that creates the buffer view. -
pCreateInfois a pointer to a VkBufferViewCreateInfo structure containing parameters to be used to create the buffer view. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter. -
pViewis a pointer to a VkBufferView handle in which the resulting buffer view object is returned.
The VkBufferViewCreateInfo structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkBufferViewCreateInfo {
VkStructureType sType;
const void* pNext;
VkBufferViewCreateFlags flags;
VkBuffer buffer;
VkFormat format;
VkDeviceSize offset;
VkDeviceSize range;
} VkBufferViewCreateInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis reserved for future use. -
bufferis a VkBuffer on which the view will be created. -
formatis a VkFormat describing the format of the data elements in the buffer. -
offsetis an offset in bytes from the base address of the buffer. Accesses to the buffer view from shaders use addressing that is relative to this starting offset. -
rangeis a size in bytes of the buffer view. Ifrangeis equal toVK_WHOLE_SIZE, the range fromoffsetto the end of the buffer is used. IfVK_WHOLE_SIZEis used and the remaining size of the buffer is not a multiple of the texel block size offormat, the nearest smaller multiple is used.
// Provided by VK_VERSION_1_0
typedef VkFlags VkBufferViewCreateFlags;VkBufferViewCreateFlags is a bitmask type for setting a mask, but is
currently reserved for future use.
To destroy a buffer view, call:
// Provided by VK_VERSION_1_0
void vkDestroyBufferView(
VkDevice device,
VkBufferView bufferView,
const VkAllocationCallbacks* pAllocator);-
deviceis the logical device that destroys the buffer view. -
bufferViewis the buffer view to destroy. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter.
12.3. Images
Images represent multidimensional - up to 3 - arrays of data which can be used for various purposes (e.g. attachments, textures), by binding them to a graphics or compute pipeline via descriptor sets, or by directly specifying them as parameters to certain commands.
Images are represented by VkImage handles:
// Provided by VK_VERSION_1_0
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkImage)To create images, call:
// Provided by VK_VERSION_1_0
VkResult vkCreateImage(
VkDevice device,
const VkImageCreateInfo* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkImage* pImage);-
deviceis the logical device that creates the image. -
pCreateInfois a pointer to a VkImageCreateInfo structure containing parameters to be used to create the image. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter. -
pImageis a pointer to a VkImage handle in which the resulting image object is returned.
The VkImageCreateInfo structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkImageCreateInfo {
VkStructureType sType;
const void* pNext;
VkImageCreateFlags flags;
VkImageType imageType;
VkFormat format;
VkExtent3D extent;
uint32_t mipLevels;
uint32_t arrayLayers;
VkSampleCountFlagBits samples;
VkImageTiling tiling;
VkImageUsageFlags usage;
VkSharingMode sharingMode;
uint32_t queueFamilyIndexCount;
const uint32_t* pQueueFamilyIndices;
VkImageLayout initialLayout;
} VkImageCreateInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis a bitmask of VkImageCreateFlagBits describing additional parameters of the image. -
imageTypeis a VkImageType value specifying the basic dimensionality of the image. Layers in array textures do not count as a dimension for the purposes of the image type. -
formatis a VkFormat describing the format and type of the texel blocks that will be contained in the image. -
extentis a VkExtent3D describing the number of data elements in each dimension of the base level. -
mipLevelsdescribes the number of levels of detail available for minified sampling of the image. -
arrayLayersis the number of layers in the image. -
samplesis a VkSampleCountFlagBits value specifying the number of samples per texel. -
tilingis a VkImageTiling value specifying the tiling arrangement of the texel blocks in memory. -
usageis a bitmask of VkImageUsageFlagBits describing the intended usage of the image. -
sharingModeis a VkSharingMode value specifying the sharing mode of the image when it will be accessed by multiple queue families. -
queueFamilyIndexCountis the number of entries in thepQueueFamilyIndicesarray. -
pQueueFamilyIndicesis a pointer to an array of queue families that will access this image. It is ignored ifsharingModeis notVK_SHARING_MODE_CONCURRENT. -
initialLayoutis a VkImageLayout value specifying the initial VkImageLayout of all image subresources of the image. See Image Layouts.
Images created with tiling equal to VK_IMAGE_TILING_LINEAR have
further restrictions on their limits and capabilities compared to images
created with tiling equal to VK_IMAGE_TILING_OPTIMAL.
Creation of images with tiling VK_IMAGE_TILING_LINEAR may not be
supported unless other parameters meet all of the constraints:
-
imageTypeisVK_IMAGE_TYPE_2D -
formatis not a depth/stencil format -
mipLevelsis 1 -
arrayLayersis 1 -
samplesisVK_SAMPLE_COUNT_1_BIT -
usageonly includesVK_IMAGE_USAGE_TRANSFER_SRC_BITand/orVK_IMAGE_USAGE_TRANSFER_DST_BIT
Images created with a format from one of those listed in
Formats requiring sampler Y′CBCR conversion for VK_IMAGE_ASPECT_COLOR_BIT image views have further restrictions on
their limits and capabilities compared to images created with other formats.
Creation of images with a format requiring
Y′CBCR conversion may not
be supported unless other parameters meet all of the constraints:
-
imageTypeisVK_IMAGE_TYPE_2D -
mipLevelsis 1 -
arrayLayersis 1 -
samplesisVK_SAMPLE_COUNT_1_BIT
Implementations may support additional limits and capabilities beyond those listed above.
To determine the set of valid usage bits for a given format, call
vkGetPhysicalDeviceFormatProperties.
If the size of the resultant image would exceed maxResourceSize, then
vkCreateImage must fail and return
VK_ERROR_OUT_OF_DEVICE_MEMORY.
This failure may occur even when all image creation parameters satisfy
their valid usage requirements.
|
Note
For images created without For images created with |
To define a set of external memory handle types that may be used as backing
store for an image, add a VkExternalMemoryImageCreateInfo structure to
the pNext chain of the VkImageCreateInfo structure.
The VkExternalMemoryImageCreateInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkExternalMemoryImageCreateInfo {
VkStructureType sType;
const void* pNext;
VkExternalMemoryHandleTypeFlags handleTypes;
} VkExternalMemoryImageCreateInfo;|
Note
A |
-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
handleTypesis zero, or a bitmask of VkExternalMemoryHandleTypeFlagBits specifying one or more external memory handle types.
Bits which can be set in
VkImageViewUsageCreateInfo::usage, or
VkImageCreateInfo::usage, specifying intended usage of an image,
are:
// Provided by VK_VERSION_1_0
typedef enum VkImageUsageFlagBits {
VK_IMAGE_USAGE_TRANSFER_SRC_BIT = 0x00000001,
VK_IMAGE_USAGE_TRANSFER_DST_BIT = 0x00000002,
VK_IMAGE_USAGE_SAMPLED_BIT = 0x00000004,
VK_IMAGE_USAGE_STORAGE_BIT = 0x00000008,
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT = 0x00000010,
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT = 0x00000020,
VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT = 0x00000040,
VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT = 0x00000080,
} VkImageUsageFlagBits;-
VK_IMAGE_USAGE_TRANSFER_SRC_BITspecifies that the image can be used as the source of a transfer command. -
VK_IMAGE_USAGE_TRANSFER_DST_BITspecifies that the image can be used as the destination of a transfer command. -
VK_IMAGE_USAGE_SAMPLED_BITspecifies that the image can be used to create aVkImageViewsuitable for occupying aVkDescriptorSetslot either of typeVK_DESCRIPTOR_TYPE_SAMPLED_IMAGEorVK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, and be sampled by a shader. -
VK_IMAGE_USAGE_STORAGE_BITspecifies that the image can be used to create aVkImageViewsuitable for occupying aVkDescriptorSetslot of typeVK_DESCRIPTOR_TYPE_STORAGE_IMAGE. -
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BITspecifies that the image can be used to create aVkImageViewsuitable for use as a color or resolve attachment in aVkFramebuffer. -
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BITspecifies that the image can be used to create aVkImageViewsuitable for use as a depth/stencil attachment in aVkFramebuffer. -
VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BITspecifies that the memory bound to this image will be allocated with theVK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT(see Memory Allocation for more detail). This bit can be set for any image that can be used to create aVkImageViewsuitable for use as a color, resolve, depth/stencil, or input attachment. -
VK_IMAGE_USAGE_INPUT_ATTACHMENT_BITspecifies that the image can be used to create aVkImageViewsuitable for occupyingVkDescriptorSetslot of typeVK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT; be read from a shader as an input attachment; and be used as an input attachment in a framebuffer.
// Provided by VK_VERSION_1_0
typedef VkFlags VkImageUsageFlags;VkImageUsageFlags is a bitmask type for setting a mask of zero or more
VkImageUsageFlagBits.
When creating a VkImageView one of the following
VkImageUsageFlagBits must be set:
-
VK_IMAGE_USAGE_SAMPLED_BIT -
VK_IMAGE_USAGE_STORAGE_BIT -
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT -
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT -
VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT -
VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT
Bits which can be set in VkImageCreateInfo::flags, specifying
additional parameters of an image, are:
// Provided by VK_VERSION_1_0
typedef enum VkImageCreateFlagBits {
VK_IMAGE_CREATE_SPARSE_BINDING_BIT = 0x00000001,
VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT = 0x00000002,
VK_IMAGE_CREATE_SPARSE_ALIASED_BIT = 0x00000004,
VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT = 0x00000008,
VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT = 0x00000010,
// Provided by VK_VERSION_1_1
VK_IMAGE_CREATE_ALIAS_BIT = 0x00000400,
// Provided by VK_VERSION_1_1
VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT = 0x00000040,
// Provided by VK_VERSION_1_1
VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT = 0x00000020,
// Provided by VK_VERSION_1_1
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT = 0x00000080,
// Provided by VK_VERSION_1_1
VK_IMAGE_CREATE_EXTENDED_USAGE_BIT = 0x00000100,
// Provided by VK_VERSION_1_1
VK_IMAGE_CREATE_PROTECTED_BIT = 0x00000800,
// Provided by VK_VERSION_1_1
VK_IMAGE_CREATE_DISJOINT_BIT = 0x00000200,
} VkImageCreateFlagBits;-
VK_IMAGE_CREATE_SPARSE_BINDING_BITspecifies that the image will be backed using sparse memory binding. -
VK_IMAGE_CREATE_SPARSE_RESIDENCY_BITspecifies that the image can be partially backed using sparse memory binding. Images created with this flag must also be created with theVK_IMAGE_CREATE_SPARSE_BINDING_BITflag. -
VK_IMAGE_CREATE_SPARSE_ALIASED_BITspecifies that the image will be backed using sparse memory binding with memory ranges that might also simultaneously be backing another image (or another portion of the same image). Images created with this flag must also be created with theVK_IMAGE_CREATE_SPARSE_BINDING_BITflag. -
VK_IMAGE_CREATE_MUTABLE_FORMAT_BITspecifies that the image can be used to create aVkImageViewwith a different format from the image. For multi-planar formats,VK_IMAGE_CREATE_MUTABLE_FORMAT_BITspecifies that aVkImageViewcan be created of a plane of the image. -
VK_IMAGE_CREATE_CUBE_COMPATIBLE_BITspecifies that the image can be used to create aVkImageViewof typeVK_IMAGE_VIEW_TYPE_CUBEorVK_IMAGE_VIEW_TYPE_CUBE_ARRAY. -
VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BITspecifies that the image can be used to create aVkImageViewof typeVK_IMAGE_VIEW_TYPE_2DorVK_IMAGE_VIEW_TYPE_2D_ARRAY. -
VK_IMAGE_CREATE_PROTECTED_BITspecifies that the image is a protected image. -
VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BITspecifies that the image can be used with a non-zero value of thesplitInstanceBindRegionCountmember of a VkBindImageMemoryDeviceGroupInfo structure passed into vkBindImageMemory2. This flag also has the effect of making the image use the standard sparse image block dimensions. -
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BITspecifies that the image having a compressed format can be used to create aVkImageViewwith an uncompressed format where each texel in the image view corresponds to a compressed texel block of the image. -
VK_IMAGE_CREATE_EXTENDED_USAGE_BITspecifies that the image can be created with usage flags that are not supported for the format the image is created with but are supported for at least one format aVkImageViewcreated from the image can have. -
VK_IMAGE_CREATE_DISJOINT_BITspecifies that an image with a multi-planar format must have each plane separately bound to memory, rather than having a single memory binding for the whole image; the presence of this bit distinguishes a disjoint image from an image without this bit set. -
VK_IMAGE_CREATE_ALIAS_BITspecifies that two images created with the same creation parameters and aliased to the same memory can interpret the contents of the memory consistently with each other, subject to the rules described in the Memory Aliasing section. This flag further specifies that each plane of a disjoint image can share an in-memory non-linear representation with single-plane images, and that a single-plane image can share an in-memory non-linear representation with a plane of a multi-planar disjoint image, according to the rules in Compatible formats of planes of multi-planar formats. If thepNextchain includes a VkExternalMemoryImageCreateInfo structure whosehandleTypesmember is not0, it is as ifVK_IMAGE_CREATE_ALIAS_BITis set.
See Sparse Resource Features and Sparse Physical Device Features for more details.
// Provided by VK_VERSION_1_0
typedef VkFlags VkImageCreateFlags;VkImageCreateFlags is a bitmask type for setting a mask of zero or
more VkImageCreateFlagBits.
Possible values of VkImageCreateInfo::imageType, specifying the
basic dimensionality of an image, are:
// Provided by VK_VERSION_1_0
typedef enum VkImageType {
VK_IMAGE_TYPE_1D = 0,
VK_IMAGE_TYPE_2D = 1,
VK_IMAGE_TYPE_3D = 2,
} VkImageType;-
VK_IMAGE_TYPE_1Dspecifies a one-dimensional image. -
VK_IMAGE_TYPE_2Dspecifies a two-dimensional image. -
VK_IMAGE_TYPE_3Dspecifies a three-dimensional image.
Possible values of VkImageCreateInfo::tiling, specifying the
tiling arrangement of texel blocks in an image, are:
// Provided by VK_VERSION_1_0
typedef enum VkImageTiling {
VK_IMAGE_TILING_OPTIMAL = 0,
VK_IMAGE_TILING_LINEAR = 1,
} VkImageTiling;-
VK_IMAGE_TILING_OPTIMALspecifies optimal tiling (texels are laid out in an implementation-dependent arrangement, for more efficient memory access). -
VK_IMAGE_TILING_LINEARspecifies linear tiling (texels are laid out in memory in row-major order, possibly with some padding on each row).
To query the memory layout of an image subresource, call:
// Provided by VK_VERSION_1_0
void vkGetImageSubresourceLayout(
VkDevice device,
VkImage image,
const VkImageSubresource* pSubresource,
VkSubresourceLayout* pLayout);-
deviceis the logical device that owns the image. -
imageis the image whose layout is being queried. -
pSubresourceis a pointer to a VkImageSubresource structure selecting a specific image for the image subresource. -
pLayoutis a pointer to a VkSubresourceLayout structure in which the layout is returned.
The image must be linear. The returned layout is valid for host access.
If the image’s
format is a multi-planar
format, then vkGetImageSubresourceLayout describes one
plane
of the image.
vkGetImageSubresourceLayout is invariant for the lifetime of a single
image.
The VkImageSubresource structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkImageSubresource {
VkImageAspectFlags aspectMask;
uint32_t mipLevel;
uint32_t arrayLayer;
} VkImageSubresource;-
aspectMaskis a VkImageAspectFlags value selecting the image aspect. -
mipLevelselects the mipmap level. -
arrayLayerselects the array layer.
Information about the layout of the image subresource is returned in a
VkSubresourceLayout structure:
// Provided by VK_VERSION_1_0
typedef struct VkSubresourceLayout {
VkDeviceSize offset;
VkDeviceSize size;
VkDeviceSize rowPitch;
VkDeviceSize arrayPitch;
VkDeviceSize depthPitch;
} VkSubresourceLayout;-
offsetis the byte offset from the start of the image or the plane where the image subresource begins. -
sizeis the size in bytes of the image subresource.sizeincludes any extra memory that is required based onrowPitch. -
rowPitchdescribes the number of bytes between each row of texels in an image. -
arrayPitchdescribes the number of bytes between each array layer of an image. -
depthPitchdescribes the number of bytes between each slice of 3D image.
If the image is linear, then rowPitch,
arrayPitch and depthPitch describe the layout of the image
subresource in linear memory.
For uncompressed formats, rowPitch is the number of bytes between
texels with the same x coordinate in adjacent rows (y coordinates differ by
one).
arrayPitch is the number of bytes between texels with the same x and y
coordinate in adjacent array layers of the image (array layer values differ
by one).
depthPitch is the number of bytes between texels with the same x and y
coordinate in adjacent slices of a 3D image (z coordinates differ by one).
Expressed as an addressing formula, the starting byte of a texel in the
image subresource has address:
// (x,y,z,layer) are in texel coordinates
address(x,y,z,layer) = layer*arrayPitch + z*depthPitch + y*rowPitch + x*elementSize + offsetFor compressed formats, the rowPitch is the number of bytes between
compressed texel blocks in adjacent rows.
arrayPitch is the number of bytes between compressed texel blocks in
adjacent array layers.
depthPitch is the number of bytes between compressed texel blocks in
adjacent slices of a 3D image.
// (x,y,z,layer) are in compressed texel block coordinates
address(x,y,z,layer) = layer*arrayPitch + z*depthPitch + y*rowPitch + x*compressedTexelBlockByteSize + offset;The value of arrayPitch is undefined for images that were not created
as arrays.
depthPitch is defined only for 3D images.
If the image has a
single-plane
color format
, then the aspectMask member of VkImageSubresource must be
VK_IMAGE_ASPECT_COLOR_BIT.
If the image has a depth/stencil format
, then aspectMask must be either VK_IMAGE_ASPECT_DEPTH_BIT or
VK_IMAGE_ASPECT_STENCIL_BIT.
On implementations that store depth and stencil aspects separately, querying
each of these image subresource layouts will return a different offset
and size representing the region of memory used for that aspect.
On implementations that store depth and stencil aspects interleaved, the
same offset and size are returned and represent the interleaved
memory allocation.
If the image has a multi-planar
format
, then the aspectMask member of VkImageSubresource must be
VK_IMAGE_ASPECT_PLANE_0_BIT, VK_IMAGE_ASPECT_PLANE_1_BIT, or
(for 3-plane formats only) VK_IMAGE_ASPECT_PLANE_2_BIT.
Querying each of these image subresource layouts will return a different
offset and size representing the region of memory used for that
plane.
If the image is disjoint, then the offset is relative to the base
address of the plane.
If the image is non-disjoint, then the offset is relative to the
base address of the image.
To destroy an image, call:
// Provided by VK_VERSION_1_0
void vkDestroyImage(
VkDevice device,
VkImage image,
const VkAllocationCallbacks* pAllocator);-
deviceis the logical device that destroys the image. -
imageis the image to destroy. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter.
12.3.1. Image Format Features
Valid uses of a VkImage may depend on the image’s format features, defined below. Such constraints are documented in the affected valid usage statement.
-
If the image was created with
VK_IMAGE_TILING_LINEAR, then its set of format features is the value of VkFormatProperties::linearTilingFeaturesfound by calling vkGetPhysicalDeviceFormatProperties on the sameformatas VkImageCreateInfo::format. -
If the image was created with
VK_IMAGE_TILING_OPTIMAL, then its set of format features is the value of VkFormatProperties::optimalTilingFeaturesfound by calling vkGetPhysicalDeviceFormatProperties on the sameformatas VkImageCreateInfo::format.
12.3.2. Image Miplevel Sizing
A complete mipmap chain is the full set of miplevels, from the largest miplevel provided, down to the minimum miplevel size.
Conventional Images
For conventional images, the dimensions of each successive miplevel, n+1, are:
-
widthn+1 = max(⌊widthn/2⌋, 1) -
heightn+1 = max(⌊heightn/2⌋, 1) -
depthn+1 = max(⌊depthn/2⌋, 1)
where widthn, heightn, and depthn
are the dimensions of the next larger miplevel, n.
The minimum miplevel size is:
-
1 for one-dimensional images,
-
1x1 for two-dimensional images, and
-
1x1x1 for three-dimensional images.
The number of levels in a complete mipmap chain is:
-
⌊log2(max(
width0,height0,depth0))⌋ + 1
where width0, height0, and depth0
are the dimensions of the largest (most detailed) miplevel, 0.
12.4. Image Layouts
Images are stored in implementation-dependent opaque layouts in memory.
Each layout has limitations on what kinds of operations are supported for
image subresources using the layout.
At any given time, the data representing an image subresource in memory
exists in a particular layout which is determined by the most recent layout
transition that was performed on that image subresource.
Applications have control over which layout each image subresource uses, and
can transition an image subresource from one layout to another.
Transitions can happen with an image memory barrier, included as part of a
vkCmdPipelineBarrier or a vkCmdWaitEvents command buffer command
(see Image Memory Barriers), or as part of a subpass
dependency within a render pass (see VkSubpassDependency).
Image layout is per-image subresource.
Separate image subresources of the same image can be in different layouts
at the same time, with the exception that depth and stencil aspects of a
given image subresource can only be in different layouts if the
separateDepthStencilLayouts
feature is enabled.
|
Note
Each layout may offer optimal performance for a specific usage of image
memory.
For example, an image with a layout of
|
Upon creation, all image subresources of an image are initially in the same
layout, where that layout is selected by the
VkImageCreateInfo::initialLayout member.
The initialLayout must be either VK_IMAGE_LAYOUT_UNDEFINED or
VK_IMAGE_LAYOUT_PREINITIALIZED.
If it is VK_IMAGE_LAYOUT_PREINITIALIZED, then the image data can be
preinitialized by the host while using this layout, and the transition away
from this layout will preserve that data.
If it is VK_IMAGE_LAYOUT_UNDEFINED, then the contents of the data are
considered to be undefined, and the transition away from this layout is not
guaranteed to preserve that data.
For either of these initial layouts, any image subresources must be
transitioned to another layout before they are accessed by the device.
Host access to image memory is only well-defined for
linear images and for image subresources of
those images which are currently in either the
VK_IMAGE_LAYOUT_PREINITIALIZED or VK_IMAGE_LAYOUT_GENERAL
layout.
Calling vkGetImageSubresourceLayout for a linear image returns a
subresource layout mapping that is valid for either of those image layouts.
The set of image layouts consists of:
// Provided by VK_VERSION_1_0
typedef enum VkImageLayout {
VK_IMAGE_LAYOUT_UNDEFINED = 0,
VK_IMAGE_LAYOUT_GENERAL = 1,
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL = 2,
VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL = 3,
VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL = 4,
VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL = 5,
VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL = 6,
VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL = 7,
VK_IMAGE_LAYOUT_PREINITIALIZED = 8,
// Provided by VK_VERSION_1_1
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL = 1000117000,
// Provided by VK_VERSION_1_1
VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL = 1000117001,
} VkImageLayout;The type(s) of device access supported by each layout are:
-
VK_IMAGE_LAYOUT_UNDEFINEDspecifies that the layout is unknown. Image memory cannot be transitioned into this layout. This layout can be used as theinitialLayoutmember of VkImageCreateInfo. This layout can be used in place of the current image layout in a layout transition, but doing so will cause the contents of the image’s memory to be undefined. -
VK_IMAGE_LAYOUT_PREINITIALIZEDspecifies that an image’s memory is in a defined layout and can be populated by data, but that it has not yet been initialized by the driver. Image memory cannot be transitioned into this layout. This layout can be used as theinitialLayoutmember of VkImageCreateInfo. This layout is intended to be used as the initial layout for an image whose contents are written by the host, and hence the data can be written to memory immediately, without first executing a layout transition. Currently,VK_IMAGE_LAYOUT_PREINITIALIZEDis only useful with linear images because there is not a standard layout defined forVK_IMAGE_TILING_OPTIMALimages. -
VK_IMAGE_LAYOUT_GENERALsupports all types of device access. -
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMALmust only be used as a color or resolve attachment in aVkFramebuffer. This layout is valid only for image subresources of images created with theVK_IMAGE_USAGE_COLOR_ATTACHMENT_BITusage bit enabled. -
VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMALspecifies a layout for both the depth and stencil aspects of a depth/stencil format image allowing read and write access as a depth/stencil attachment. -
VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMALspecifies a layout for both the depth and stencil aspects of a depth/stencil format image allowing read only access as a depth/stencil attachment or in shaders as a sampled image, combined image/sampler, or input attachment. -
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMALspecifies a layout for depth/stencil format images allowing read and write access to the stencil aspect as a stencil attachment, and read only access to the depth aspect as a depth attachment or in shaders as a sampled image, combined image/sampler, or input attachment. -
VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMALspecifies a layout for depth/stencil format images allowing read and write access to the depth aspect as a depth attachment, and read only access to the stencil aspect as a stencil attachment or in shaders as a sampled image, combined image/sampler, or input attachment. -
VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMALspecifies a layout allowing read-only access in a shader as a sampled image, combined image/sampler, or input attachment. This layout is valid only for image subresources of images created with theVK_IMAGE_USAGE_SAMPLED_BITorVK_IMAGE_USAGE_INPUT_ATTACHMENT_BITusage bits enabled. -
VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMALmust only be used as a source image of a transfer command (see the definition ofVK_PIPELINE_STAGE_TRANSFER_BIT). This layout is valid only for image subresources of images created with theVK_IMAGE_USAGE_TRANSFER_SRC_BITusage bit enabled. -
VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMALmust only be used as a destination image of a transfer command. This layout is valid only for image subresources of images created with theVK_IMAGE_USAGE_TRANSFER_DST_BITusage bit enabled.
The layout of each image subresource is not a state of the image subresource
itself, but is rather a property of how the data in memory is organized, and
thus for each mechanism of accessing an image in the API the application
must specify a parameter or structure member that indicates which image
layout the image subresource(s) are considered to be in when the image will
be accessed.
For transfer commands, this is a parameter to the command (see Clear Commands
and Copy Commands).
For use as a framebuffer attachment, this is a member in the substructures
of the VkRenderPassCreateInfo (see Render Pass).
For use in a descriptor set, this is a member in the
VkDescriptorImageInfo structure (see Descriptor Set Updates).
12.4.1. Image Layout Matching Rules
At the time that any command buffer command accessing an image executes on any queue, the layouts of the image subresources that are accessed must all match exactly the layout specified via the API controlling those accesses , except in case of accesses to an image with a depth/stencil format performed through descriptors referring to only a single aspect of the image, where the following relaxed matching rules apply:
-
Descriptors referring just to the depth aspect of a depth/stencil image only need to match in the image layout of the depth aspect, thus
VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMALandVK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMALare considered to match. -
Descriptors referring just to the stencil aspect of a depth/stencil image only need to match in the image layout of the stencil aspect, thus
VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMALandVK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMALare considered to match .
When performing a layout transition on an image subresource, the old layout
value must either equal the current layout of the image subresource (at the
time the transition executes), or else be VK_IMAGE_LAYOUT_UNDEFINED
(implying that the contents of the image subresource need not be preserved).
The new layout used in a transition must not be
VK_IMAGE_LAYOUT_UNDEFINED or VK_IMAGE_LAYOUT_PREINITIALIZED.
12.5. Image Views
Image objects are not directly accessed by pipeline shaders for reading or writing image data. Instead, image views representing contiguous ranges of the image subresources and containing additional metadata are used for that purpose. Views must be created on images of compatible types, and must represent a valid subset of image subresources.
Image views are represented by VkImageView handles:
// Provided by VK_VERSION_1_0
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkImageView)VK_REMAINING_ARRAY_LAYERS is a special constant value used for image
views to indicate that all remaining array layers in an image after the base
layer should be included in the view.
#define VK_REMAINING_ARRAY_LAYERS (~0U)VK_REMAINING_MIP_LEVELS is a special constant value used for image
views to indicate that all remaining mipmap levels in an image after the
base level should be included in the view.
#define VK_REMAINING_MIP_LEVELS (~0U)The types of image views that can be created are:
// Provided by VK_VERSION_1_0
typedef enum VkImageViewType {
VK_IMAGE_VIEW_TYPE_1D = 0,
VK_IMAGE_VIEW_TYPE_2D = 1,
VK_IMAGE_VIEW_TYPE_3D = 2,
VK_IMAGE_VIEW_TYPE_CUBE = 3,
VK_IMAGE_VIEW_TYPE_1D_ARRAY = 4,
VK_IMAGE_VIEW_TYPE_2D_ARRAY = 5,
VK_IMAGE_VIEW_TYPE_CUBE_ARRAY = 6,
} VkImageViewType;To create an image view, call:
// Provided by VK_VERSION_1_0
VkResult vkCreateImageView(
VkDevice device,
const VkImageViewCreateInfo* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkImageView* pView);-
deviceis the logical device that creates the image view. -
pCreateInfois a pointer to aVkImageViewCreateInfostructure containing parameters to be used to create the image view. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter. -
pViewis a pointer to a VkImageView handle in which the resulting image view object is returned.
The VkImageViewCreateInfo structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkImageViewCreateInfo {
VkStructureType sType;
const void* pNext;
VkImageViewCreateFlags flags;
VkImage image;
VkImageViewType viewType;
VkFormat format;
VkComponentMapping components;
VkImageSubresourceRange subresourceRange;
} VkImageViewCreateInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis a bitmask of VkImageViewCreateFlagBits describing additional parameters of the image view. -
imageis a VkImage on which the view will be created. -
viewTypeis a VkImageViewType value specifying the type of the image view. -
formatis a VkFormat describing the format and type used to interpret texel blocks in the image. -
componentsis a VkComponentMapping structure specifying a remapping of color components (or of depth or stencil components after they have been converted into color components). -
subresourceRangeis a VkImageSubresourceRange structure selecting the set of mipmap levels and array layers to be accessible to the view.
Some of the image creation parameters are inherited by the view.
In particular, image view creation inherits the implicit parameter
usage specifying the allowed usages of the image view that, by
default, takes the value of the corresponding usage parameter
specified in VkImageCreateInfo at image creation time.
The implicit usage can be overriden by adding a
VkImageViewUsageCreateInfo structure to the pNext chain, but the
view usage must be a subset of the image usage.
If image was created with the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT
flag,
and if the format of the image is not
multi-planar,
format can be different from the image’s format, but if
image was created without the
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT flag and
they are not equal they must be compatible.
Image format compatibility is defined in the
Format Compatibility Classes section.
Views of compatible formats will have the same mapping between texel
coordinates and memory locations irrespective of the format, with only
the interpretation of the bit pattern changing.
|
Note
Values intended to be used with one view format may not be exactly preserved when written or read through a different format. For example, an integer value that happens to have the bit pattern of a floating point denorm or NaN may be flushed or canonicalized when written or read through a view with a floating point format. Similarly, a value written through a signed normalized format that has a bit pattern exactly equal to -2b may be changed to -2b + 1 as described in Conversion from Normalized Fixed-Point to Floating-Point. |
If image was created with the
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT flag, format
must be compatible with the image’s format as described above, or must
be an uncompressed format in which case it must be size-compatible with
the image’s format, as defined for
copying data between images.
In this case, the resulting image view’s texel dimensions equal the
dimensions of the selected mip level divided by the compressed texel block
size and rounded up.
The VkComponentMapping components member describes a remapping
from components of the image to components of the vector returned by shader
image instructions.
This remapping must be the identity swizzle for storage image descriptors,
input attachment descriptors,
framebuffer attachments, and any VkImageView used with a combined
image sampler that enables sampler Y’CBCR
conversion.
If the image view is to be used with a sampler which supports
sampler Y′CBCR conversion, an identically
defined object of type VkSamplerYcbcrConversion to that used to
create the sampler must be passed to vkCreateImageView in a
VkSamplerYcbcrConversionInfo included in the pNext chain of
VkImageViewCreateInfo.
Conversely, if a VkSamplerYcbcrConversion object is passed to
vkCreateImageView, an identically defined
VkSamplerYcbcrConversion object must be used when sampling the image.
If the image has a
multi-planar format and
subresourceRange.aspectMask is VK_IMAGE_ASPECT_COLOR_BIT,
then the format must be identical to the image format, and the
sampler to be used with the image view must enable
sampler Y′CBCR conversion.
If image was created with the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT
and the image has a
multi-planar format,
and if subresourceRange.aspectMask is
VK_IMAGE_ASPECT_PLANE_0_BIT, VK_IMAGE_ASPECT_PLANE_1_BIT, or
VK_IMAGE_ASPECT_PLANE_2_BIT, format must be
compatible with the corresponding plane of the
image, and the sampler to be used with the image view must not enable
sampler Y′CBCR conversion.
The width and height of the single-plane image view must be
derived from the multi-planar image’s dimensions in the manner listed for
plane compatibility for the plane.
Any view of an image plane will have the same mapping between texel coordinates and memory locations as used by the components of the color aspect, subject to the formulae relating texel coordinates to lower-resolution planes as described in Chroma Reconstruction. That is, if an R or B plane has a reduced resolution relative to the G plane of the multi-planar image, the image view operates using the (uplane, vplane) unnormalized coordinates of the reduced-resolution plane, and these coordinates access the same memory locations as the (ucolor, vcolor) unnormalized coordinates of the color aspect for which chroma reconstruction operations operate on the same (uplane, vplane) or (iplane, jplane) coordinates.
| Image View Type | Compatible Image Types |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bits which can be set in VkImageViewCreateInfo::flags,
specifying additional parameters of an image view, are:
// Provided by VK_VERSION_1_0
typedef enum VkImageViewCreateFlagBits {
} VkImageViewCreateFlagBits;// Provided by VK_VERSION_1_0
typedef VkFlags VkImageViewCreateFlags;VkImageViewCreateFlags is a bitmask type for setting a mask of zero or
more VkImageViewCreateFlagBits.
The set of usages for the created image view can be restricted compared to
the parent image’s usage flags by adding a
VkImageViewUsageCreateInfo structure to the pNext chain of
VkImageViewCreateInfo.
The VkImageViewUsageCreateInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkImageViewUsageCreateInfo {
VkStructureType sType;
const void* pNext;
VkImageUsageFlags usage;
} VkImageViewUsageCreateInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
usageis a bitmask of VkImageUsageFlagBits specifying allowed usages of the image view.
When this structure is chained to VkImageViewCreateInfo the
usage field overrides the implicit usage parameter inherited
from image creation time and its value is used instead for the purposes of
determining the valid usage conditions of VkImageViewCreateInfo.
The VkImageSubresourceRange structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkImageSubresourceRange {
VkImageAspectFlags aspectMask;
uint32_t baseMipLevel;
uint32_t levelCount;
uint32_t baseArrayLayer;
uint32_t layerCount;
} VkImageSubresourceRange;-
aspectMaskis a bitmask of VkImageAspectFlagBits specifying which aspect(s) of the image are included in the view. -
baseMipLevelis the first mipmap level accessible to the view. -
levelCountis the number of mipmap levels (starting frombaseMipLevel) accessible to the view. -
baseArrayLayeris the first array layer accessible to the view. -
layerCountis the number of array layers (starting frombaseArrayLayer) accessible to the view.
The number of mipmap levels and array layers must be a subset of the image
subresources in the image.
If an application wants to use all mip levels or layers in an image after
the baseMipLevel or baseArrayLayer, it can set levelCount
and layerCount to the special values VK_REMAINING_MIP_LEVELS and
VK_REMAINING_ARRAY_LAYERS without knowing the exact number of mip
levels or layers.
For cube and cube array image views, the layers of the image view starting
at baseArrayLayer correspond to faces in the order +X, -X, +Y, -Y, +Z,
-Z.
For cube arrays, each set of six sequential layers is a single cube, so the
number of cube maps in a cube map array view is layerCount / 6, and
image array layer (baseArrayLayer + i) is face index
(i mod 6) of cube i / 6.
If the number of layers in the view, whether set explicitly in
layerCount or implied by VK_REMAINING_ARRAY_LAYERS, is not a
multiple of 6, the last cube map in the array must not be accessed.
aspectMask must be only VK_IMAGE_ASPECT_COLOR_BIT,
VK_IMAGE_ASPECT_DEPTH_BIT or VK_IMAGE_ASPECT_STENCIL_BIT if
format is a color, depth-only or stencil-only format,
respectively, except if format is a
multi-planar format.
If using a depth/stencil format with both depth and stencil components,
aspectMask must include at least one of
VK_IMAGE_ASPECT_DEPTH_BIT and VK_IMAGE_ASPECT_STENCIL_BIT, and
can include both.
When the VkImageSubresourceRange structure is used to select a subset
of the slices of a 3D image’s mip level in order to create a 2D or 2D array
image view of a 3D image created with
VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT, baseArrayLayer and
layerCount specify the first slice index and the number of slices to
include in the created image view.
Such an image view can be used as a framebuffer attachment that refers only
to the specified range of slices of the selected mip level.
However, any layout transitions performed on such an attachment view during
a render pass instance still apply to the entire subresource referenced
which includes all the slices of the selected mip level.
When using an image view of a depth/stencil image to populate a descriptor
set (e.g. for sampling in the shader, or for use as an input attachment),
the aspectMask must only include one bit, which selects whether the
image view is used for depth reads (i.e. using a floating-point sampler or
input attachment in the shader) or stencil reads (i.e. using an unsigned
integer sampler or input attachment in the shader).
When an image view of a depth/stencil image is used as a depth/stencil
framebuffer attachment, the aspectMask is ignored and both depth and
stencil image subresources are used.
When creating a VkImageView, if sampler
Y′CBCR conversion is enabled in the sampler, the aspectMask of a
subresourceRange used by the VkImageView must be
VK_IMAGE_ASPECT_COLOR_BIT.
When creating a VkImageView, if sampler Y′CBCR conversion is not
enabled in the sampler and the image format is
multi-planar, the image must
have been created with VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT, and the
aspectMask of the VkImageView’s subresourceRange must be
VK_IMAGE_ASPECT_PLANE_0_BIT, VK_IMAGE_ASPECT_PLANE_1_BIT or
VK_IMAGE_ASPECT_PLANE_2_BIT.
Bits which can be set in an aspect mask to specify aspects of an image for purposes such as identifying a subresource, are:
// Provided by VK_VERSION_1_0
typedef enum VkImageAspectFlagBits {
VK_IMAGE_ASPECT_COLOR_BIT = 0x00000001,
VK_IMAGE_ASPECT_DEPTH_BIT = 0x00000002,
VK_IMAGE_ASPECT_STENCIL_BIT = 0x00000004,
VK_IMAGE_ASPECT_METADATA_BIT = 0x00000008,
// Provided by VK_VERSION_1_1
VK_IMAGE_ASPECT_PLANE_0_BIT = 0x00000010,
// Provided by VK_VERSION_1_1
VK_IMAGE_ASPECT_PLANE_1_BIT = 0x00000020,
// Provided by VK_VERSION_1_1
VK_IMAGE_ASPECT_PLANE_2_BIT = 0x00000040,
} VkImageAspectFlagBits;-
VK_IMAGE_ASPECT_COLOR_BITspecifies the color aspect. -
VK_IMAGE_ASPECT_DEPTH_BITspecifies the depth aspect. -
VK_IMAGE_ASPECT_STENCIL_BITspecifies the stencil aspect. -
VK_IMAGE_ASPECT_METADATA_BITspecifies the metadata aspect, used for sparse resource operations. -
VK_IMAGE_ASPECT_PLANE_0_BITspecifies plane 0 of a multi-planar image format. -
VK_IMAGE_ASPECT_PLANE_1_BITspecifies plane 1 of a multi-planar image format. -
VK_IMAGE_ASPECT_PLANE_2_BITspecifies plane 2 of a multi-planar image format.
// Provided by VK_VERSION_1_0
typedef VkFlags VkImageAspectFlags;VkImageAspectFlags is a bitmask type for setting a mask of zero or
more VkImageAspectFlagBits.
The VkComponentMapping structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkComponentMapping {
VkComponentSwizzle r;
VkComponentSwizzle g;
VkComponentSwizzle b;
VkComponentSwizzle a;
} VkComponentMapping;-
ris a VkComponentSwizzle specifying the component value placed in the R component of the output vector. -
gis a VkComponentSwizzle specifying the component value placed in the G component of the output vector. -
bis a VkComponentSwizzle specifying the component value placed in the B component of the output vector. -
ais a VkComponentSwizzle specifying the component value placed in the A component of the output vector.
Possible values of the members of VkComponentMapping, specifying the component values placed in each component of the output vector, are:
// Provided by VK_VERSION_1_0
typedef enum VkComponentSwizzle {
VK_COMPONENT_SWIZZLE_IDENTITY = 0,
VK_COMPONENT_SWIZZLE_ZERO = 1,
VK_COMPONENT_SWIZZLE_ONE = 2,
VK_COMPONENT_SWIZZLE_R = 3,
VK_COMPONENT_SWIZZLE_G = 4,
VK_COMPONENT_SWIZZLE_B = 5,
VK_COMPONENT_SWIZZLE_A = 6,
} VkComponentSwizzle;-
VK_COMPONENT_SWIZZLE_IDENTITYspecifies that the component is set to the identity swizzle. -
VK_COMPONENT_SWIZZLE_ZEROspecifies that the component is set to zero. -
VK_COMPONENT_SWIZZLE_ONEspecifies that the component is set to either 1 or 1.0, depending on whether the type of the image view format is integer or floating-point respectively, as determined by the Format Definition section for each VkFormat. -
VK_COMPONENT_SWIZZLE_Rspecifies that the component is set to the value of the R component of the image. -
VK_COMPONENT_SWIZZLE_Gspecifies that the component is set to the value of the G component of the image. -
VK_COMPONENT_SWIZZLE_Bspecifies that the component is set to the value of the B component of the image. -
VK_COMPONENT_SWIZZLE_Aspecifies that the component is set to the value of the A component of the image.
Setting the identity swizzle on a component is equivalent to setting the identity mapping on that component. That is:
| Component | Identity Mapping |
|---|---|
|
|
|
|
|
|
|
|
To destroy an image view, call:
// Provided by VK_VERSION_1_0
void vkDestroyImageView(
VkDevice device,
VkImageView imageView,
const VkAllocationCallbacks* pAllocator);-
deviceis the logical device that destroys the image view. -
imageViewis the image view to destroy. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter.
12.5.1. Image View Format Features
Valid uses of a VkImageView may depend on the image view’s format features, defined below. Such constraints are documented in the affected valid usage statement.
-
If VkImageViewCreateInfo::
imagewas created withVK_IMAGE_TILING_LINEAR, then the image view’s set of format features is the value of VkFormatProperties::linearTilingFeaturesfound by calling vkGetPhysicalDeviceFormatProperties on the sameformatas VkImageViewCreateInfo::format. -
If VkImageViewCreateInfo::
imagewas created withVK_IMAGE_TILING_OPTIMAL, then the image view’s set of format features is the value of VkFormatProperties::optimalTilingFeaturesfound by calling vkGetPhysicalDeviceFormatProperties on the sameformatas VkImageViewCreateInfo::format.
12.6. Resource Memory Association
Resources are initially created as virtual allocations with no backing memory. Device memory is allocated separately (see Device Memory) and then associated with the resource. This association is done differently for sparse and non-sparse resources.
Resources created with any of the sparse creation flags are considered sparse resources. Resources created without these flags are non-sparse. The details on resource memory association for sparse resources is described in Sparse Resources.
Non-sparse resources must be bound completely and contiguously to a single
VkDeviceMemory object before the resource is passed as a parameter to
any of the following operations:
-
creating image or buffer views
-
updating descriptor sets
-
recording commands in a command buffer
Once bound, the memory binding is immutable for the lifetime of the resource.
In a logical device representing more than one physical device, buffer and image resources exist on all physical devices but can be bound to memory differently on each. Each such replicated resource is an instance of the resource. For sparse resources, each instance can be bound to memory arbitrarily differently. For non-sparse resources, each instance can either be bound to the local or a peer instance of the memory, or for images can be bound to rectangular regions from the local and/or peer instances. When a resource is used in a descriptor set, each physical device interprets the descriptor according to its own instance’s binding to memory.
|
Note
There are no new copy commands to transfer data between physical devices. Instead, an application can create a resource with a peer mapping and use it as the source or destination of a transfer command executed by a single physical device to copy the data from one physical device to another. |
To determine the memory requirements for a buffer resource, call:
// Provided by VK_VERSION_1_0
void vkGetBufferMemoryRequirements(
VkDevice device,
VkBuffer buffer,
VkMemoryRequirements* pMemoryRequirements);-
deviceis the logical device that owns the buffer. -
bufferis the buffer to query. -
pMemoryRequirementsis a pointer to a VkMemoryRequirements structure in which the memory requirements of the buffer object are returned.
To determine the memory requirements for an image resource which is not
created with the VK_IMAGE_CREATE_DISJOINT_BIT flag set, call:
// Provided by VK_VERSION_1_0
void vkGetImageMemoryRequirements(
VkDevice device,
VkImage image,
VkMemoryRequirements* pMemoryRequirements);-
deviceis the logical device that owns the image. -
imageis the image to query. -
pMemoryRequirementsis a pointer to a VkMemoryRequirements structure in which the memory requirements of the image object are returned.
The VkMemoryRequirements structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkMemoryRequirements {
VkDeviceSize size;
VkDeviceSize alignment;
uint32_t memoryTypeBits;
} VkMemoryRequirements;-
sizeis the size, in bytes, of the memory allocation required for the resource. -
alignmentis the alignment, in bytes, of the offset within the allocation required for the resource. -
memoryTypeBitsis a bitmask and contains one bit set for every supported memory type for the resource. Bitiis set if and only if the memory typeiin theVkPhysicalDeviceMemoryPropertiesstructure for the physical device is supported for the resource.
The implementation guarantees certain properties about the memory requirements returned by vkGetBufferMemoryRequirements and vkGetImageMemoryRequirements:
-
The
memoryTypeBitsmember always contains at least one bit set. -
If
bufferis aVkBuffernot created with theVK_BUFFER_CREATE_SPARSE_BINDING_BITbit set, or ifimageis linear image, then thememoryTypeBitsmember always contains at least one bit set corresponding to aVkMemoryTypewith apropertyFlagsthat has both theVK_MEMORY_PROPERTY_HOST_VISIBLE_BITbit and theVK_MEMORY_PROPERTY_HOST_COHERENT_BITbit set. In other words, mappable coherent memory can always be attached to these objects. -
If
bufferwas created with VkExternalMemoryBufferCreateInfo::handleTypesset to0orimagewas created with VkExternalMemoryImageCreateInfo::handleTypesset to0, thememoryTypeBitsmember always contains at least one bit set corresponding to aVkMemoryTypewith apropertyFlagsthat has theVK_MEMORY_PROPERTY_DEVICE_LOCAL_BITbit set. -
The
memoryTypeBitsmember is identical for allVkBufferobjects created with the same value for theflagsandusagemembers in the VkBufferCreateInfo structure and thehandleTypesmember of the VkExternalMemoryBufferCreateInfo structure passed to vkCreateBuffer. Further, ifusage1andusage2of type VkBufferUsageFlags are such that the bits set inusage2are a subset of the bits set inusage1, and they have the sameflagsand VkExternalMemoryBufferCreateInfo::handleTypes, then the bits set inmemoryTypeBitsreturned forusage1must be a subset of the bits set inmemoryTypeBitsreturned forusage2, for all values offlags. -
The
alignmentmember is a power of two. -
The
alignmentmember is identical for allVkBufferobjects created with the same combination of values for theusageandflagsmembers in the VkBufferCreateInfo structure passed to vkCreateBuffer. -
The
alignmentmember satisfies the buffer descriptor offset alignment requirements associated with theVkBuffer’susage:-
If
usageincludedVK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BITorVK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT,alignmentmust be an integer multiple ofVkPhysicalDeviceLimits::minTexelBufferOffsetAlignment. -
If
usageincludedVK_BUFFER_USAGE_UNIFORM_BUFFER_BIT,alignmentmust be an integer multiple ofVkPhysicalDeviceLimits::minUniformBufferOffsetAlignment. -
If
usageincludedVK_BUFFER_USAGE_STORAGE_BUFFER_BIT,alignmentmust be an integer multiple ofVkPhysicalDeviceLimits::minStorageBufferOffsetAlignment.
-
-
For images created with a color format, the
memoryTypeBitsmember is identical for allVkImageobjects created with the same combination of values for thetilingmember, theVK_IMAGE_CREATE_SPARSE_BINDING_BITbit of theflagsmember, theVK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BITbit of theflagsmember,handleTypesmember of VkExternalMemoryImageCreateInfo, and theVK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BITof theusagemember in the VkImageCreateInfo structure passed to vkCreateImage. -
For images created with a depth/stencil format, the
memoryTypeBitsmember is identical for allVkImageobjects created with the same combination of values for theformatmember, thetilingmember, theVK_IMAGE_CREATE_SPARSE_BINDING_BITbit of theflagsmember, theVK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BITbit of theflagsmember,handleTypesmember of VkExternalMemoryImageCreateInfo, and theVK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BITof theusagemember in the VkImageCreateInfo structure passed to vkCreateImage. -
If the memory requirements are for a
VkImage, thememoryTypeBitsmember must not refer to aVkMemoryTypewith apropertyFlagsthat has theVK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BITbit set if theimagedid not haveVK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BITbit set in theusagemember of the VkImageCreateInfo structure passed to vkCreateImage. -
If the memory requirements are for a
VkBuffer, thememoryTypeBitsmember must not refer to aVkMemoryTypewith apropertyFlagsthat has theVK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BITbit set.NoteThe implication of this requirement is that lazily allocated memory is disallowed for buffers in all cases.
-
The
sizemember is identical for allVkBufferobjects created with the same combination of creation parameters specified in VkBufferCreateInfo and itspNextchain. -
The
sizemember is identical for allVkImageobjects created with the same combination of creation parameters specified in VkImageCreateInfo and itspNextchain.NoteThis, however, does not imply that they interpret the contents of the bound memory identically with each other. That additional guarantee, however, can be explicitly requested using
VK_IMAGE_CREATE_ALIAS_BIT.
To determine the memory requirements for a buffer resource, call:
// Provided by VK_VERSION_1_1
void vkGetBufferMemoryRequirements2(
VkDevice device,
const VkBufferMemoryRequirementsInfo2* pInfo,
VkMemoryRequirements2* pMemoryRequirements);-
deviceis the logical device that owns the buffer. -
pInfois a pointer to a VkBufferMemoryRequirementsInfo2 structure containing parameters required for the memory requirements query. -
pMemoryRequirementsis a pointer to a VkMemoryRequirements2 structure in which the memory requirements of the buffer object are returned.
The VkBufferMemoryRequirementsInfo2 structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkBufferMemoryRequirementsInfo2 {
VkStructureType sType;
const void* pNext;
VkBuffer buffer;
} VkBufferMemoryRequirementsInfo2;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
bufferis the buffer to query.
To determine the memory requirements for an image resource, call:
// Provided by VK_VERSION_1_1
void vkGetImageMemoryRequirements2(
VkDevice device,
const VkImageMemoryRequirementsInfo2* pInfo,
VkMemoryRequirements2* pMemoryRequirements);-
deviceis the logical device that owns the image. -
pInfois a pointer to a VkImageMemoryRequirementsInfo2 structure containing parameters required for the memory requirements query. -
pMemoryRequirementsis a pointer to a VkMemoryRequirements2 structure in which the memory requirements of the image object are returned.
The VkImageMemoryRequirementsInfo2 structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkImageMemoryRequirementsInfo2 {
VkStructureType sType;
const void* pNext;
VkImage image;
} VkImageMemoryRequirementsInfo2;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
imageis the image to query.
To determine the memory requirements for a plane of a disjoint image, add a
VkImagePlaneMemoryRequirementsInfo structure to the pNext chain
of the VkImageMemoryRequirementsInfo2 structure.
The VkImagePlaneMemoryRequirementsInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkImagePlaneMemoryRequirementsInfo {
VkStructureType sType;
const void* pNext;
VkImageAspectFlagBits planeAspect;
} VkImagePlaneMemoryRequirementsInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
planeAspectis a VkImageAspectFlagBits value specifying the aspect corresponding to the image plane to query.
The VkMemoryRequirements2 structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkMemoryRequirements2 {
VkStructureType sType;
void* pNext;
VkMemoryRequirements memoryRequirements;
} VkMemoryRequirements2;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
memoryRequirementsis a VkMemoryRequirements structure describing the memory requirements of the resource.
The VkMemoryDedicatedRequirements structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkMemoryDedicatedRequirements {
VkStructureType sType;
void* pNext;
VkBool32 prefersDedicatedAllocation;
VkBool32 requiresDedicatedAllocation;
} VkMemoryDedicatedRequirements;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
prefersDedicatedAllocationspecifies that the implementation would prefer a dedicated allocation for this resource. The application is still free to suballocate the resource but it may get better performance if a dedicated allocation is used. -
requiresDedicatedAllocationspecifies that a dedicated allocation is required for this resource.
To determine the dedicated allocation requirements of a buffer or image
resource, add a VkMemoryDedicatedRequirements structure to the
pNext chain of the VkMemoryRequirements2 structure passed as the
pMemoryRequirements parameter of vkGetBufferMemoryRequirements2
or vkGetImageMemoryRequirements2, respectively.
Constraints on the values returned for buffer resources are:
-
requiresDedicatedAllocationmay beVK_TRUEif thepNextchain of VkBufferCreateInfo for the call tovkCreateBufferused to create the buffer being queried included a VkExternalMemoryBufferCreateInfo structure, and any of the handle types specified in VkExternalMemoryBufferCreateInfo::handleTypesrequires dedicated allocation, as reported by vkGetPhysicalDeviceExternalBufferProperties inVkExternalBufferProperties::externalMemoryProperties.externalMemoryFeatures. Otherwise,requiresDedicatedAllocationwill beVK_FALSE. -
When the implementation sets
requiresDedicatedAllocationtoVK_TRUE, it must also setprefersDedicatedAllocationtoVK_TRUE. -
If
VK_BUFFER_CREATE_SPARSE_BINDING_BITwas set in VkBufferCreateInfo::flagswhenbufferwas created, then bothprefersDedicatedAllocationandrequiresDedicatedAllocationwill beVK_FALSE.
Constraints on the values returned for image resources are:
-
requiresDedicatedAllocationmay beVK_TRUEif thepNextchain of VkImageCreateInfo for the call to vkCreateImage used to create the image being queried included a VkExternalMemoryImageCreateInfo structure, and any of the handle types specified in VkExternalMemoryImageCreateInfo::handleTypesrequires dedicated allocation, as reported by vkGetPhysicalDeviceImageFormatProperties2 inVkExternalImageFormatProperties::externalMemoryProperties.externalMemoryFeatures. Otherwise,requiresDedicatedAllocationwill beVK_FALSE. -
If
VK_IMAGE_CREATE_SPARSE_BINDING_BITwas set in VkImageCreateInfo::flagswhenimagewas created, then bothprefersDedicatedAllocationandrequiresDedicatedAllocationwill beVK_FALSE.
To attach memory to a buffer object, call:
// Provided by VK_VERSION_1_0
VkResult vkBindBufferMemory(
VkDevice device,
VkBuffer buffer,
VkDeviceMemory memory,
VkDeviceSize memoryOffset);-
deviceis the logical device that owns the buffer and memory. -
bufferis the buffer to be attached to memory. -
memoryis a VkDeviceMemory object describing the device memory to attach. -
memoryOffsetis the start offset of the region ofmemorywhich is to be bound to the buffer. The number of bytes returned in theVkMemoryRequirements::sizemember inmemory, starting frommemoryOffsetbytes, will be bound to the specified buffer.
vkBindBufferMemory is equivalent to passing the same parameters
through VkBindBufferMemoryInfo to vkBindBufferMemory2.
To attach memory to buffer objects for one or more buffers at a time, call:
// Provided by VK_VERSION_1_1
VkResult vkBindBufferMemory2(
VkDevice device,
uint32_t bindInfoCount,
const VkBindBufferMemoryInfo* pBindInfos);-
deviceis the logical device that owns the buffers and memory. -
bindInfoCountis the number of elements inpBindInfos. -
pBindInfosis a pointer to an array ofbindInfoCountVkBindBufferMemoryInfo structures describing buffers and memory to bind.
On some implementations, it may be more efficient to batch memory bindings into a single command.
VkBindBufferMemoryInfo contains members corresponding to the
parameters of vkBindBufferMemory.
The VkBindBufferMemoryInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkBindBufferMemoryInfo {
VkStructureType sType;
const void* pNext;
VkBuffer buffer;
VkDeviceMemory memory;
VkDeviceSize memoryOffset;
} VkBindBufferMemoryInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
bufferis the buffer to be attached to memory. -
memoryis a VkDeviceMemory object describing the device memory to attach. -
memoryOffsetis the start offset of the region ofmemorywhich is to be bound to the buffer. The number of bytes returned in theVkMemoryRequirements::sizemember inmemory, starting frommemoryOffsetbytes, will be bound to the specified buffer.
The VkBindBufferMemoryDeviceGroupInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkBindBufferMemoryDeviceGroupInfo {
VkStructureType sType;
const void* pNext;
uint32_t deviceIndexCount;
const uint32_t* pDeviceIndices;
} VkBindBufferMemoryDeviceGroupInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
deviceIndexCountis the number of elements inpDeviceIndices. -
pDeviceIndicesis a pointer to an array of device indices.
If the pNext chain of VkBindBufferMemoryInfo includes a
VkBindBufferMemoryDeviceGroupInfo structure, then that structure
determines how memory is bound to buffers across multiple devices in a
device group.
If deviceIndexCount is greater than zero, then on device index i
the buffer is attached to the instance of memory on the physical
device with device index pDeviceIndices[i].
If deviceIndexCount is zero and memory comes from a memory heap
with the VK_MEMORY_HEAP_MULTI_INSTANCE_BIT bit set, then it is as if
pDeviceIndices contains consecutive indices from zero to the number of
physical devices in the logical device, minus one.
In other words, by default each physical device attaches to its own instance
of memory.
If deviceIndexCount is zero and memory comes from a memory heap
without the VK_MEMORY_HEAP_MULTI_INSTANCE_BIT bit set, then it is as
if pDeviceIndices contains an array of zeros.
In other words, by default each physical device attaches to instance zero.
To attach memory to a VkImage object created without the
VK_IMAGE_CREATE_DISJOINT_BIT set, call:
// Provided by VK_VERSION_1_0
VkResult vkBindImageMemory(
VkDevice device,
VkImage image,
VkDeviceMemory memory,
VkDeviceSize memoryOffset);-
deviceis the logical device that owns the image and memory. -
imageis the image. -
memoryis the VkDeviceMemory object describing the device memory to attach. -
memoryOffsetis the start offset of the region ofmemorywhich is to be bound to the image. The number of bytes returned in theVkMemoryRequirements::sizemember inmemory, starting frommemoryOffsetbytes, will be bound to the specified image.
vkBindImageMemory is equivalent to passing the same parameters through
VkBindImageMemoryInfo to vkBindImageMemory2.
To attach memory to image objects for one or more images at a time, call:
// Provided by VK_VERSION_1_1
VkResult vkBindImageMemory2(
VkDevice device,
uint32_t bindInfoCount,
const VkBindImageMemoryInfo* pBindInfos);-
deviceis the logical device that owns the images and memory. -
bindInfoCountis the number of elements inpBindInfos. -
pBindInfosis a pointer to an array of VkBindImageMemoryInfo structures, describing images and memory to bind.
On some implementations, it may be more efficient to batch memory bindings into a single command.
VkBindImageMemoryInfo contains members corresponding to the parameters
of vkBindImageMemory.
The VkBindImageMemoryInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkBindImageMemoryInfo {
VkStructureType sType;
const void* pNext;
VkImage image;
VkDeviceMemory memory;
VkDeviceSize memoryOffset;
} VkBindImageMemoryInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
imageis the image to be attached to memory. -
memoryis a VkDeviceMemory object describing the device memory to attach. -
memoryOffsetis the start offset of the region ofmemorywhich is to be bound to the image. The number of bytes returned in theVkMemoryRequirements::sizemember inmemory, starting frommemoryOffsetbytes, will be bound to the specified image.
The VkBindImageMemoryDeviceGroupInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkBindImageMemoryDeviceGroupInfo {
VkStructureType sType;
const void* pNext;
uint32_t deviceIndexCount;
const uint32_t* pDeviceIndices;
uint32_t splitInstanceBindRegionCount;
const VkRect2D* pSplitInstanceBindRegions;
} VkBindImageMemoryDeviceGroupInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
deviceIndexCountis the number of elements inpDeviceIndices. -
pDeviceIndicesis a pointer to an array of device indices. -
splitInstanceBindRegionCountis the number of elements inpSplitInstanceBindRegions. -
pSplitInstanceBindRegionsis a pointer to an array of VkRect2D structures describing which regions of the image are attached to each instance of memory.
If the pNext chain of VkBindImageMemoryInfo includes a
VkBindImageMemoryDeviceGroupInfo structure, then that structure
determines how memory is bound to images across multiple devices in a device
group.
If deviceIndexCount is greater than zero, then on device index i
image is attached to the instance of the memory on the physical device
with device index pDeviceIndices[i].
Let N be the number of physical devices in the logical device.
If splitInstanceBindRegionCount is greater than zero, then
pSplitInstanceBindRegions is a pointer to an array of N2
rectangles, where the image region specified by the rectangle at element
i*N+j in resource instance i is bound to the memory instance
j.
The blocks of the memory that are bound to each sparse image block region
use an offset in memory, relative to memoryOffset, computed as if the
whole image was being bound to a contiguous range of memory.
In other words, horizontally adjacent image blocks use consecutive blocks of
memory, vertically adjacent image blocks are separated by the number of
bytes per block multiplied by the width in blocks of image, and the
block at (0,0) corresponds to memory starting at memoryOffset.
If splitInstanceBindRegionCount and deviceIndexCount are zero
and the memory comes from a memory heap with the
VK_MEMORY_HEAP_MULTI_INSTANCE_BIT bit set, then it is as if
pDeviceIndices contains consecutive indices from zero to the number of
physical devices in the logical device, minus one.
In other words, by default each physical device attaches to its own instance
of the memory.
If splitInstanceBindRegionCount and deviceIndexCount are zero
and the memory comes from a memory heap without the
VK_MEMORY_HEAP_MULTI_INSTANCE_BIT bit set, then it is as if
pDeviceIndices contains an array of zeros.
In other words, by default each physical device attaches to instance zero.
In order to bind planes of a disjoint image, add a
VkBindImagePlaneMemoryInfo structure to the pNext chain of
VkBindImageMemoryInfo.
The VkBindImagePlaneMemoryInfo structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkBindImagePlaneMemoryInfo {
VkStructureType sType;
const void* pNext;
VkImageAspectFlagBits planeAspect;
} VkBindImagePlaneMemoryInfo;-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
planeAspectis aVkImageAspectFlagBitsvalue specifying the aspect of the disjoint image plane to bind.
There is an implementation-dependent limit, bufferImageGranularity,
which specifies a page-like granularity at which linear and non-linear
resources must be placed in adjacent memory locations to avoid aliasing.
Two resources which do not satisfy this granularity requirement are said to
alias.
bufferImageGranularity is specified in bytes, and must be a power of
two.
Implementations which do not impose a granularity restriction may report a
bufferImageGranularity value of one.
|
Note
Despite its name, |
Given resourceA at the lower memory offset and resourceB at the higher
memory offset in the same VkDeviceMemory object, where one resource is
linear and the other is non-linear (as defined in the
Glossary), and the following:
resourceA.end = resourceA.memoryOffset + resourceA.size - 1
resourceA.endPage = resourceA.end & ~(bufferImageGranularity-1)
resourceB.start = resourceB.memoryOffset
resourceB.startPage = resourceB.start & ~(bufferImageGranularity-1)The following property must hold:
resourceA.endPage < resourceB.startPageThat is, the end of the first resource (A) and the beginning of the second
resource (B) must be on separate “pages” of size
bufferImageGranularity.
bufferImageGranularity may be different than the physical page size
of the memory heap.
This restriction is only needed when a linear resource and a non-linear
resource are adjacent in memory and will be used simultaneously.
The memory ranges of adjacent resources can be closer than
bufferImageGranularity, provided they meet the alignment
requirement for the objects in question.
Sparse block size in bytes and sparse image and buffer memory alignments
must all be multiples of the bufferImageGranularity.
Therefore, memory bound to sparse resources naturally satisfies the
bufferImageGranularity.
12.7. Resource Sharing Mode
Buffer and image objects are created with a sharing mode controlling how they can be accessed from queues. The supported sharing modes are:
// Provided by VK_VERSION_1_0
typedef enum VkSharingMode {
VK_SHARING_MODE_EXCLUSIVE = 0,
VK_SHARING_MODE_CONCURRENT = 1,
} VkSharingMode;-
VK_SHARING_MODE_EXCLUSIVEspecifies that access to any range or image subresource of the object will be exclusive to a single queue family at a time. -
VK_SHARING_MODE_CONCURRENTspecifies that concurrent access to any range or image subresource of the object from multiple queue families is supported.
|
Note
|
Ranges of buffers and image subresources of image objects created using
VK_SHARING_MODE_EXCLUSIVE must only be accessed by queues in the
queue family that has ownership of the resource.
Upon creation, such resources are not owned by any queue family; ownership
is implicitly acquired upon first use within a queue.
Once a resource using VK_SHARING_MODE_EXCLUSIVE is owned by some queue
family, the application must perform a
queue family ownership transfer to make
the memory contents of a range or image subresource accessible to a
different queue family.
|
Note
Images still require a layout transition from
|
A queue family can take ownership of an image subresource or buffer range
of a resource created with VK_SHARING_MODE_EXCLUSIVE, without an
ownership transfer, in the same way as for a resource that was just created;
however, taking ownership in this way has the effect that the contents of
the image subresource or buffer range are undefined.
Ranges of buffers and image subresources of image objects created using
VK_SHARING_MODE_CONCURRENT must only be accessed by queues from the
queue families specified through the queueFamilyIndexCount and
pQueueFamilyIndices members of the corresponding create info
structures.
12.7.1. External Resource Sharing
Resources should only be accessed in the Vulkan instance that has exclusive
ownership of their underlying memory.
Only one Vulkan instance has exclusive ownership of a resource’s underlying
memory at a given time, regardless of whether the resource was created using
VK_SHARING_MODE_EXCLUSIVE or VK_SHARING_MODE_CONCURRENT.
Applications can transfer ownership of a resource’s underlying memory only
if the memory has been imported from or exported to another instance or
external API using external memory handles.
The semantics for transferring ownership outside of the instance are similar
to those used for transferring ownership of VK_SHARING_MODE_EXCLUSIVE
resources between queues, and is also accomplished using
VkBufferMemoryBarrier or VkImageMemoryBarrier operations.
Applications must
-
Release exclusive ownership from the source instance or API.
-
Ensure the release operation has completed using semaphores or fences.
-
Acquire exclusive ownership in the destination instance or API
Unlike queue ownership transfers, the destination instance or API is not
specified explicitly when releasing ownership, nor is the source instance or
API specified when acquiring ownership.
Instead, the image or memory barrier’s dstQueueFamilyIndex or
srcQueueFamilyIndex parameters are set to the reserved queue family
index VK_QUEUE_FAMILY_EXTERNAL
to represent the external destination or source respectively.
Binding a resource to a memory object shared between multiple Vulkan
instances or other APIs does not change the ownership of the underlying
memory.
The first entity to access the resource implicitly acquires ownership.
Accessing a resource backed by memory that is owned by a particular instance
or API has the same semantics as accessing a VK_SHARING_MODE_EXCLUSIVE
resource, with one exception: Implementations must ensure layout
transitions performed on one member of a set of identical subresources of
identical images that alias the same range of an underlying memory object
affect the layout of all the subresources in the set.
As a corollary, writes to any image subresources in such a set must not
make the contents of memory used by other subresources in the set
undefined.
An application can define the content of a subresource of one image by
performing device writes to an identical subresource of another image
provided both images are bound to the same region of external memory.
Applications may also add resources to such a set after the content of the
existing set members has been defined without making the content undefined
by creating a new image with the initial layout
VK_IMAGE_LAYOUT_UNDEFINED and binding it to the same region of
external memory as the existing images.
|
Note
Because layout transitions apply to all identical images aliasing the same region of external memory, the actual layout of the memory backing a new image as well as an existing image with defined content will not be undefined. Such an image is not usable until it acquires ownership of its memory from the existing owner. Therefore, the layout specified as part of this transition will be the true initial layout of the image. The undefined layout specified when creating it is a placeholder to simplify valid usage requirements. |
12.8. Memory Aliasing
A range of a VkDeviceMemory allocation is aliased if it is bound to
multiple resources simultaneously, as described below, via
vkBindImageMemory, vkBindBufferMemory,
via sparse memory bindings, or by binding
the memory to resources in multiple Vulkan instances or external APIs using
external memory handle export and import mechanisms.
Consider two resources, resourceA and resourceB, bound respectively to
memory rangeA and rangeB.
Let paddedRangeA and paddedRangeB be, respectively, rangeA and
rangeB aligned to bufferImageGranularity.
If the resources are both linear or both non-linear (as defined in the
Glossary), then the resources alias the
memory in the intersection of rangeA and rangeB.
If one resource is linear and the other is non-linear, then the resources
alias the memory in the intersection of paddedRangeA and paddedRangeB.
Applications can alias memory, but use of multiple aliases is subject to several constraints.
|
Note
Memory aliasing can be useful to reduce the total device memory footprint of an application, if some large resources are used for disjoint periods of time. |
When a non-linear,
non-VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT image is bound to an aliased
range, all image subresources of the image overlap the range.
When a linear image is bound to an aliased range, the image subresources
that (according to the image’s advertised layout) include bytes from the
aliased range overlap the range.
When a VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT image has sparse image
blocks bound to an aliased range, only image subresources including those
sparse image blocks overlap the range, and when the memory bound to the
image’s mip tail overlaps an aliased range all image subresources in the mip
tail overlap the range.
Buffers, and linear image subresources in either the
VK_IMAGE_LAYOUT_PREINITIALIZED or VK_IMAGE_LAYOUT_GENERAL
layouts, are host-accessible subresources.
That is, the host has a well-defined addressing scheme to interpret the
contents, and thus the layout of the data in memory can be consistently
interpreted across aliases if each of those aliases is a host-accessible
subresource.
Non-linear images, and linear image subresources in other layouts, are not
host-accessible.
If two aliases are both host-accessible, then they interpret the contents of the memory in consistent ways, and data written to one alias can be read by the other alias.
If two aliases are both images that were created with identical creation
parameters, both were created with the VK_IMAGE_CREATE_ALIAS_BIT flag
set, and both are bound identically to memory
except for VkBindImageMemoryDeviceGroupInfo::pDeviceIndices and
VkBindImageMemoryDeviceGroupInfo::pSplitInstanceBindRegions,
then they interpret the contents of the memory in consistent ways, and data
written to one alias can be read by the other alias.
Additionally, if an individual plane of a multi-planar image and a single-plane image alias the same memory, then they also interpret the contents of the memory in consistent ways under the same conditions, but with the following modifications:
-
Both must have been created with the
VK_IMAGE_CREATE_DISJOINT_BITflag. -
The single-plane image must have a VkFormat that is equivalent to that of the multi-planar image’s individual plane.
-
The single-plane image and the individual plane of the multi-planar image must be bound identically to memory except for VkBindImageMemoryDeviceGroupInfo::
pDeviceIndicesand VkBindImageMemoryDeviceGroupInfo::pSplitInstanceBindRegions. -
The
widthandheightof the single-plane image are derived from the multi-planar image’s dimensions in the manner listed for plane compatibility for the aliased plane. -
All other creation parameters must be identical
Aliases created by binding the same memory to resources in multiple Vulkan instances or external APIs using external memory handle export and import mechanisms interpret the contents of the memory in consistent ways, and data written to one alias can be read by the other alias.
Otherwise, the aliases interpret the contents of the memory differently, and writes via one alias make the contents of memory partially or completely undefined to the other alias. If the first alias is a host-accessible subresource, then the bytes affected are those written by the memory operations according to its addressing scheme. If the first alias is not host-accessible, then the bytes affected are those overlapped by the image subresources that were written. If the second alias is a host-accessible subresource, the affected bytes become undefined. If the second alias is not host-accessible, all sparse image blocks (for sparse partially-resident images) or all image subresources (for non-sparse image and fully resident sparse images) that overlap the affected bytes become undefined.
If any image subresources are made undefined due to writes to an alias,
then each of those image subresources must have its layout transitioned
from VK_IMAGE_LAYOUT_UNDEFINED to a valid layout before it is used, or
from VK_IMAGE_LAYOUT_PREINITIALIZED if the memory has been written by
the host.
If any sparse blocks of a sparse image have been made undefined, then only
the image subresources containing them must be transitioned.
Use of an overlapping range by two aliases must be separated by a memory dependency using the appropriate access types if at least one of those uses performs writes, whether the aliases interpret memory consistently or not. If buffer or image memory barriers are used, the scope of the barrier must contain the entire range and/or set of image subresources that overlap.
If two aliasing image views are used in the same framebuffer, then the
render pass must declare the attachments using the
VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT, and
follow the other rules listed in that section.
|
Note
Memory recycled via an application suballocator (i.e. without freeing and reallocating the memory objects) is not substantially different from memory aliasing. However, a suballocator usually waits on a fence before recycling a region of memory, and signaling a fence involves sufficient implicit dependencies to satisfy all the above requirements. |