Vulkan.Core10.DeviceInitialization

vkCreateInstance - Create a new Vulkan instance

Description

createInstance verifies that the requested layers exist. If not, createInstance will return ERROR_LAYER_NOT_PRESENT. Next createInstance verifies that the requested extensions are supported (e.g. in the implementation or in any enabled instance layer) and if any requested extension is not supported, createInstance must return ERROR_EXTENSION_NOT_PRESENT. After verifying and enabling the instance layers and extensions the Instance object is created and returned to the application. If a requested extension is only supported by a layer, both the layer and the extension need to be specified at createInstance time for the creation to succeed.

Valid Usage

• All required extensions for each extension in the InstanceCreateInfo::ppEnabledExtensionNames list must also be present in that list

Valid Usage (Implicit)

• pCreateInfo must be a valid pointer to a valid InstanceCreateInfo structure

• If pAllocator is not NULL, pAllocator must be a valid pointer to a valid AllocationCallbacks structure

• pInstance must be a valid pointer to a Instance handle

Return Codes

Success

• SUCCESS

Failure

• ERROR_EXTENSION_NOT_PRESENT

• ERROR_INCOMPATIBLE_DRIVER

• ERROR_INITIALIZATION_FAILED

• ERROR_LAYER_NOT_PRESENT

• ERROR_OUT_OF_DEVICE_MEMORY

• ERROR_OUT_OF_HOST_MEMORY

• ERROR_UNKNOWN

• ERROR_VALIDATION_FAILED

See Also

VK_VERSION_1_0, AllocationCallbacks, Instance, InstanceCreateInfo

A convenience wrapper to make a compatible pair of calls to createInstance and destroyInstance

To ensure that destroyInstance is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

vkDestroyInstance - Destroy an instance of Vulkan

Description

Prior to destroying an instance, an application is responsible for destroying/freeing any Vulkan objects with explicit vkDestroy* or vkFree* commands that were created using that instance, or any PhysicalDevice object retrieved from it, as the first parameter of the corresponding vkCreate* or vkAllocate* command.

Valid Usage

• All child objects that were created with instance or with a PhysicalDevice retrieved from it, and that can be destroyed or freed, must have been destroyed or freed prior to destroying instance

• If AllocationCallbacks were provided when instance was created, a compatible set of callbacks must be provided here

• If no AllocationCallbacks were provided when instance was created, pAllocator must be NULL

Valid Usage (Implicit)

• If instance is not NULL, instance must be a valid Instance handle

• If pAllocator is not NULL, pAllocator must be a valid pointer to a valid AllocationCallbacks structure

Host Synchronization

• Host access to instance must be externally synchronized

• Host access to all PhysicalDevice objects enumerated from instance must be externally synchronized

See Also

VK_VERSION_1_0, AllocationCallbacks, Instance

vkEnumeratePhysicalDevices - Enumerates the physical devices accessible to a Vulkan instance

Description

If pPhysicalDevices is NULL, then the number of physical devices available is returned in pPhysicalDeviceCount. Otherwise, pPhysicalDeviceCount must point to a variable set by the application to the number of elements in the pPhysicalDevices array, and on return the variable is overwritten with the number of handles actually written to pPhysicalDevices. If pPhysicalDeviceCount is less than the number of physical devices available, at most pPhysicalDeviceCount structures will be written, and INCOMPLETE will be returned instead of SUCCESS, to indicate that not all the available physical devices were returned.

Valid Usage (Implicit)

• instance must be a valid Instance handle

• pPhysicalDeviceCount must be a valid pointer to a uint32_t value

• If the value referenced by pPhysicalDeviceCount is not 0, and pPhysicalDevices is not NULL, pPhysicalDevices must be a valid pointer to an array of pPhysicalDeviceCount PhysicalDevice handles

Return Codes

Success

• INCOMPLETE

• SUCCESS

Failure

• ERROR_INITIALIZATION_FAILED

• ERROR_OUT_OF_DEVICE_MEMORY

• ERROR_OUT_OF_HOST_MEMORY

• ERROR_UNKNOWN

• ERROR_VALIDATION_FAILED

See Also

VK_VERSION_1_0, Instance, PhysicalDevice

vkGetDeviceProcAddr - Return a function pointer for a command

Description

The table below defines the various use cases for getDeviceProcAddr and expected return value (“fp” is “function pointer”) for each case. A valid returned function pointer (“fp”) must not be NULL.

The returned function pointer is of type PFN_vkVoidFunction, and must be cast to the type of the command being queried before use. The function pointer must only be called with a dispatchable object (the first parameter) that is device or a child of device.

getDeviceProcAddr behavior

1

"*" means any representable value for the parameter (including valid values, invalid values, and

NULL

).

2

Device-level commands which are part of the core version specified by

ApplicationInfo

::

apiVersion

when creating the instance will always return a valid function pointer. If the

maintenance5

feature is enabled, core commands beyond that version which are supported by the implementation will return

NULL

, otherwise the implementation

may

either return

NULL

or a function pointer. If a function pointer is returned, it

must

not be called.

3

In this function, device-level excludes all physical-device-level commands.

4

The returned function pointer

must

only be called with a dispatchable object (the first parameter) that is

device

or a child of

device

e.g.

Device

,

Queue

, or

CommandBuffer

.

Valid Usage (Implicit)

See Also

PFN_vkVoidFunction, VK_VERSION_1_0, Device

vkGetInstanceProcAddr - Return a function pointer for a command

Description

getInstanceProcAddr itself is obtained in a platform- and loader- specific manner. Typically, the loader library will export this command as a function symbol, so applications can link against the loader library, or load it dynamically and look up the symbol using platform-specific APIs.

The table below defines the various use cases for getInstanceProcAddr and expected return value (“fp” is “function pointer”) for each case. A valid returned function pointer (“fp”) must not be NULL.

The returned function pointer is of type PFN_vkVoidFunction, and must be cast to the type of the command being queried before use.

getInstanceProcAddr behavior

1

"*" means any representable value for the parameter (including valid values, invalid values, and

NULL

).

2

The global commands are:

enumerateInstanceVersion

,

enumerateInstanceExtensionProperties

,

enumerateInstanceLayerProperties

, and

createInstance

. Dispatchable commands are all other commands which are not global.

3

The returned function pointer

must

only be called with a dispatchable object (the first parameter) that is

instance

or a child of

instance

, e.g.

Instance

,

PhysicalDevice

,

Device

,

Queue

, or

CommandBuffer

.

4

An “available device extension” is a device extension supported by any physical device enumerated by

instance

.

5

Starting with Vulkan 1.2,

getInstanceProcAddr

can resolve itself with a

NULL

instance pointer.

Valid Usage (Implicit)

• If instance is not NULL, instance must be a valid Instance handle

• pName must be a null-terminated UTF-8 string

See Also

PFN_vkVoidFunction, VK_VERSION_1_0, Instance

vkGetPhysicalDeviceProperties - Returns properties of a physical device

Valid Usage (Implicit)

See Also

VK_VERSION_1_0, PhysicalDevice, PhysicalDeviceProperties

vkGetPhysicalDeviceQueueFamilyProperties - Reports properties of the queues of the specified physical device

Description

If pQueueFamilyProperties is NULL, then the number of queue families available is returned in pQueueFamilyPropertyCount. Implementations must support at least one queue family. Otherwise, pQueueFamilyPropertyCount must point to a variable set by the application to the number of elements in the pQueueFamilyProperties array, and on return the variable is overwritten with the number of structures actually written to pQueueFamilyProperties. If pQueueFamilyPropertyCount is less than the number of queue families available, at most pQueueFamilyPropertyCount structures will be written.

Valid Usage (Implicit)

• physicalDevice must be a valid PhysicalDevice handle

• pQueueFamilyPropertyCount must be a valid pointer to a uint32_t value

• If the value referenced by pQueueFamilyPropertyCount is not 0, and pQueueFamilyProperties is not NULL, pQueueFamilyProperties must be a valid pointer to an array of pQueueFamilyPropertyCount QueueFamilyProperties structures

See Also

VK_VERSION_1_0, PhysicalDevice, QueueFamilyProperties

vkGetPhysicalDeviceMemoryProperties - Reports memory information for the specified physical device

Valid Usage (Implicit)

See Also

VK_VERSION_1_0, PhysicalDevice, PhysicalDeviceMemoryProperties

vkGetPhysicalDeviceFeatures - Reports capabilities of a physical device

Valid Usage (Implicit)

See Also

VK_VERSION_1_0, PhysicalDevice, PhysicalDeviceFeatures

vkGetPhysicalDeviceFormatProperties - Lists physical device’s format capabilities

Valid Usage

• If Vulkan 1.3 is not supported, the maintenance5 feature is not supported, and the ycbcr2plane444Formats feature is not supported, format must not be FORMAT_G8_B8R8_2PLANE_444_UNORM, FORMAT_G10X6_B10X6R10X6_2PLANE_444_UNORM_3PACK16, FORMAT_G12X4_B12X4R12X4_2PLANE_444_UNORM_3PACK16, or FORMAT_G16_B16R16_2PLANE_444_UNORM

Valid Usage (Implicit)

• physicalDevice must be a valid PhysicalDevice handle

• format must be a valid Format value

• pFormatProperties must be a valid pointer to a FormatProperties structure

See Also

VK_VERSION_1_0, Format, FormatProperties, PhysicalDevice

vkGetPhysicalDeviceImageFormatProperties - Lists physical device’s image format capabilities

Description

The format, type, tiling, usage, and flags parameters correspond to parameters that would be consumed by createImage (as members of ImageCreateInfo).

If format is not a supported image format, or if the combination of format, type, tiling, usage, and flags is not supported for images, then getPhysicalDeviceImageFormatProperties returns ERROR_FORMAT_NOT_SUPPORTED.

The limitations on an image format that are reported by getPhysicalDeviceImageFormatProperties have the following property: if usage1 and usage2 of type ImageUsageFlags are such that the bits set in usage1 are a subset of the bits set in usage2, and flags1 and flags2 of type ImageCreateFlags are such that the bits set in flags1 are a subset of the bits set in flags2, then the limitations for usage1 and flags1 must be no more strict than the limitations for usage2 and flags2, for all values of format, type, and tiling.

If the hostImageCopy feature is supported, and:

Then the result of calls to getPhysicalDeviceImageFormatProperties with identical parameters except for the inclusion of IMAGE_USAGE_HOST_TRANSFER_BIT in usage must be identical.

Return Codes

Success

• SUCCESS

Failure

• ERROR_FORMAT_NOT_SUPPORTED

• ERROR_OUT_OF_DEVICE_MEMORY

• ERROR_OUT_OF_HOST_MEMORY

• ERROR_UNKNOWN

• ERROR_VALIDATION_FAILED

See Also

VK_VERSION_1_0, Format, ImageCreateFlags, ImageFormatProperties, ImageTiling, ImageType, ImageUsageFlags, PhysicalDevice

VkPhysicalDeviceProperties - Structure specifying physical device properties

Description

The value of apiVersion may be different than the version returned by enumerateInstanceVersion; either higher or lower. In such cases, the application must not use functionality that exceeds the version of Vulkan associated with a given object. The pApiVersion parameter returned by enumerateInstanceVersion is the version associated with a Instance and its children, except for a PhysicalDevice and its children. PhysicalDeviceProperties::apiVersion is the version associated with a PhysicalDevice and its children.

The encoding of driverVersion is implementation-defined. It may not use the same encoding as apiVersion. Applications should follow information from the vendor on how to extract the version information from driverVersion.

On implementations that claim support for the Roadmap 2022 profile, the major and minor version expressed by apiVersion must be at least Vulkan 1.3.

The vendorID and deviceID fields are provided to allow applications to adapt to device characteristics that are not adequately exposed by other Vulkan queries.

These may include performance profiles, hardware errata, or other characteristics.

The vendor identified by vendorID is the entity responsible for the most salient characteristics of the underlying implementation of the PhysicalDevice being queried.

For example, in the case of a discrete GPU implementation, this should be the GPU chipset vendor. In the case of a hardware accelerator integrated into a system-on-chip (SoC), this should be the supplier of the silicon IP used to create the accelerator.

If the vendor has a PCI vendor ID, the low 16 bits of vendorID must contain that PCI vendor ID, and the remaining bits must be zero. Otherwise, the value returned must be a valid Khronos vendor ID, obtained as described in the Vulkan Documentation and Extensions: Procedures and Conventions document in the section “Registering a Vendor ID with Khronos”. Khronos vendor IDs are allocated starting at 0x10000, to distinguish them from the PCI vendor ID namespace. Khronos vendor IDs are symbolically defined in the VendorId type.

