This extension allows applications to copy data between host memory and images on the host processor, without staging the data through a GPU-accessible buffer. This removes the need to allocate and manage the buffer and its associated memory. On some architectures it may also eliminate an extra copy operation. This extension additionally allows applications to copy data between images on the host.

To support initializing a new image in preparation for a host copy, it is now possible to transition a new image to IMAGE_LAYOUT_GENERAL or other host-copyable layouts via transitionImageLayoutEXT. Additionally, it is possible to perform copies that preserve the swizzling layout of the image by using the HOST_IMAGE_COPY_MEMCPY_BIT_EXT flag. In that case, the memory size needed for copies to or from a buffer can be retrieved by chaining SubresourceHostMemcpySizeEXT to pLayout in getImageSubresourceLayout2EXT.

New Commands

copyImageToImageEXT

New Structures

CopyImageToImageInfoEXT

CopyImageToMemoryInfoEXT
CopyMemoryToImageInfoEXT
HostImageLayoutTransitionInfoEXT
ImageSubresource2EXT
ImageToMemoryCopyEXT
MemoryToImageCopyEXT
SubresourceLayout2EXT
Extending ImageFormatProperties2:
- HostImageCopyDevicePerformanceQueryEXT
Extending PhysicalDeviceFeatures2, DeviceCreateInfo:
- PhysicalDeviceHostImageCopyFeaturesEXT
Extending PhysicalDeviceProperties2:
- PhysicalDeviceHostImageCopyPropertiesEXT
Extending SubresourceLayout2:
- SubresourceHostMemcpySizeEXT

New Enums

HostImageCopyFlagBitsEXT

New Bitmasks

HostImageCopyFlagsEXT

New Enum Constants

EXT_HOST_IMAGE_COPY_EXTENSION_NAME

Promotion to Vulkan 1.4

Functionality in this extension is included in core Vulkan 1.4, with the EXT suffix omitted. However, the feature is made optional in Vulkan 1.4. The original type, enum, and command names are still available as aliases of the core functionality.

A Vulkan 1.4 implementation that has a QUEUE_GRAPHICS_BIT queue must support either:

the hostImageCopy feature; or
an additional queue that supports QUEUE_TRANSFER_BIT.

Additionally, all queues supporting QUEUE_GRAPHICS_BIT or QUEUE_COMPUTE_BIT must also advertise QUEUE_TRANSFER_BIT.

Issues

1) When uploading data to an image, the data is usually loaded from disk. Why not have the application load the data directly into a DeviceMemory bound to a buffer (instead of host memory), and use cmdCopyBufferToImage? The same could be done when downloading data from an image.

RESOLVED: This may not always be possible. Complicated Vulkan applications such as game engines often have decoupled subsystems for streaming data and rendering. It may be unreasonable to require the streaming subsystem to coordinate with the rendering subsystem to allocate memory on its behalf, especially as Vulkan may not be the only API supported by the engine. In emulation layers, the image data is necessarily provided by the application in host memory, so an optimization as suggested is not possible. Most importantly, the device memory may not be mappable by an application, but still accessible to the driver.

2) Are optimalBufferCopyOffsetAlignment and optimalBufferCopyRowPitchAlignment applicable to host memory as well with the functions introduced by this extension? Or should there be new limits?

RESOLVED: No alignment requirements for the host memory pointer.

3) Should there be granularity requirements for image offsets and extents?

RESOLVED: No granularity requirements, i.e. a granularity of 1 pixel (for non-compressed formats) and 1 texel block (for compressed formats) is assumed.

4) How should the application deal with layout transitions before or after copying to or from images?

RESOLVED: An existing issue with linear images is that when emulating other APIs, it is impossible to know when to transition them as they are written to by the host and then used bindlessly. The copy operations in this extension are affected by the same limitation. A new command is thus introduced by this extension to address this problem by allowing the host to perform an image layout transition between a handful of layouts.