The vendor is also responsible for the value returned in deviceID. If the implementation is driven primarily by a PCI device with a PCI device ID, the low 16 bits of deviceID must contain that PCI device ID, and the remaining bits must be zero. Otherwise, the choice of what values to return may be dictated by operating system or platform policies - but should uniquely identify both the device version and any major configuration options (for example, core count in the case of multicore devices).

The same device ID should be used for all physical implementations of that device version and configuration. For example, all uses of a specific silicon IP GPU version and configuration should use the same device ID, even if those uses occur in different SoCs.

See Also

VK_VERSION_1_0, PhysicalDeviceLimits, PhysicalDeviceProperties2, PhysicalDeviceSparseProperties, PhysicalDeviceType, getPhysicalDeviceProperties

VkApplicationInfo - Structure specifying application information

Description

Vulkan 1.0 implementations were required to return ERROR_INCOMPATIBLE_DRIVER if apiVersion was larger than 1.0. Implementations that support Vulkan 1.1 or later must not return ERROR_INCOMPATIBLE_DRIVER for any value of apiVersion .

Because Vulkan 1.0 implementations may fail with ERROR_INCOMPATIBLE_DRIVER, applications should determine the version of Vulkan available before calling createInstance. If the getInstanceProcAddr returns NULL for enumerateInstanceVersion, it is a Vulkan 1.0 implementation. Otherwise, the application can call enumerateInstanceVersion to determine the version of Vulkan.

As long as the instance supports at least Vulkan 1.1, an application can use different versions of Vulkan with an instance than it does with a device or physical device.

The Khronos validation layers will treat apiVersion as the highest API version the application targets, and will validate API usage against the minimum of that version and the implementation version (instance or device, depending on context). If an application tries to use functionality from a greater version than this, a validation error will be triggered.

For example, if the instance supports Vulkan 1.1 and three physical devices support Vulkan 1.0, Vulkan 1.1, and Vulkan 1.2, respectively, and if the application sets apiVersion to 1.2, the application can use the following versions of Vulkan:

• Vulkan 1.0 can be used with the instance and with all physical devices.

• Vulkan 1.1 can be used with the instance and with the physical devices that support Vulkan 1.1 and Vulkan 1.2.

• Vulkan 1.2 can be used with the physical device that supports Vulkan 1.2.

If we modify the above example so that the application sets apiVersion to 1.1, then the application must not use Vulkan 1.2 functionality on the physical device that supports Vulkan 1.2.

Providing a NULL InstanceCreateInfo::pApplicationInfo or providing an apiVersion of 0 is equivalent to providing an apiVersion of VK_MAKE_API_VERSION(0,1,0,0).

Valid Usage

• If apiVersion is not 0, then it must be greater than or equal to API_VERSION_1_0

Valid Usage (Implicit)

• sType must be STRUCTURE_TYPE_APPLICATION_INFO

• pNext must be NULL

• If pApplicationName is not NULL, pApplicationName must be a null-terminated UTF-8 string

• If pEngineName is not NULL, pEngineName must be a null-terminated UTF-8 string

See Also

VK_VERSION_1_0, InstanceCreateInfo, StructureType

VkInstanceCreateInfo - Structure specifying parameters of a newly created instance

Description

To capture events that occur while creating or destroying an instance, an application can link a DebugReportCallbackCreateInfoEXT structure or a DebugUtilsMessengerCreateInfoEXT structure to the pNext chain of the InstanceCreateInfo structure passed to createInstance. This callback is only valid for the duration of the createInstance and the destroyInstance call. Use createDebugReportCallbackEXT or createDebugUtilsMessengerEXT to create persistent callback objects.

An application can add additional drivers by including the DirectDriverLoadingListLUNARG structure in the pNext chain of the InstanceCreateInfo structure passed to createInstance.

DirectDriverLoadingListLUNARG allows applications to ship drivers with themselves. Only drivers that are designed to work with it should be used, such as drivers that implement Vulkan in software or that implement Vulkan by translating it to a different API. Any driver that requires installation should not be used, such as hardware drivers.

Valid Usage

• If the pNext chain of InstanceCreateInfo includes a DebugReportCallbackCreateInfoEXT structure, the list of enabled extensions in ppEnabledExtensionNames must contain VK_EXT_debug_report

• If the pNext chain of InstanceCreateInfo includes a DebugUtilsMessengerCreateInfoEXT structure, the list of enabled extensions in ppEnabledExtensionNames must contain VK_EXT_debug_utils

• If the pNext chain includes a ExportMetalObjectCreateInfoEXT structure, its exportObjectType member must be either EXPORT_METAL_OBJECT_TYPE_METAL_DEVICE_BIT_EXT or EXPORT_METAL_OBJECT_TYPE_METAL_COMMAND_QUEUE_BIT_EXT

• If flags has the INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR bit set, the list of enabled extensions in ppEnabledExtensionNames must contain VK_KHR_portability_enumeration

• If the pNext chain of InstanceCreateInfo includes a DirectDriverLoadingListLUNARG structure, the list of enabled extensions in ppEnabledExtensionNames must contain VK_LUNARG_direct_driver_loading

• If the pNext chain of InstanceCreateInfo includes a LayerSettingsCreateInfoEXT structure, the list of enabled extensions in ppEnabledExtensionNames must contain VK_EXT_layer_settings

• If the pNext chain of InstanceCreateInfo includes a ValidationFeaturesEXT structure, the list of enabled extensions in ppEnabledExtensionNames must contain VK_EXT_validation_features

• If the pNext chain of InstanceCreateInfo includes a ValidationFlagsEXT structure, the list of enabled extensions in ppEnabledExtensionNames must contain VK_EXT_validation_flags

Valid Usage (Implicit)

• sType must be STRUCTURE_TYPE_INSTANCE_CREATE_INFO

• Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid instance of DebugReportCallbackCreateInfoEXT, DebugUtilsMessengerCreateInfoEXT, DirectDriverLoadingListLUNARG, ExportMetalObjectCreateInfoEXT, LayerSettingsCreateInfoEXT, ValidationFeaturesEXT, or ValidationFlagsEXT

• The sType value of each structure in the pNext chain must be unique, with the exception of structures of type DebugUtilsMessengerCreateInfoEXT, ExportMetalObjectCreateInfoEXT, or LayerSettingsCreateInfoEXT

• flags must be a valid combination of InstanceCreateFlagBits values

• If pApplicationInfo is not NULL, pApplicationInfo must be a valid pointer to a valid ApplicationInfo structure

• If enabledLayerCount is not 0, ppEnabledLayerNames must be a valid pointer to an array of enabledLayerCount null-terminated UTF-8 strings

• If enabledExtensionCount is not 0, ppEnabledExtensionNames must be a valid pointer to an array of enabledExtensionCount null-terminated UTF-8 strings

See Also

VK_VERSION_1_0, ApplicationInfo, InstanceCreateFlags, StructureType, createInstance

VkQueueFamilyProperties - Structure providing information about a queue family

Description

The value returned in minImageTransferGranularity has a unit of compressed texel blocks for images having a block-compressed format, and a unit of texels otherwise.

Possible values of minImageTransferGranularity are:

• (0,0,0) specifies that only whole mip levels must be transferred using the image transfer operations on the corresponding queues. In this case, the following restrictions apply to all offset and extent parameters of image transfer operations:

  • The x, y, and z members of a Offset3D parameter must always be zero.

  • The width, height, and depth members of a Extent3D parameter must always match the width, height, and depth of the image subresource corresponding to the parameter, respectively.

• (Ax, Ay, Az) where Ax, Ay, and Az are all integer powers of two. In this case the following restrictions apply to all image transfer operations:

  • x, y, and z of a Offset3D parameter must be integer multiples of Ax, Ay, and Az, respectively.

  • width of a Extent3D parameter must be an integer multiple of Ax, or else x + width must equal the width of the image subresource corresponding to the parameter.

  • height of a Extent3D parameter must be an integer multiple of Ay, or else y + height must equal the height of the image subresource corresponding to the parameter.

  • depth of a Extent3D parameter must be an integer multiple of Az, or else z + depth must equal the depth of the image subresource corresponding to the parameter.

  • If the format of the image corresponding to the parameters is one of the block-compressed formats then for the purposes of the above calculations the granularity must be scaled up by the compressed texel block dimensions.

Queues supporting graphics and/or compute and/or, if the maintenance11 feature is supported, transfer operations, must report (1,1,1) in minImageTransferGranularity, meaning that there are no additional restrictions on the granularity of image transfer operations for these queues. Other queues supporting image transfer operations are only required to support whole mip level transfers, thus minImageTransferGranularity for queues belonging to such queue families may be (0,0,0).

If the maintenance11 feature is supported, QueueFamilyOptimalImageTransferGranularityPropertiesKHR::optimalImageTransferGranularity can be used to determine the optimal image transfer granularity for a particular queue family.

The Device Memory section describes memory properties queried from the physical device.

For physical device feature queries see the Features chapter.

See Also

VK_VERSION_1_0, Extent3D, QueueFamilyProperties2, QueueFlags, getPhysicalDeviceQueueFamilyProperties

VkPhysicalDeviceMemoryProperties - Structure specifying physical device memory properties

Description

The PhysicalDeviceMemoryProperties 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 memoryHeapCount and is less than or equal to MAX_MEMORY_HEAPS. Each heap is described by an element of the memoryHeaps array as a MemoryHeap structure. The number of memory types available across all memory heaps is given by memoryTypeCount and is less than or equal to MAX_MEMORY_TYPES. Each memory type is described by an element of the memoryTypes array as a MemoryType structure.

At least one heap must include MEMORY_HEAP_DEVICE_LOCAL_BIT in MemoryHeap::flags. If there are multiple heaps that all have similar performance characteristics, they may all include 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.

Memory contents within a tile memory heap, denoted by MEMORY_HEAP_TILE_MEMORY_BIT_QCOM, are only visible across the command buffers executed in a single command buffer submission batch within a queueSubmit or queueSubmit2 call. If the PhysicalDeviceTileMemoryHeapPropertiesQCOM::queueSubmitBoundary property is set, the visibility is extended across all batches in the submit call. Memory contents are discarded and made undefined after the respective submission batch or submit call. Tile memory may have different performance characteristics than non tile memory. Tile memory can be used simultaneously by command buffers in other queues without invalidating each others contents. Collectively, these rules define the tile memory scope.

Tile memory heaps work differently than most heaps as it is allowing addressing on device cache memory. Therefore, the heap’s address space is aliased across the different queues, with each queue retaining its individual copy of the heap. The implementation takes care of any required saving and restoring of the tile memory contents.

Effectively, this means that the same address in the heap in different queues have simultaneously different defined contents and the contents has a lifespan scoped to the submit or batch for that specific queues.

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

• 0

• MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT

• MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_CACHED_BIT

• MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_CACHED_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_CACHED_BIT

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_CACHED_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT

• MEMORY_PROPERTY_PROTECTED_BIT

• MEMORY_PROPERTY_PROTECTED_BIT | MEMORY_PROPERTY_DEVICE_LOCAL_BIT

• MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD

• MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_CACHED_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_CACHED_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD

• MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD | MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD

• MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_CACHED_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD | MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD | MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD | MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_CACHED_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT | MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD | MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD

• MEMORY_PROPERTY_DEVICE_LOCAL_BIT | MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV

There must be at least one memory type with both the MEMORY_PROPERTY_HOST_VISIBLE_BIT and MEMORY_PROPERTY_HOST_COHERENT_BIT bits set in its propertyFlags. There must be at least one memory type with the MEMORY_PROPERTY_DEVICE_LOCAL_BIT bit set in its propertyFlags. If the deviceCoherentMemory feature is enabled, there must be at least one memory type with the MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD bit set in its propertyFlags.

For each pair of elements X and Y returned in memoryTypes, X must be placed at a lower index position than Y if:

• the set of bit flags returned in the propertyFlags member of X is a strict subset of the set of bit flags returned in the propertyFlags member of Y; or

• the propertyFlags members of X and Y are equal, and X belongs to a memory heap with greater performance (as determined in an implementation-specific manner) ; or

• the propertyFlags members of Y includes MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD or MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD and X does not

There is no ordering requirement between X and Y elements for the case their propertyFlags members are not in a subset relation. That potentially allows more than one possible way to order the same set of memory types. Notice that the list of all allowed memory property flag combinations is written in a valid order. But if instead MEMORY_PROPERTY_DEVICE_LOCAL_BIT was before MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT, the list would still be in a valid order.

There may be a performance penalty for using device coherent or uncached device memory types, and using these accidentally is undesirable. In order to avoid this, memory types with these properties always appear at the end of the list; but are subject to the same rules otherwise.

This ordering requirement enables applications to use a simple search loop to select the desired memory type along the lines of:

// Find a memory in `memoryTypeBitsRequirement` that includes all of `requiredProperties`
int32_t findProperties(const VkPhysicalDeviceMemoryProperties* pMemoryProperties,
                       uint32_t memoryTypeBitsRequirement,
                       VkMemoryPropertyFlags requiredProperties) {
    const uint32_t memoryCount = pMemoryProperties->memoryTypeCount;
    for (uint32_t memoryIndex = 0; memoryIndex < memoryCount; ++memoryIndex) {
        const uint32_t memoryTypeBits = (1 << memoryIndex);
        const bool isRequiredMemoryType = memoryTypeBitsRequirement & memoryTypeBits;

        const VkMemoryPropertyFlags properties =
            pMemoryProperties->memoryTypes[memoryIndex].propertyFlags;
        const bool hasRequiredProperties =
            (properties & requiredProperties) == requiredProperties;

        if (isRequiredMemoryType && hasRequiredProperties)
            return static_cast<int32_t>(memoryIndex);
    }

    // failed to find memory type
    return -1;
}

// Try to find an optimal memory type, or if it does not exist try fallback memory type
// `device` is the VkDevice
// `image` is the VkImage that requires memory to be bound
// `memoryProperties` properties as returned by vkGetPhysicalDeviceMemoryProperties
// `requiredProperties` are the property flags that must be present
// `optimalProperties` are the property flags that are preferred by the application
VkMemoryRequirements memoryRequirements;
vkGetImageMemoryRequirements(device, image, &memoryRequirements);
int32_t memoryType =
    findProperties(&memoryProperties, memoryRequirements.memoryTypeBits, optimalProperties);
if (memoryType == -1) // not found; try fallback properties
    memoryType =
        findProperties(&memoryProperties, memoryRequirements.memoryTypeBits, requiredProperties);

See Also

VK_VERSION_1_0, MemoryHeap, MemoryType, PhysicalDeviceMemoryProperties2, getPhysicalDeviceMemoryProperties

VkMemoryType - Structure specifying memory type

See Also

VK_VERSION_1_0, MemoryPropertyFlags, PhysicalDeviceMemoryProperties

VkMemoryHeap - Structure specifying a memory heap

See Also

VK_VERSION_1_0, DeviceSize, MemoryHeapFlags, PhysicalDeviceMemoryProperties

VkFormatProperties - Structure specifying image format properties

Description

If no format feature flags are supported, the format itself is not supported, and images of that format cannot be created.

If format is block-compressed, requires sampler Y′CBCR conversion, or is a depth/stencil format then bufferFeatures must not support any features for the format.

If format is not a multi-plane format then linearTilingFeatures and optimalTilingFeatures must not contain FORMAT_FEATURE_DISJOINT_BIT.

See Also

VK_VERSION_1_0, FormatFeatureFlags, FormatProperties2, getPhysicalDeviceFormatProperties

VkImageFormatProperties - Structure specifying an image format properties

Members

• maxExtent are the maximum image dimensions. See the Allowed Extent Values section below for how these values are constrained by type.

• maxMipLevels is the maximum number of mipmap levels. maxMipLevels must be equal to the number of levels in the complete mipmap chain based on the maxExtent.width, maxExtent.height, and maxExtent.depth, except when one of the following conditions is true, in which case it may instead be 1:

  • getPhysicalDeviceImageFormatProperties::tiling was IMAGE_TILING_LINEAR

  • PhysicalDeviceImageFormatInfo2::tiling was IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT

  • the PhysicalDeviceImageFormatInfo2::pNext chain included a PhysicalDeviceExternalImageFormatInfo structure with a handle type included in the handleTypes member for which mipmap image support is not required

  • image format is one of the formats that require a sampler Y′CBCR conversion

  • flags contains IMAGE_CREATE_SUBSAMPLED_BIT_EXT

• maxArrayLayers is the maximum number of array layers. maxArrayLayers must be no less than PhysicalDeviceLimits::maxImageArrayLayers, except when one of the following conditions is true, in which case it may instead be 1:

  • tiling is IMAGE_TILING_LINEAR

  • tiling is IMAGE_TILING_OPTIMAL and type is IMAGE_TYPE_3D

  • format is one of the formats that require a sampler Y′CBCR conversion

• If tiling is IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT, then maxArrayLayers must not be 0.

• sampleCounts is a bitmask of SampleCountFlagBits specifying all the supported sample counts for this image as described below.

• maxResourceSize is an upper bound on the total image size in bytes, inclusive of all image subresources. Implementations may have an address space limit on total size of a resource, which is advertised by this property. maxResourceSize must be at least 231.

Description

There is no mechanism to query the size of an image before creating it, to compare that size against maxResourceSize. If an application attempts to create an image that exceeds this limit, the creation will fail and createImage will return ERROR_OUT_OF_DEVICE_MEMORY. While the advertised limit must be at least 231, it may not be possible to create an image that approaches that size, particularly for IMAGE_TYPE_1D.

If the combination of parameters to getPhysicalDeviceImageFormatProperties is not supported by the implementation for use in createImage, then all members of ImageFormatProperties will be filled with zero.

Filling ImageFormatProperties with zero for unsupported formats is an exception to the usual rule that output structures have undefined contents on error. This exception was unintentional, but is preserved for backwards compatibility.

See Also

VK_VERSION_1_0, DeviceSize, Extent3D, ExternalImageFormatPropertiesNV, ImageFormatProperties2, SampleCountFlags, getPhysicalDeviceImageFormatProperties

VkPhysicalDeviceFeatures - Structure describing the fine-grained features that can be supported by an implementation

Members

This structure describes the following features:

See Also

VK_VERSION_1_0, Bool32, DeviceCreateInfo, PhysicalDeviceFeatures2, getPhysicalDeviceFeatures

VkPhysicalDeviceSparseProperties - Structure specifying physical device sparse memory properties

See Also

VK_VERSION_1_0, Bool32, PhysicalDeviceProperties

VkPhysicalDeviceLimits - Structure reporting implementation-dependent physical device limits

Members

The PhysicalDeviceLimits are properties of the physical device. These are available in the limits member of the PhysicalDeviceProperties structure which is returned from getPhysicalDeviceProperties.

See Also

VK_VERSION_1_0, Bool32, DeviceSize, PhysicalDeviceProperties, SampleCountFlags

VkInstance - Opaque handle to an instance object

See Also

PFN_vkGetInstanceProcAddrLUNARG, VK_DEFINE_HANDLE, VK_VERSION_1_0, createAndroidSurfaceKHR, createDebugReportCallbackEXT, createDebugUtilsMessengerEXT, createDirectFBSurfaceEXT, createDisplayPlaneSurfaceKHR, createHeadlessSurfaceEXT, createIOSSurfaceMVK, createImagePipeSurfaceFUCHSIA, createInstance, createMacOSSurfaceMVK, createMetalSurfaceEXT, createScreenSurfaceQNX, createStreamDescriptorSurfaceGGP, vkCreateSurfaceOHOS, vkCreateUbmSurfaceSEC, createViSurfaceNN, createWaylandSurfaceKHR, createWin32SurfaceKHR, createXcbSurfaceKHR, createXlibSurfaceKHR, debugReportMessageEXT, destroyDebugReportCallbackEXT, destroyDebugUtilsMessengerEXT, destroyInstance, destroySurfaceKHR, enumeratePhysicalDeviceGroups, enumeratePhysicalDeviceGroups, enumeratePhysicalDevices, getInstanceProcAddr, submitDebugUtilsMessageEXT

VkPhysicalDevice - Opaque handle to a physical device object

See Also

VK_DEFINE_HANDLE, VK_VERSION_1_0, DeviceGroupDeviceCreateInfo, PhysicalDeviceGroupProperties, acquireDrmDisplayEXT, acquireWinrtDisplayNV, acquireXlibDisplayEXT, createDevice, createDisplayModeKHR, enumerateDeviceExtensionProperties, enumerateDeviceLayerProperties, vkEnumeratePhysicalDeviceQueueFamilyPerformanceCountersByRegionARM, enumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR, enumeratePhysicalDeviceShaderInstrumentationMetricsARM, enumeratePhysicalDevices, getDisplayModeProperties2KHR, getDisplayModePropertiesKHR, getDisplayPlaneCapabilities2KHR, getDisplayPlaneCapabilitiesKHR, getDisplayPlaneSupportedDisplaysKHR, getDrmDisplayEXT, getPhysicalDeviceCalibrateableTimeDomainsKHR, getPhysicalDeviceCalibrateableTimeDomainsKHR, getPhysicalDeviceCooperativeMatrixFlexibleDimensionsPropertiesNV, getPhysicalDeviceCooperativeMatrixPropertiesKHR, getPhysicalDeviceCooperativeMatrixPropertiesNV, getPhysicalDeviceCooperativeVectorPropertiesNV, getPhysicalDeviceDescriptorSizeEXT, getPhysicalDeviceDirectFBPresentationSupportEXT, getPhysicalDeviceDisplayPlaneProperties2KHR, getPhysicalDeviceDisplayPlanePropertiesKHR, getPhysicalDeviceDisplayProperties2KHR, getPhysicalDeviceDisplayPropertiesKHR, getPhysicalDeviceExternalBufferProperties, getPhysicalDeviceExternalBufferProperties, getPhysicalDeviceExternalFenceProperties, getPhysicalDeviceExternalFenceProperties, getPhysicalDeviceExternalImageFormatPropertiesNV, getPhysicalDeviceExternalSemaphoreProperties, getPhysicalDeviceExternalSemaphoreProperties, getPhysicalDeviceExternalTensorPropertiesARM, getPhysicalDeviceFeatures, getPhysicalDeviceFeatures2, getPhysicalDeviceFeatures2, getPhysicalDeviceFormatProperties, getPhysicalDeviceFormatProperties2, getPhysicalDeviceFormatProperties2, getPhysicalDeviceFragmentShadingRatesKHR, getPhysicalDeviceImageFormatProperties, getPhysicalDeviceImageFormatProperties2, getPhysicalDeviceImageFormatProperties2, getPhysicalDeviceMemoryProperties, getPhysicalDeviceMemoryProperties2, getPhysicalDeviceMemoryProperties2, getPhysicalDeviceMultisamplePropertiesEXT, getPhysicalDeviceOpticalFlowImageFormatsNV, getPhysicalDevicePresentRectanglesKHR, getPhysicalDeviceProperties, getPhysicalDeviceProperties2, getPhysicalDeviceProperties2, getPhysicalDeviceQueueFamilyDataGraphEngineOperationPropertiesARM, getPhysicalDeviceQueueFamilyDataGraphOpticalFlowImageFormatsARM, getPhysicalDeviceQueueFamilyDataGraphProcessingEnginePropertiesARM, getPhysicalDeviceQueueFamilyDataGraphPropertiesARM, getPhysicalDeviceQueueFamilyPerformanceQueryPassesKHR, getPhysicalDeviceQueueFamilyProperties, getPhysicalDeviceQueueFamilyProperties2, getPhysicalDeviceQueueFamilyProperties2, getPhysicalDeviceScreenPresentationSupportQNX, getPhysicalDeviceSparseImageFormatProperties, getPhysicalDeviceSparseImageFormatProperties2, getPhysicalDeviceSparseImageFormatProperties2, getPhysicalDeviceSupportedFramebufferMixedSamplesCombinationsNV, getPhysicalDeviceSurfaceCapabilities2EXT, getPhysicalDeviceSurfaceCapabilities2KHR, getPhysicalDeviceSurfaceCapabilitiesKHR, getPhysicalDeviceSurfaceFormats2KHR, getPhysicalDeviceSurfaceFormatsKHR, getPhysicalDeviceSurfacePresentModes2EXT, getPhysicalDeviceSurfacePresentModesKHR, getPhysicalDeviceSurfaceSupportKHR, getPhysicalDeviceToolProperties, getPhysicalDeviceToolProperties, vkGetPhysicalDeviceUbmPresentationSupportSEC, vkGetPhysicalDeviceVideoCapabilitiesKHR, vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR, vkGetPhysicalDeviceVideoFormatPropertiesKHR, getPhysicalDeviceWaylandPresentationSupportKHR, getPhysicalDeviceWin32PresentationSupportKHR, getPhysicalDeviceXcbPresentationSupportKHR, getPhysicalDeviceXlibPresentationSupportKHR, getRandROutputDisplayEXT, getWinrtDisplayNV, releaseDisplayEXT

VkAllocationCallbacks - Structure containing callback function pointers for memory allocation

Description

• pUserData is NULL or an application-defined user data pointer to be interpreted by the implementation of the callbacks. When any of the callbacks in AllocationCallbacks 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.

• pfnAllocation is a PFN_vkAllocationFunction pointer to an application-defined memory allocation function.

• pfnReallocation is a PFN_vkReallocationFunction pointer to an application-defined memory reallocation function.

• pfnFree is a PFN_vkFreeFunction pointer to an application-defined memory free function.

• pfnInternalAllocation is a PFN_vkInternalAllocationNotification pointer to an application-defined function that is called by the implementation when the implementation makes internal allocations.

• pfnInternalFree is a PFN_vkInternalFreeNotification pointer to an application-defined function that is called by the implementation when the implementation frees internal allocations.

Valid Usage

• pfnAllocation must be a valid pointer to a valid application-defined PFN_vkAllocationFunction

• pfnReallocation must be a valid pointer to a valid application-defined PFN_vkReallocationFunction

• pfnFree must be a valid pointer to a valid application-defined PFN_vkFreeFunction

• If either of pfnInternalAllocation or pfnInternalFree is not NULL, both must be valid callbacks

See Also

PFN_vkAllocationFunction, PFN_vkFreeFunction, PFN_vkInternalAllocationNotification, PFN_vkInternalFreeNotification, PFN_vkReallocationFunction, VK_VERSION_1_0, allocateMemory, createAccelerationStructure2KHR, createAccelerationStructureKHR, createAccelerationStructureNV, createAndroidSurfaceKHR, createBuffer, createBufferCollectionFUCHSIA, createBufferView, createCommandPool, createComputePipelines, createCuFunctionNVX, createCuModuleNVX, createCudaFunctionNV, createCudaModuleNV, createDataGraphPipelineSessionARM, createDataGraphPipelinesARM, createDebugReportCallbackEXT, createDebugUtilsMessengerEXT, createDeferredOperationKHR, createDescriptorPool, createDescriptorSetLayout, createDescriptorUpdateTemplate, createDescriptorUpdateTemplate, createDevice, createDirectFBSurfaceEXT, createDisplayModeKHR, createDisplayPlaneSurfaceKHR, createEvent, createExecutionGraphPipelinesAMDX, createExternalComputeQueueNV, createFence, createFramebuffer, createGpaSessionAMD, createGraphicsPipelines, createHeadlessSurfaceEXT, createIOSSurfaceMVK, createImage, createImagePipeSurfaceFUCHSIA, createImageView, createIndirectCommandsLayoutEXT, createIndirectCommandsLayoutNV, createIndirectExecutionSetEXT, createInstance, createMacOSSurfaceMVK, createMetalSurfaceEXT, createMicromapEXT, createOpticalFlowSessionNV, createPipelineBinariesKHR, createPipelineCache, createPipelineLayout, createPrivateDataSlot, createPrivateDataSlot, createQueryPool, createRayTracingPipelinesKHR, createRayTracingPipelinesNV, createRenderPass, createRenderPass2, createRenderPass2, createSampler, createSamplerYcbcrConversion, createSamplerYcbcrConversion, createScreenSurfaceQNX, createSemaphore, createShaderInstrumentationARM, createShaderModule, createShadersEXT, createSharedSwapchainsKHR, createStreamDescriptorSurfaceGGP, vkCreateSurfaceOHOS, createSwapchainKHR, createTensorARM, createTensorViewARM, vkCreateUbmSurfaceSEC, createValidationCacheEXT, createViSurfaceNN, vkCreateVideoSessionKHR, vkCreateVideoSessionParametersKHR, createWaylandSurfaceKHR, createWin32SurfaceKHR, createXcbSurfaceKHR, createXlibSurfaceKHR, destroyAccelerationStructureKHR, destroyAccelerationStructureNV, destroyBuffer, destroyBufferCollectionFUCHSIA, destroyBufferView, destroyCommandPool, destroyCuFunctionNVX, destroyCuModuleNVX, destroyCudaFunctionNV, destroyCudaModuleNV, destroyDataGraphPipelineSessionARM, destroyDebugReportCallbackEXT, destroyDebugUtilsMessengerEXT, destroyDeferredOperationKHR, destroyDescriptorPool, destroyDescriptorSetLayout, destroyDescriptorUpdateTemplate, destroyDescriptorUpdateTemplate, destroyDevice, destroyEvent, destroyExternalComputeQueueNV, destroyFence, destroyFramebuffer, destroyGpaSessionAMD, destroyImage, destroyImageView, destroyIndirectCommandsLayoutEXT, destroyIndirectCommandsLayoutNV, destroyIndirectExecutionSetEXT, destroyInstance, destroyMicromapEXT, destroyOpticalFlowSessionNV, destroyPipeline, destroyPipelineBinaryKHR, destroyPipelineCache, destroyPipelineLayout, destroyPrivateDataSlot, destroyPrivateDataSlot, destroyQueryPool, destroyRenderPass, destroySampler, destroySamplerYcbcrConversion, destroySamplerYcbcrConversion, destroySemaphore, destroyShaderEXT, destroyShaderInstrumentationARM, destroyShaderModule, destroySurfaceKHR, destroySwapchainKHR, destroyTensorARM, destroyTensorViewARM, destroyValidationCacheEXT, vkDestroyVideoSessionKHR, vkDestroyVideoSessionParametersKHR, freeMemory, registerDeviceEventEXT, registerDisplayEventEXT, releaseCapturedPipelineDataKHR

VkImageType - Specifies the type of an image object

Description

• IMAGE_TYPE_1D specifies a one-dimensional image.

• IMAGE_TYPE_2D specifies a two-dimensional image.

• IMAGE_TYPE_3D specifies a three-dimensional image.

See Also

VK_VERSION_1_0, ImageCreateInfo, PhysicalDeviceImageFormatInfo2, PhysicalDeviceSparseImageFormatInfo2, VkVideoFormatPropertiesKHR, getPhysicalDeviceExternalImageFormatPropertiesNV, getPhysicalDeviceImageFormatProperties, getPhysicalDeviceSparseImageFormatProperties

VkImageTiling - Specifies the tiling arrangement of data in an image

Description

• IMAGE_TILING_OPTIMAL specifies optimal tiling (texels are laid out in an implementation-dependent arrangement, for more efficient memory access).

• IMAGE_TILING_LINEAR specifies linear tiling (texels are laid out in memory in row-major order, possibly with some padding on each row).

• IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT specifies that the image’s tiling is defined by a Linux DRM format modifier. The modifier is specified at image creation with ImageDrmFormatModifierListCreateInfoEXT or ImageDrmFormatModifierExplicitCreateInfoEXT, and can be queried with getImageDrmFormatModifierPropertiesEXT.

See Also

VK_VERSION_1_0, ImageCreateInfo, PhysicalDeviceImageFormatInfo2, PhysicalDeviceSparseImageFormatInfo2, VkVideoFormatPropertiesKHR, getPhysicalDeviceExternalImageFormatPropertiesNV, getPhysicalDeviceImageFormatProperties, getPhysicalDeviceSparseImageFormatProperties

VkInternalAllocationType - Allocation type

Description

• INTERNAL_ALLOCATION_TYPE_EXECUTABLE specifies that the allocation is intended for execution by the host.

See Also

PFN_vkInternalAllocationNotification, PFN_vkInternalFreeNotification, VK_VERSION_1_0

VkSystemAllocationScope - Allocation scope

Description

• SYSTEM_ALLOCATION_SCOPE_COMMAND specifies that the allocation is scoped to the duration of the Vulkan command.

• SYSTEM_ALLOCATION_SCOPE_OBJECT specifies that the allocation is scoped to the lifetime of the Vulkan object that is being created or used.

• SYSTEM_ALLOCATION_SCOPE_CACHE specifies that the allocation is scoped to the lifetime of a PipelineCache or ValidationCacheEXT object.

• SYSTEM_ALLOCATION_SCOPE_DEVICE specifies that the allocation is scoped to the lifetime of the Vulkan device.

• SYSTEM_ALLOCATION_SCOPE_INSTANCE specifies that 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 an allocation scope of SYSTEM_ALLOCATION_SCOPE_OBJECT or 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 allocation scope available:

• If an allocation is scoped to the duration of a command, the allocator will use the SYSTEM_ALLOCATION_SCOPE_COMMAND allocation 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 Device has an allocator it will be used, else if the parent Instance has an allocator it will be used. Else,

• If an allocation is associated with a ValidationCacheEXT or PipelineCache object, the allocator will use the SYSTEM_ALLOCATION_SCOPE_CACHE allocation scope. The most specific allocator available is used (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 Device or Instance, the allocator will use an allocation scope of 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 an allocation scope of 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 an allocation scope of SYSTEM_ALLOCATION_SCOPE_INSTANCE.

• Otherwise an implementation will allocate memory through an alternative mechanism that is unspecified.

See Also

PFN_vkAllocationFunction, PFN_vkInternalAllocationNotification, PFN_vkInternalFreeNotification, PFN_vkReallocationFunction, VK_VERSION_1_0, AllocationCallbacks

VkPhysicalDeviceType - Supported physical device types

Description

• PHYSICAL_DEVICE_TYPE_OTHER - the device does not match any other available types.

• PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU - the device is typically one embedded in or tightly coupled with the host.

• PHYSICAL_DEVICE_TYPE_DISCRETE_GPU - the device is typically a separate processor connected to the host via an interlink.

• PHYSICAL_DEVICE_TYPE_VIRTUAL_GPU - the device is typically a virtual node in a virtualization environment.

• PHYSICAL_DEVICE_TYPE_CPU - the device is typically running on the same processors as the host.

The physical device type is advertised for informational purposes only, and does not directly affect the operation of the system. However, the device type may correlate with other advertised properties or capabilities of the system, such as how many memory heaps there are.

See Also

VK_VERSION_1_0, PhysicalDeviceProperties

VkFormat - Available image formats

Description

• FORMAT_UNDEFINED specifies that the format is not specified.

• FORMAT_R4G4_UNORM_PACK8 specifies a two-component, 8-bit packed unsigned normalized format that has a 4-bit R component in bits 4..7, and a 4-bit G component in bits 0..3.

• FORMAT_R4G4B4A4_UNORM_PACK16 specifies a four-component, 16-bit packed unsigned normalized format that has a 4-bit R component in bits 12..15, a 4-bit G component in bits 8..11, a 4-bit B component in bits 4..7, and a 4-bit A component in bits 0..3.

• FORMAT_B4G4R4A4_UNORM_PACK16 specifies a four-component, 16-bit packed unsigned normalized format that has a 4-bit B component in bits 12..15, a 4-bit G component in bits 8..11, a 4-bit R component in bits 4..7, and a 4-bit A component in bits 0..3.

• FORMAT_A4R4G4B4_UNORM_PACK16 specifies a four-component, 16-bit packed unsigned normalized format that has a 4-bit A component in bits 12..15, a 4-bit R component in bits 8..11, a 4-bit G component in bits 4..7, and a 4-bit B component in bits 0..3.

• FORMAT_A4B4G4R4_UNORM_PACK16 specifies a four-component, 16-bit packed unsigned normalized format that has a 4-bit A component in bits 12..15, a 4-bit B component in bits 8..11, a 4-bit G component in bits 4..7, and a 4-bit R component in bits 0..3.

• FORMAT_R5G6B5_UNORM_PACK16 specifies a three-component, 16-bit packed unsigned normalized format that has a 5-bit R component in bits 11..15, a 6-bit G component in bits 5..10, and a 5-bit B component in bits 0..4.

• FORMAT_B5G6R5_UNORM_PACK16 specifies a three-component, 16-bit packed unsigned normalized format that has a 5-bit B component in bits 11..15, a 6-bit G component in bits 5..10, and a 5-bit R component in bits 0..4.

• FORMAT_R5G5B5A1_UNORM_PACK16 specifies a four-component, 16-bit packed unsigned normalized format that has a 5-bit R component in bits 11..15, a 5-bit G component in bits 6..10, a 5-bit B component in bits 1..5, and a 1-bit A component in bit 0.

• FORMAT_B5G5R5A1_UNORM_PACK16 specifies a four-component, 16-bit packed unsigned normalized format that has a 5-bit B component in bits 11..15, a 5-bit G component in bits 6..10, a 5-bit R component in bits 1..5, and a 1-bit A component in bit 0.

• FORMAT_A1R5G5B5_UNORM_PACK16 specifies a four-component, 16-bit packed unsigned normalized format that has a 1-bit A component in bit 15, a 5-bit R component in bits 10..14, a 5-bit G component in bits 5..9, and a 5-bit B component in bits 0..4.

• FORMAT_A1B5G5R5_UNORM_PACK16 specifies a four-component, 16-bit packed unsigned normalized format that has a 1-bit A component in bit 15, a 5-bit B component in bits 10..14, a 5-bit G component in bits 5..9, and a 5-bit R component in bits 0..4.

• FORMAT_A8_UNORM specifies a one-component, 8-bit unsigned normalized format that has a single 8-bit A component.

• FORMAT_R8_UNORM specifies a one-component, 8-bit unsigned normalized format that has a single 8-bit R component.

• FORMAT_R8_SNORM specifies a one-component, 8-bit signed normalized format that has a single 8-bit R component.

• FORMAT_R8_USCALED specifies a one-component, 8-bit unsigned scaled integer format that has a single 8-bit R component.

• FORMAT_R8_SSCALED specifies a one-component, 8-bit signed scaled integer format that has a single 8-bit R component.

• FORMAT_R8_UINT specifies a one-component, 8-bit unsigned integer format that has a single 8-bit R component.

• FORMAT_R8_SINT specifies a one-component, 8-bit signed integer format that has a single 8-bit R component.

• FORMAT_R8_SRGB specifies a one-component, 8-bit unsigned normalized format that has a single 8-bit R component stored with sRGB nonlinear encoding.

• FORMAT_R8G8_UNORM specifies a two-component, 16-bit unsigned normalized format that has an 8-bit R component in byte 0, and an 8-bit G component in byte 1.

• FORMAT_R8G8_SNORM specifies a two-component, 16-bit signed normalized format that has an 8-bit R component in byte 0, and an 8-bit G component in byte 1.

• FORMAT_R8G8_USCALED specifies a two-component, 16-bit unsigned scaled integer format that has an 8-bit R component in byte 0, and an 8-bit G component in byte 1.

• FORMAT_R8G8_SSCALED specifies a two-component, 16-bit signed scaled integer format that has an 8-bit R component in byte 0, and an 8-bit G component in byte 1.

• FORMAT_R8G8_UINT specifies a two-component, 16-bit unsigned integer format that has an 8-bit R component in byte 0, and an 8-bit G component in byte 1.

• FORMAT_R8G8_SINT specifies a two-component, 16-bit signed integer format that has an 8-bit R component in byte 0, and an 8-bit G component in byte 1.

• FORMAT_R8G8_SRGB specifies a two-component, 16-bit unsigned normalized format that has an 8-bit R component stored with sRGB nonlinear encoding in byte 0, and an 8-bit G component stored with sRGB nonlinear encoding in byte 1.

• FORMAT_R8G8B8_UNORM specifies a three-component, 24-bit unsigned normalized format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, and an 8-bit B component in byte 2.

• FORMAT_R8G8B8_SNORM specifies a three-component, 24-bit signed normalized format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, and an 8-bit B component in byte 2.

• FORMAT_R8G8B8_USCALED specifies a three-component, 24-bit unsigned scaled format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, and an 8-bit B component in byte 2.

• FORMAT_R8G8B8_SSCALED specifies a three-component, 24-bit signed scaled format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, and an 8-bit B component in byte 2.

• FORMAT_R8G8B8_UINT specifies a three-component, 24-bit unsigned integer format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, and an 8-bit B component in byte 2.

• FORMAT_R8G8B8_SINT specifies a three-component, 24-bit signed integer format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, and an 8-bit B component in byte 2.

• FORMAT_R8G8B8_SRGB specifies a three-component, 24-bit unsigned normalized format that has an 8-bit R component stored with sRGB nonlinear encoding in byte 0, an 8-bit G component stored with sRGB nonlinear encoding in byte 1, and an 8-bit B component stored with sRGB nonlinear encoding in byte 2.

• FORMAT_B8G8R8_UNORM specifies a three-component, 24-bit unsigned normalized format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, and an 8-bit R component in byte 2.

• FORMAT_B8G8R8_SNORM specifies a three-component, 24-bit signed normalized format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, and an 8-bit R component in byte 2.

• FORMAT_B8G8R8_USCALED specifies a three-component, 24-bit unsigned scaled format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, and an 8-bit R component in byte 2.

• FORMAT_B8G8R8_SSCALED specifies a three-component, 24-bit signed scaled format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, and an 8-bit R component in byte 2.

• FORMAT_B8G8R8_UINT specifies a three-component, 24-bit unsigned integer format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, and an 8-bit R component in byte 2.

• FORMAT_B8G8R8_SINT specifies a three-component, 24-bit signed integer format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, and an 8-bit R component in byte 2.

• FORMAT_B8G8R8_SRGB specifies a three-component, 24-bit unsigned normalized format that has an 8-bit B component stored with sRGB nonlinear encoding in byte 0, an 8-bit G component stored with sRGB nonlinear encoding in byte 1, and an 8-bit R component stored with sRGB nonlinear encoding in byte 2.

• FORMAT_R8G8B8A8_UNORM specifies a four-component, 32-bit unsigned normalized format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, an 8-bit B component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_R8G8B8A8_SNORM specifies a four-component, 32-bit signed normalized format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, an 8-bit B component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_R8G8B8A8_USCALED specifies a four-component, 32-bit unsigned scaled format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, an 8-bit B component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_R8G8B8A8_SSCALED specifies a four-component, 32-bit signed scaled format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, an 8-bit B component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_R8G8B8A8_UINT specifies a four-component, 32-bit unsigned integer format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, an 8-bit B component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_R8G8B8A8_SINT specifies a four-component, 32-bit signed integer format that has an 8-bit R component in byte 0, an 8-bit G component in byte 1, an 8-bit B component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_R8G8B8A8_SRGB specifies a four-component, 32-bit unsigned normalized format that has an 8-bit R component stored with sRGB nonlinear encoding in byte 0, an 8-bit G component stored with sRGB nonlinear encoding in byte 1, an 8-bit B component stored with sRGB nonlinear encoding in byte 2, and an 8-bit A component in byte 3.

• FORMAT_B8G8R8A8_UNORM specifies a four-component, 32-bit unsigned normalized format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, an 8-bit R component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_B8G8R8A8_SNORM specifies a four-component, 32-bit signed normalized format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, an 8-bit R component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_B8G8R8A8_USCALED specifies a four-component, 32-bit unsigned scaled format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, an 8-bit R component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_B8G8R8A8_SSCALED specifies a four-component, 32-bit signed scaled format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, an 8-bit R component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_B8G8R8A8_UINT specifies a four-component, 32-bit unsigned integer format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, an 8-bit R component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_B8G8R8A8_SINT specifies a four-component, 32-bit signed integer format that has an 8-bit B component in byte 0, an 8-bit G component in byte 1, an 8-bit R component in byte 2, and an 8-bit A component in byte 3.

• FORMAT_B8G8R8A8_SRGB specifies a four-component, 32-bit unsigned normalized format that has an 8-bit B component stored with sRGB nonlinear encoding in byte 0, an 8-bit G component stored with sRGB nonlinear encoding in byte 1, an 8-bit R component stored with sRGB nonlinear encoding in byte 2, and an 8-bit A component in byte 3.

• FORMAT_A8B8G8R8_UNORM_PACK32 specifies a four-component, 32-bit packed unsigned normalized format that has an 8-bit A component in bits 24..31, an 8-bit B component in bits 16..23, an 8-bit G component in bits 8..15, and an 8-bit R component in bits 0..7.

• FORMAT_A8B8G8R8_SNORM_PACK32 specifies a four-component, 32-bit packed signed normalized format that has an 8-bit A component in bits 24..31, an 8-bit B component in bits 16..23, an 8-bit G component in bits 8..15, and an 8-bit R component in bits 0..7.

• FORMAT_A8B8G8R8_USCALED_PACK32 specifies a four-component, 32-bit packed unsigned scaled integer format that has an 8-bit A component in bits 24..31, an 8-bit B component in bits 16..23, an 8-bit G component in bits 8..15, and an 8-bit R component in bits 0..7.

• FORMAT_A8B8G8R8_SSCALED_PACK32 specifies a four-component, 32-bit packed signed scaled integer format that has an 8-bit A component in bits 24..31, an 8-bit B component in bits 16..23, an 8-bit G component in bits 8..15, and an 8-bit R component in bits 0..7.

• FORMAT_A8B8G8R8_UINT_PACK32 specifies a four-component, 32-bit packed unsigned integer format that has an 8-bit A component in bits 24..31, an 8-bit B component in bits 16..23, an 8-bit G component in bits 8..15, and an 8-bit R component in bits 0..7.

• FORMAT_A8B8G8R8_SINT_PACK32 specifies a four-component, 32-bit packed signed integer format that has an 8-bit A component in bits 24..31, an 8-bit B component in bits 16..23, an 8-bit G component in bits 8..15, and an 8-bit R component in bits 0..7.

• FORMAT_A8B8G8R8_SRGB_PACK32 specifies a four-component, 32-bit packed unsigned normalized format that has an 8-bit A component in bits 24..31, an 8-bit B component stored with sRGB nonlinear encoding in bits 16..23, an 8-bit G component stored with sRGB nonlinear encoding in bits 8..15, and an 8-bit R component stored with sRGB nonlinear encoding in bits 0..7.

• FORMAT_A2R10G10B10_UNORM_PACK32 specifies a four-component, 32-bit packed unsigned normalized format that has a 2-bit A component in bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit B component in bits 0..9.

• FORMAT_A2R10G10B10_SNORM_PACK32 specifies a four-component, 32-bit packed signed normalized format that has a 2-bit A component in bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit B component in bits 0..9.

• FORMAT_A2R10G10B10_USCALED_PACK32 specifies a four-component, 32-bit packed unsigned scaled integer format that has a 2-bit A component in bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit B component in bits 0..9.

• FORMAT_A2R10G10B10_SSCALED_PACK32 specifies a four-component, 32-bit packed signed scaled integer format that has a 2-bit A component in bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit B component in bits 0..9.

• FORMAT_A2R10G10B10_UINT_PACK32 specifies a four-component, 32-bit packed unsigned integer format that has a 2-bit A component in bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit B component in bits 0..9.

• FORMAT_A2R10G10B10_SINT_PACK32 specifies a four-component, 32-bit packed signed integer format that has a 2-bit A component in bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit B component in bits 0..9.

• FORMAT_A2B10G10R10_UNORM_PACK32 specifies a four-component, 32-bit packed unsigned normalized format that has a 2-bit A component in bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit R component in bits 0..9.

• FORMAT_A2B10G10R10_SNORM_PACK32 specifies a four-component, 32-bit packed signed normalized format that has a 2-bit A component in bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit R component in bits 0..9.

• FORMAT_A2B10G10R10_USCALED_PACK32 specifies a four-component, 32-bit packed unsigned scaled integer format that has a 2-bit A component in bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit R component in bits 0..9.

• FORMAT_A2B10G10R10_SSCALED_PACK32 specifies a four-component, 32-bit packed signed scaled integer format that has a 2-bit A component in bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit R component in bits 0..9.

• FORMAT_A2B10G10R10_UINT_PACK32 specifies a four-component, 32-bit packed unsigned integer format that has a 2-bit A component in bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit R component in bits 0..9.

• FORMAT_A2B10G10R10_SINT_PACK32 specifies a four-component, 32-bit packed signed integer format that has a 2-bit A component in bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component in bits 10..19, and a 10-bit R component in bits 0..9.

• FORMAT_R16_UNORM specifies a one-component, 16-bit unsigned normalized format that has a single 16-bit R component.

• FORMAT_R16_SNORM specifies a one-component, 16-bit signed normalized format that has a single 16-bit R component.

• FORMAT_R16_USCALED specifies a one-component, 16-bit unsigned scaled integer format that has a single 16-bit R component.

• FORMAT_R16_SSCALED specifies a one-component, 16-bit signed scaled integer format that has a single 16-bit R component.

• FORMAT_R16_UINT specifies a one-component, 16-bit unsigned integer format that has a single 16-bit R component.

• FORMAT_R16_SINT specifies a one-component, 16-bit signed integer format that has a single 16-bit R component.

• FORMAT_R16_SFLOAT specifies a one-component, 16-bit signed floating-point format that has a single 16-bit R component.

• FORMAT_R16G16_UNORM specifies a two-component, 32-bit unsigned normalized format that has a 16-bit R component in bytes 0..1, and a 16-bit G component in bytes 2..3.

• FORMAT_R16G16_SNORM specifies a two-component, 32-bit signed normalized format that has a 16-bit R component in bytes 0..1, and a 16-bit G component in bytes 2..3.

• FORMAT_R16G16_USCALED specifies a two-component, 32-bit unsigned scaled integer format that has a 16-bit R component in bytes 0..1, and a 16-bit G component in bytes 2..3.

• FORMAT_R16G16_SSCALED specifies a two-component, 32-bit signed scaled integer format that has a 16-bit R component in bytes 0..1, and a 16-bit G component in bytes 2..3.

• FORMAT_R16G16_UINT specifies a two-component, 32-bit unsigned integer format that has a 16-bit R component in bytes 0..1, and a 16-bit G component in bytes 2..3.

• FORMAT_R16G16_SINT specifies a two-component, 32-bit signed integer format that has a 16-bit R component in bytes 0..1, and a 16-bit G component in bytes 2..3.

• FORMAT_R16G16_SFLOAT specifies a two-component, 32-bit signed floating-point format that has a 16-bit R component in bytes 0..1, and a 16-bit G component in bytes 2..3.

• FORMAT_R16G16B16_UNORM specifies a three-component, 48-bit unsigned normalized format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in bytes 4..5.

• FORMAT_R16G16B16_SNORM specifies a three-component, 48-bit signed normalized format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in bytes 4..5.

• FORMAT_R16G16B16_USCALED specifies a three-component, 48-bit unsigned scaled integer format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in bytes 4..5.

• FORMAT_R16G16B16_SSCALED specifies a three-component, 48-bit signed scaled integer format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in bytes 4..5.

• FORMAT_R16G16B16_UINT specifies a three-component, 48-bit unsigned integer format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in bytes 4..5.

• FORMAT_R16G16B16_SINT specifies a three-component, 48-bit signed integer format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in bytes 4..5.

• FORMAT_R16G16B16_SFLOAT specifies a three-component, 48-bit signed floating-point format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in bytes 4..5.

• FORMAT_R16G16B16A16_UNORM specifies a four-component, 64-bit unsigned normalized format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5, and a 16-bit A component in bytes 6..7.

• FORMAT_R16G16B16A16_SNORM specifies a four-component, 64-bit signed normalized format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5, and a 16-bit A component in bytes 6..7.

• FORMAT_R16G16B16A16_USCALED specifies a four-component, 64-bit unsigned scaled integer format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5, and a 16-bit A component in bytes 6..7.

• FORMAT_R16G16B16A16_SSCALED specifies a four-component, 64-bit signed scaled integer format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5, and a 16-bit A component in bytes 6..7.

• FORMAT_R16G16B16A16_UINT specifies a four-component, 64-bit unsigned integer format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5, and a 16-bit A component in bytes 6..7.

• FORMAT_R16G16B16A16_SINT specifies a four-component, 64-bit signed integer format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5, and a 16-bit A component in bytes 6..7.

• FORMAT_R16G16B16A16_SFLOAT specifies a four-component, 64-bit signed floating-point format that has a 16-bit R component in bytes 0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5, and a 16-bit A component in bytes 6..7.

• FORMAT_R32_UINT specifies a one-component, 32-bit unsigned integer format that has a single 32-bit R component.

• FORMAT_R32_SINT specifies a one-component, 32-bit signed integer format that has a single 32-bit R component.

• FORMAT_R32_SFLOAT specifies a one-component, 32-bit signed floating-point format that has a single 32-bit R component.

• FORMAT_R32G32_UINT specifies a two-component, 64-bit unsigned integer format that has a 32-bit R component in bytes 0..3, and a 32-bit G component in bytes 4..7.

• FORMAT_R32G32_SINT specifies a two-component, 64-bit signed integer format that has a 32-bit R component in bytes 0..3, and a 32-bit G component in bytes 4..7.

• FORMAT_R32G32_SFLOAT specifies a two-component, 64-bit signed floating-point format that has a 32-bit R component in bytes 0..3, and a 32-bit G component in bytes 4..7.

• FORMAT_R32G32B32_UINT specifies a three-component, 96-bit unsigned integer format that has a 32-bit R component in bytes 0..3, a 32-bit G component in bytes 4..7, and a 32-bit B component in bytes 8..11.

• FORMAT_R32G32B32_SINT specifies a three-component, 96-bit signed integer format that has a 32-bit R component in bytes 0..3, a 32-bit G component in bytes 4..7, and a 32-bit B component in bytes 8..11.

• FORMAT_R32G32B32_SFLOAT specifies a three-component, 96-bit signed floating-point format that has a 32-bit R component in bytes 0..3, a 32-bit G component in bytes 4..7, and a 32-bit B component in bytes 8..11.

• FORMAT_R32G32B32A32_UINT specifies a four-component, 128-bit unsigned integer format that has a 32-bit R component in bytes 0..3, a 32-bit G component in bytes 4..7, a 32-bit B component in bytes 8..11, and a 32-bit A component in bytes 12..15.

• FORMAT_R32G32B32A32_SINT specifies a four-component, 128-bit signed integer format that has a 32-bit R component in bytes 0..3, a 32-bit G component in bytes 4..7, a 32-bit B component in bytes 8..11, and a 32-bit A component in bytes 12..15.

• FORMAT_R32G32B32A32_SFLOAT specifies a four-component, 128-bit signed floating-point format that has a 32-bit R component in bytes 0..3, a 32-bit G component in bytes 4..7, a 32-bit B component in bytes 8..11, and a 32-bit A component in bytes 12..15.

• FORMAT_R64_UINT specifies a one-component, 64-bit unsigned integer format that has a single 64-bit R component.

• FORMAT_R64_SINT specifies a one-component, 64-bit signed integer format that has a single 64-bit R component.

• FORMAT_R64_SFLOAT specifies a one-component, 64-bit signed floating-point format that has a single 64-bit R component.

• FORMAT_R64G64_UINT specifies a two-component, 128-bit unsigned integer format that has a 64-bit R component in bytes 0..7, and a 64-bit G component in bytes 8..15.

• FORMAT_R64G64_SINT specifies a two-component, 128-bit signed integer format that has a 64-bit R component in bytes 0..7, and a 64-bit G component in bytes 8..15.

• FORMAT_R64G64_SFLOAT specifies a two-component, 128-bit signed floating-point format that has a 64-bit R component in bytes 0..7, and a 64-bit G component in bytes 8..15.

• FORMAT_R64G64B64_UINT specifies a three-component, 192-bit unsigned integer format that has a 64-bit R component in bytes 0..7, a 64-bit G component in bytes 8..15, and a 64-bit B component in bytes 16..23.

• FORMAT_R64G64B64_SINT specifies a three-component, 192-bit signed integer format that has a 64-bit R component in bytes 0..7, a 64-bit G component in bytes 8..15, and a 64-bit B component in bytes 16..23.

• FORMAT_R64G64B64_SFLOAT specifies a three-component, 192-bit signed floating-point format that has a 64-bit R component in bytes 0..7, a 64-bit G component in bytes 8..15, and a 64-bit B component in bytes 16..23.

• FORMAT_R64G64B64A64_UINT specifies a four-component, 256-bit unsigned integer format that has a 64-bit R component in bytes 0..7, a 64-bit G component in bytes 8..15, a 64-bit B component in bytes 16..23, and a 64-bit A component in bytes 24..31.

• FORMAT_R64G64B64A64_SINT specifies a four-component, 256-bit signed integer format that has a 64-bit R component in bytes 0..7, a 64-bit G component in bytes 8..15, a 64-bit B component in bytes 16..23, and a 64-bit A component in bytes 24..31.

• FORMAT_R64G64B64A64_SFLOAT specifies a four-component, 256-bit signed floating-point format that has a 64-bit R component in bytes 0..7, a 64-bit G component in bytes 8..15, a 64-bit B component in bytes 16..23, and a 64-bit A component in bytes 24..31.

• FORMAT_B10G11R11_UFLOAT_PACK32 specifies a three-component, 32-bit packed unsigned floating-point format that has a 10-bit B component in bits 22..31, an 11-bit G component in bits 11..21, an 11-bit R component in bits 0..10. See https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#fundamentals-fp10 and https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#fundamentals-fp11.

• FORMAT_E5B9G9R9_UFLOAT_PACK32 specifies a three-component, 32-bit packed unsigned floating-point format that has a 5-bit shared exponent in bits 27..31, a 9-bit B component mantissa in bits 18..26, a 9-bit G component mantissa in bits 9..17, and a 9-bit R component mantissa in bits 0..8.

• FORMAT_D16_UNORM specifies a one-component, 16-bit unsigned normalized format that has a single 16-bit depth component.

• FORMAT_X8_D24_UNORM_PACK32 specifies a two-component, 32-bit format that has 24 unsigned normalized bits in the depth component and, optionally, 8 bits that are unused.

• FORMAT_D32_SFLOAT specifies a one-component, 32-bit signed floating-point format that has 32 bits in the depth component.

• FORMAT_S8_UINT specifies a one-component, 8-bit unsigned integer format that has 8 bits in the stencil component.

• FORMAT_D16_UNORM_S8_UINT specifies a two-component, 24-bit format that has 16 unsigned normalized bits in the depth component and 8 unsigned integer bits in the stencil component.

• FORMAT_D24_UNORM_S8_UINT specifies a two-component, 32-bit packed format that has 8 unsigned integer bits in the stencil component, and 24 unsigned normalized bits in the depth component.

• FORMAT_D32_SFLOAT_S8_UINT specifies a two-component format that has 32 signed float bits in the depth component and 8 unsigned integer bits in the stencil component. There are optionally 24 bits that are unused.

• FORMAT_BC1_RGB_UNORM_BLOCK specifies a three-component, block-compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGB texel data. This format has no alpha and is considered opaque.

• FORMAT_BC1_RGB_SRGB_BLOCK specifies a three-component, block-compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGB texel data with sRGB nonlinear encoding. This format has no alpha and is considered opaque.

• FORMAT_BC1_RGBA_UNORM_BLOCK specifies a four-component, block-compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGB texel data, and provides 1 bit of alpha.

• FORMAT_BC1_RGBA_SRGB_BLOCK specifies a four-component, block-compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGB texel data with sRGB nonlinear encoding, and provides 1 bit of alpha.

• FORMAT_BC2_UNORM_BLOCK specifies a four-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with the first 64 bits encoding alpha values followed by 64 bits encoding RGB values.

• FORMAT_BC2_SRGB_BLOCK specifies a four-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with the first 64 bits encoding alpha values followed by 64 bits encoding RGB values with sRGB nonlinear encoding.

• FORMAT_BC3_UNORM_BLOCK specifies a four-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with the first 64 bits encoding alpha values followed by 64 bits encoding RGB values.

• FORMAT_BC3_SRGB_BLOCK specifies a four-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with the first 64 bits encoding alpha values followed by 64 bits encoding RGB values with sRGB nonlinear encoding.

• FORMAT_BC4_UNORM_BLOCK specifies a one-component, block-compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized red texel data.

• FORMAT_BC4_SNORM_BLOCK specifies a one-component, block-compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of signed normalized red texel data.

• FORMAT_BC5_UNORM_BLOCK specifies a two-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RG texel data with the first 64 bits encoding red values followed by 64 bits encoding green values.

• FORMAT_BC5_SNORM_BLOCK specifies a two-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of signed normalized RG texel data with the first 64 bits encoding red values followed by 64 bits encoding green values.

• FORMAT_BC6H_UFLOAT_BLOCK specifies a three-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned floating-point RGB texel data.

• FORMAT_BC6H_SFLOAT_BLOCK specifies a three-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of signed floating-point RGB texel data.

• FORMAT_BC7_UNORM_BLOCK specifies a four-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data.

• FORMAT_BC7_SRGB_BLOCK specifies a four-component, block-compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ETC2_R8G8B8_UNORM_BLOCK specifies a three-component, ETC2 compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGB texel data. This format has no alpha and is considered opaque.

• FORMAT_ETC2_R8G8B8_SRGB_BLOCK specifies a three-component, ETC2 compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGB texel data with sRGB nonlinear encoding. This format has no alpha and is considered opaque.

• FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK specifies a four-component, ETC2 compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGB texel data, and provides 1 bit of alpha.

• FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK specifies a four-component, ETC2 compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGB texel data with sRGB nonlinear encoding, and provides 1 bit of alpha.

• FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK specifies a four-component, ETC2 compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with the first 64 bits encoding alpha values followed by 64 bits encoding RGB values.

• FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK specifies a four-component, ETC2 compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with the first 64 bits encoding alpha values followed by 64 bits encoding RGB values with sRGB nonlinear encoding applied.

• FORMAT_EAC_R11_UNORM_BLOCK specifies a one-component, ETC2 compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized red texel data.

• FORMAT_EAC_R11_SNORM_BLOCK specifies a one-component, ETC2 compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of signed normalized red texel data.

• FORMAT_EAC_R11G11_UNORM_BLOCK specifies a two-component, ETC2 compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RG texel data with the first 64 bits encoding red values followed by 64 bits encoding green values.

• FORMAT_EAC_R11G11_SNORM_BLOCK specifies a two-component, ETC2 compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of signed normalized RG texel data with the first 64 bits encoding red values followed by 64 bits encoding green values.

• FORMAT_ASTC_4x4_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_4x4_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_4x4_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_5x4_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×4 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_5x4_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×4 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_5x4_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×4 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_5x5_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_5x5_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_5x5_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_6x5_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×5 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_6x5_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×5 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_6x5_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×5 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_6x6_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_6x6_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_6x6_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_8x5_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes an 8×5 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_8x5_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes an 8×5 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_8x5_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 8×5 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_8x6_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes an 8×6 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_8x6_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes an 8×6 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_8x6_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 8×6 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_8x8_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes an 8×8 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_8x8_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes an 8×8 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_8x8_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 8×8 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_10x5_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×5 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_10x5_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×5 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_10x5_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×5 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_10x6_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×6 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_10x6_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×6 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_10x6_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×6 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_10x8_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×8 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_10x8_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×8 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_10x8_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×8 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_10x10_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×10 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_10x10_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×10 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_10x10_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 10×10 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_12x10_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 12×10 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_12x10_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 12×10 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_12x10_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 12×10 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_12x12_UNORM_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 12×12 rectangle of unsigned normalized RGBA texel data.

• FORMAT_ASTC_12x12_SRGB_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 12×12 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_12x12_SFLOAT_BLOCK specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 12×12 rectangle of signed floating-point RGBA texel data.

• FORMAT_ASTC_3x3x3_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 3×3×3 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_3x3x3_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 3×3×3 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_3x3x3_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 3×3×3 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_4x3x3_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×3×3 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_4x3x3_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×3×3 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_4x3x3_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×3×3 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_4x4x3_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4×3 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_4x4x3_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4×3 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_4x4x3_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4×3 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_4x4x4_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4×4 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_4x4x4_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4×4 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_4x4x4_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 4×4×4 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_5x4x4_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×4×4 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_5x4x4_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×4×4 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_5x4x4_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×4×4 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_5x5x4_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5×4 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_5x5x4_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5×4 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_5x5x4_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5×4 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_5x5x5_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5×5 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_5x5x5_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5×5 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_5x5x5_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 5×5×5 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_6x5x5_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×5×5 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_6x5x5_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×5×5 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_6x5x5_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×5×5 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_6x6x5_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6×5 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_6x6x5_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6×5 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_6x6x5_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6×5 cuboid of signed floating-point RGBA texel data.

• FORMAT_ASTC_6x6x6_UNORM_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6×6 cuboid of unsigned normalized RGBA texel data.

• FORMAT_ASTC_6x6x6_SRGB_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6×6 cuboid of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_ASTC_6x6x6_SFLOAT_BLOCK_EXT specifies a four-component, ASTC compressed format where each 128-bit compressed texel block encodes a 6×6×6 cuboid of signed floating-point RGBA texel data.

• FORMAT_G8B8G8R8_422_UNORM specifies a four-component, 32-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has an 8-bit G component for the even i coordinate in byte 0, an 8-bit B component in byte 1, an 8-bit G component for the odd i coordinate in byte 2, and an 8-bit R component in byte 3. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block.

• FORMAT_B8G8R8G8_422_UNORM specifies a four-component, 32-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has an 8-bit B component in byte 0, an 8-bit G component for the even i coordinate in byte 1, an 8-bit R component in byte 2, and an 8-bit G component for the odd i coordinate in byte 3. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block.

• FORMAT_G8_B8_R8_3PLANE_420_UNORM specifies an unsigned normalized multi-planar format that has an 8-bit G component in plane 0, an 8-bit B component in plane 1, and an 8-bit R component in plane 2. The horizontal and vertical dimensions of the R and B planes are halved relative to the image dimensions, and each R and B component is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G8_B8R8_2PLANE_420_UNORM specifies an unsigned normalized multi-planar format that has an 8-bit G component in plane 0, and a two-component, 16-bit BR plane 1 consisting of an 8-bit B component in byte 0 and an 8-bit R component in byte 1. The horizontal and vertical dimensions of the BR plane are halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G8_B8_R8_3PLANE_422_UNORM specifies an unsigned normalized multi-planar format that has an 8-bit G component in plane 0, an 8-bit B component in plane 1, and an 8-bit R component in plane 2. The horizontal dimension of the R and B plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane. This format only supports images with a width that is a multiple of two.

• FORMAT_G8_B8R8_2PLANE_422_UNORM specifies an unsigned normalized multi-planar format that has an 8-bit G component in plane 0, and a two-component, 16-bit BR plane 1 consisting of an 8-bit B component in byte 0 and an 8-bit R component in byte 1. The horizontal dimension of the BR plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which \left\lfloor i_G \times 0.5 \right\rfloor = i_B = i_R. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width that is a multiple of two.

• FORMAT_G8_B8_R8_3PLANE_444_UNORM specifies an unsigned normalized multi-planar format that has an 8-bit G component in plane 0, an 8-bit B component in plane 1, and an 8-bit R component in plane 2. Each plane has the same dimensions and each R, G, and B component contributes to a single texel. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane.

• FORMAT_R10X6_UNORM_PACK16 specifies a one-component, 16-bit unsigned normalized format that has a single 10-bit R component in the top 10 bits of a 16-bit word, with the bottom 6 bits unused.

• FORMAT_R10X6G10X6_UNORM_2PACK16 specifies a two-component, 32-bit unsigned normalized format that has a 10-bit R component in the top 10 bits of the word in bytes 0..1, and a 10-bit G component in the top 10 bits of the word in bytes 2..3, with the bottom 6 bits of each word unused.

• FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 specifies a four-component, 64-bit unsigned normalized format that has a 10-bit R component in the top 10 bits of the word in bytes 0..1, a 10-bit G component in the top 10 bits of the word in bytes 2..3, a 10-bit B component in the top 10 bits of the word in bytes 4..5, and a 10-bit A component in the top 10 bits of the word in bytes 6..7, with the bottom 6 bits of each word unused.

• FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16 specifies a four-component, 64-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has a 10-bit G component for the even i coordinate in the top 10 bits of the word in bytes 0..1, a 10-bit B component in the top 10 bits of the word in bytes 2..3, a 10-bit G component for the odd i coordinate in the top 10 bits of the word in bytes 4..5, and a 10-bit R component in the top 10 bits of the word in bytes 6..7, with the bottom 6 bits of each word unused. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block.

• FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16 specifies a four-component, 64-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has a 10-bit B component in the top 10 bits of the word in bytes 0..1, a 10-bit G component for the even i coordinate in the top 10 bits of the word in bytes 2..3, a 10-bit R component in the top 10 bits of the word in bytes 4..5, and a 10-bit G component for the odd i coordinate in the top 10 bits of the word in bytes 6..7, with the bottom 6 bits of each word unused. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block.

• FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 10-bit G component in the top 10 bits of each 16-bit word of plane 0, a 10-bit B component in the top 10 bits of each 16-bit word of plane 1, and a 10-bit R component in the top 10 bits of each 16-bit word of plane 2, with the bottom 6 bits of each word unused. The horizontal and vertical dimensions of the R and B planes are halved relative to the image dimensions, and each R and B component is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 10-bit G component in the top 10 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 10-bit B component in the top 10 bits of the word in bytes 0..1, and a 10-bit R component in the top 10 bits of the word in bytes 2..3, with the bottom 6 bits of each word unused. The horizontal and vertical dimensions of the BR plane are halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 10-bit G component in the top 10 bits of each 16-bit word of plane 0, a 10-bit B component in the top 10 bits of each 16-bit word of plane 1, and a 10-bit R component in the top 10 bits of each 16-bit word of plane 2, with the bottom 6 bits of each word unused. The horizontal dimension of the R and B plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane. This format only supports images with a width that is a multiple of two.

• FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 10-bit G component in the top 10 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 10-bit B component in the top 10 bits of the word in bytes 0..1, and a 10-bit R component in the top 10 bits of the word in bytes 2..3, with the bottom 6 bits of each word unused. The horizontal dimension of the BR plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which \left\lfloor i_G \times 0.5 \right\rfloor = i_B = i_R. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width that is a multiple of two.

• FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 10-bit G component in the top 10 bits of each 16-bit word of plane 0, a 10-bit B component in the top 10 bits of each 16-bit word of plane 1, and a 10-bit R component in the top 10 bits of each 16-bit word of plane 2, with the bottom 6 bits of each word unused. Each plane has the same dimensions and each R, G, and B component contributes to a single texel. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane.

• FORMAT_R12X4_UNORM_PACK16 specifies a one-component, 16-bit unsigned normalized format that has a single 12-bit R component in the top 12 bits of a 16-bit word, with the bottom 4 bits unused.

• FORMAT_R12X4G12X4_UNORM_2PACK16 specifies a two-component, 32-bit unsigned normalized format that has a 12-bit R component in the top 12 bits of the word in bytes 0..1, and a 12-bit G component in the top 12 bits of the word in bytes 2..3, with the bottom 4 bits of each word unused.

• FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16 specifies a four-component, 64-bit unsigned normalized format that has a 12-bit R component in the top 12 bits of the word in bytes 0..1, a 12-bit G component in the top 12 bits of the word in bytes 2..3, a 12-bit B component in the top 12 bits of the word in bytes 4..5, and a 12-bit A component in the top 12 bits of the word in bytes 6..7, with the bottom 4 bits of each word unused.

• FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16 specifies a four-component, 64-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has a 12-bit G component for the even i coordinate in the top 12 bits of the word in bytes 0..1, a 12-bit B component in the top 12 bits of the word in bytes 2..3, a 12-bit G component for the odd i coordinate in the top 12 bits of the word in bytes 4..5, and a 12-bit R component in the top 12 bits of the word in bytes 6..7, with the bottom 4 bits of each word unused. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block.

• FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16 specifies a four-component, 64-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has a 12-bit B component in the top 12 bits of the word in bytes 0..1, a 12-bit G component for the even i coordinate in the top 12 bits of the word in bytes 2..3, a 12-bit R component in the top 12 bits of the word in bytes 4..5, and a 12-bit G component for the odd i coordinate in the top 12 bits of the word in bytes 6..7, with the bottom 4 bits of each word unused. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block.

• FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 12-bit G component in the top 12 bits of each 16-bit word of plane 0, a 12-bit B component in the top 12 bits of each 16-bit word of plane 1, and a 12-bit R component in the top 12 bits of each 16-bit word of plane 2, with the bottom 4 bits of each word unused. The horizontal and vertical dimensions of the R and B planes are halved relative to the image dimensions, and each R and B component is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 12-bit G component in the top 12 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 12-bit B component in the top 12 bits of the word in bytes 0..1, and a 12-bit R component in the top 12 bits of the word in bytes 2..3, with the bottom 4 bits of each word unused. The horizontal and vertical dimensions of the BR plane are halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 12-bit G component in the top 12 bits of each 16-bit word of plane 0, a 12-bit B component in the top 12 bits of each 16-bit word of plane 1, and a 12-bit R component in the top 12 bits of each 16-bit word of plane 2, with the bottom 4 bits of each word unused. The horizontal dimension of the R and B plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane. This format only supports images with a width that is a multiple of two.

• FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 12-bit G component in the top 12 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 12-bit B component in the top 12 bits of the word in bytes 0..1, and a 12-bit R component in the top 12 bits of the word in bytes 2..3, with the bottom 4 bits of each word unused. The horizontal dimension of the BR plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which \left\lfloor i_G \times 0.5 \right\rfloor = i_B = i_R. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width that is a multiple of two.

• FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 12-bit G component in the top 12 bits of each 16-bit word of plane 0, a 12-bit B component in the top 12 bits of each 16-bit word of plane 1, and a 12-bit R component in the top 12 bits of each 16-bit word of plane 2, with the bottom 4 bits of each word unused. Each plane has the same dimensions and each R, G, and B component contributes to a single texel. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane.

• FORMAT_G16B16G16R16_422_UNORM specifies a four-component, 64-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has a 16-bit G component for the even i coordinate in the word in bytes 0..1, a 16-bit B component in the word in bytes 2..3, a 16-bit G component for the odd i coordinate in the word in bytes 4..5, and a 16-bit R component in the word in bytes 6..7. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block.

• FORMAT_B16G16R16G16_422_UNORM specifies a four-component, 64-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has a 16-bit B component in the word in bytes 0..1, a 16-bit G component for the even i coordinate in the word in bytes 2..3, a 16-bit R component in the word in bytes 4..5, and a 16-bit G component for the odd i coordinate in the word in bytes 6..7. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block.

• FORMAT_G16_B16_R16_3PLANE_420_UNORM specifies an unsigned normalized multi-planar format that has a 16-bit G component in each 16-bit word of plane 0, a 16-bit B component in each 16-bit word of plane 1, and a 16-bit R component in each 16-bit word of plane 2. The horizontal and vertical dimensions of the R and B planes are halved relative to the image dimensions, and each R and B component is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G16_B16R16_2PLANE_420_UNORM specifies an unsigned normalized multi-planar format that has a 16-bit G component in each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 16-bit B component in the word in bytes 0..1, and a 16-bit R component in the word in bytes 2..3. The horizontal and vertical dimensions of the BR plane are halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G16_B16_R16_3PLANE_422_UNORM specifies an unsigned normalized multi-planar format that has a 16-bit G component in each 16-bit word of plane 0, a 16-bit B component in each 16-bit word of plane 1, and a 16-bit R component in each 16-bit word of plane 2. The horizontal dimension of the R and B plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane. This format only supports images with a width that is a multiple of two.

• FORMAT_G16_B16R16_2PLANE_422_UNORM specifies an unsigned normalized multi-planar format that has a 16-bit G component in each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 16-bit B component in the word in bytes 0..1, and a 16-bit R component in the word in bytes 2..3. The horizontal dimension of the BR plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which \left\lfloor i_G \times 0.5 \right\rfloor = i_B = i_R. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width that is a multiple of two.

• FORMAT_G16_B16_R16_3PLANE_444_UNORM specifies an unsigned normalized multi-planar format that has a 16-bit G component in each 16-bit word of plane 0, a 16-bit B component in each 16-bit word of plane 1, and a 16-bit R component in each 16-bit word of plane 2. Each plane has the same dimensions and each R, G, and B component contributes to a single texel. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, IMAGE_ASPECT_PLANE_1_BIT for the B plane, and IMAGE_ASPECT_PLANE_2_BIT for the R plane.

• FORMAT_G8_B8R8_2PLANE_444_UNORM specifies an unsigned normalized multi-planar format that has an 8-bit G component in plane 0, and a two-component, 16-bit BR plane 1 consisting of an 8-bit B component in byte 0 and an 8-bit R component in byte 1. Both planes have the same dimensions and each R, G, and B component contributes to a single texel. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane.

• FORMAT_G10X6_B10X6R10X6_2PLANE_444_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 10-bit G component in the top 10 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 10-bit B component in the top 10 bits of the word in bytes 0..1, and a 10-bit R component in the top 10 bits of the word in bytes 2..3, the bottom 6 bits of each word unused. Both planes have the same dimensions and each R, G, and B component contributes to a single texel. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane.

• FORMAT_G12X4_B12X4R12X4_2PLANE_444_UNORM_3PACK16 specifies an unsigned normalized multi-planar format that has a 12-bit G component in the top 12 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 12-bit B component in the top 12 bits of the word in bytes 0..1, and a 12-bit R component in the top 12 bits of the word in bytes 2..3, the bottom 4 bits of each word unused. Both planes have the same dimensions and each R, G, and B component contributes to a single texel. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane.

• FORMAT_G16_B16R16_2PLANE_444_UNORM specifies an unsigned normalized multi-planar format that has a 16-bit G component in each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 16-bit B component in the word in bytes 0..1, and a 16-bit R component in the word in bytes 2..3. Both planes have the same dimensions and each R, G, and B component contributes to a single texel. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane.

• FORMAT_PVRTC1_2BPP_UNORM_BLOCK_IMG specifies a four-component, PVRTC compressed format where each 64-bit compressed texel block encodes an 8×4 rectangle of unsigned normalized RGBA texel data.

• FORMAT_PVRTC1_4BPP_UNORM_BLOCK_IMG specifies a four-component, PVRTC compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data.

• FORMAT_PVRTC2_2BPP_UNORM_BLOCK_IMG specifies a four-component, PVRTC compressed format where each 64-bit compressed texel block encodes an 8×4 rectangle of unsigned normalized RGBA texel data.

• FORMAT_PVRTC2_4BPP_UNORM_BLOCK_IMG specifies a four-component, PVRTC compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data.

• FORMAT_PVRTC1_2BPP_SRGB_BLOCK_IMG specifies a four-component, PVRTC compressed format where each 64-bit compressed texel block encodes an 8×4 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_PVRTC1_4BPP_SRGB_BLOCK_IMG specifies a four-component, PVRTC compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_PVRTC2_2BPP_SRGB_BLOCK_IMG specifies a four-component, PVRTC compressed format where each 64-bit compressed texel block encodes an 8×4 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_PVRTC2_4BPP_SRGB_BLOCK_IMG specifies a four-component, PVRTC compressed format where each 64-bit compressed texel block encodes a 4×4 rectangle of unsigned normalized RGBA texel data with sRGB nonlinear encoding applied to the RGB components.

• FORMAT_R16G16_SFIXED5_NV specifies a two-component, 16-bit signed fixed-point format with linear encoding. The components are signed two’s-complement integers where the most significant bit specifies the sign bit, the next 10 bits specify the integer value, and the last 5 bits represent the fractional value. The signed 16-bit values can be converted to floats in the range [-1024,1023.96875] by dividing the value by 32 (25).

• FORMAT_R10X6_UINT_PACK16_ARM specifies a one-component, 16-bit unsigned integer format that has a single 10-bit R component in the top 10 bits of a 16-bit word, with the bottom 6 bits unused.

• FORMAT_R10X6G10X6_UINT_2PACK16_ARM specifies a two-component, 32-bit unsigned integer format that has a 10-bit R component in the top 10 bits of the word in bytes 0..1, and a 10-bit G component in the top 10 bits of the word in bytes 2..3, with the bottom 6 bits of each word unused.

• FORMAT_R10X6G10X6B10X6A10X6_UINT_4PACK16_ARM specifies a four-component, 64-bit unsigned integer format that has a 10-bit R component in the top 10 bits of the word in bytes 0..1, a 10-bit G component in the top 10 bits of the word in bytes 2..3, a 10-bit B component in the top 10 bits of the word in bytes 4..5, and a 10-bit A component in the top 10 bits of the word in bytes 6..7, with the bottom 6 bits of each word unused.

• FORMAT_R12X4_UINT_PACK16_ARM specifies a one-component, 16-bit unsigned integer format that has a single 12-bit R component in the top 12 bits of a 16-bit word, with the bottom 4 bits unused.

• FORMAT_R12X4G12X4_UINT_2PACK16_ARM specifies a two-component, 32-bit unsigned integer format that has a 12-bit R component in the top 12 bits of the word in bytes 0..1, and a 12-bit G component in the top 12 bits of the word in bytes 2..3, with the bottom 4 bits of each word unused.

• FORMAT_R12X4G12X4B12X4A12X4_UINT_4PACK16_ARM specifies a four-component, 64-bit unsigned integer format that has a 12-bit R component in the top 12 bits of the word in bytes 0..1, a 12-bit G component in the top 12 bits of the word in bytes 2..3, a 12-bit B component in the top 12 bits of the word in bytes 4..5, and a 12-bit A component in the top 12 bits of the word in bytes 6..7, with the bottom 4 bits of each word unused.

• FORMAT_R14X2_UINT_PACK16_ARM specifies a one-component, 16-bit unsigned integer format that has a single 14-bit R component in the top 14 bits of a 16-bit word, with the bottom 2 bits unused.

• FORMAT_R14X2G14X2_UINT_2PACK16_ARM specifies a two-component, 32-bit unsigned integer format that has a 14-bit R component in the top 14 bits of the word in bytes 0..1, and a 14-bit G component in the top 14 bits of the word in bytes 2..3, with the bottom 2 bits of each word unused.

• FORMAT_R14X2G14X2B14X2A14X2_UINT_4PACK16_ARM specifies a four-component, 64-bit unsigned integer format that has a 14-bit R component in the top 14 bits of the word in bytes 0..1, a 14-bit G component in the top 14 bits of the word in bytes 2..3, a 14-bit B component in the top 14 bits of the word in bytes 4..5, and a 14-bit A component in the top 14 bits of the word in bytes 6..7, with the bottom 2 bits of each word unused.

• FORMAT_R14X2_UNORM_PACK16_ARM specifies a one-component, 16-bit unsigned normalized format that has a single 14-bit R component in the top 14 bits of a 16-bit word, with the bottom 2 bits unused.

• FORMAT_R14X2G14X2_UNORM_2PACK16_ARM specifies a two-component, 32-bit unsigned normalized format that has a 14-bit R component in the top 14 bits of the word in bytes 0..1, and a 14-bit G component in the top 14 bits of the word in bytes 2..3, with the bottom 2 bits of each word unused.

• FORMAT_R14X2G14X2B14X2A14X2_UNORM_4PACK16_ARM specifies a four-component, 64-bit unsigned normalized format that has a 14-bit R component in the top 14 bits of the word in bytes 0..1, a 14-bit G component in the top 14 bits of the word in bytes 2..3, a 14-bit B component in the top 14 bits of the word in bytes 4..5, and a 14-bit A component in the top 14 bits of the word in bytes 6..7, with the bottom 2 bits of each word unused.

• FORMAT_G14X2_B14X2R14X2_2PLANE_420_UNORM_3PACK16_ARM specifies an unsigned normalized multi-planar format that has a 14-bit G component in the top 14 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 14-bit B component in the top 14 bits of the word in bytes 0..1, and a 14-bit R component in the top 14 bits of the word in bytes 2..3, with the bottom 2 bits of each word unused. The horizontal and vertical dimensions of the BR plane are halved relative to the image dimensions, and each R and B value is shared with the G components for which (leftlfloor i_G times 0.5 rightrfloor = i_B = i_R) and (leftlfloor j_G times 0.5 rightrfloor = j_B = j_R). The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width and height that is a multiple of two.

• FORMAT_G14X2_B14X2R14X2_2PLANE_422_UNORM_3PACK16_ARM specifies an unsigned normalized multi-planar format that has a 14-bit G component in the top 14 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 14-bit B component in the top 14 bits of the word in bytes 0..1, and a 14-bit R component in the top 14 bits of the word in bytes 2..3, with the bottom 2 bits of each word unused. The horizontal dimension of the BR plane is halved relative to the image dimensions, and each R and B value is shared with the G components for which \left\lfloor i_G \times 0.5 \right\rfloor = i_B = i_R. The location of each plane when this image is in linear layout can be determined via getImageSubresourceLayout, using IMAGE_ASPECT_PLANE_0_BIT for the G plane, and IMAGE_ASPECT_PLANE_1_BIT for the BR plane. This format only supports images with a width that is a multiple of two.

• FORMAT_R8_BOOL_ARM specifies a one-component 8-bit boolean format that has a single 8-bit R component. See https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#fundamentals-bool.

• FORMAT_R16_SFLOAT_FPENCODING_BFLOAT16_ARM specifies a one-component, 16-bit signed floating-point format with BFLOAT16 encoding that has a single 16-bit R component.

• FORMAT_R8_SFLOAT_FPENCODING_FLOAT8E4M3_ARM specifies a one-component, 8-bit signed floating-point format with FLOAT8E4M3 encoding that has a single 8-bit R component.

• FORMAT_R8_SFLOAT_FPENCODING_FLOAT8E5M2_ARM specifies a one-component, 8-bit signed floating-point format with FLOAT8E5M2 encoding that has a single 8-bit R component.