# VK_EXT_host_image_copy(3) Manual Page

## Name

VK_EXT_host_image_copy - device extension

Loading… please wait.

## Registered Extension Number

271

## Revision

1

## Ratification Status

Ratified

## Extension and Version Dependencies

VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_copy_commands2
and
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3

## Deprecation State

- Promoted to Vulkan 1.4

## Contact

- Shahbaz Youssefi [GitHub]syoussefi

## Extension Proposal

VK_EXT_host_image_copy

## Other Extension Metadata

Last Modified Date

  2023-04-26

Contributors

  - Shahbaz Youssefi, Google

  - Faith Ekstrand, Collabora

  - Hans-Kristian Arntzen, Valve

  - Piers Daniell, NVIDIA

  - Jan-Harald Fredriksen, Arm

  - James Fitzpatrick, Imagination

  - Daniel Story, Nintendo

## Description

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 `VK_IMAGE_LAYOUT_GENERAL` or other host-copyable layouts via vkTransitionImageLayoutEXT. Additionally, it is possible to perform copies that preserve the swizzling layout of the image by using the `VK_HOST_IMAGE_COPY_MEMCPY_EXT` flag. In that case, the memory size needed for copies to or from a buffer can be retrieved by chaining VkSubresourceHostMemcpySizeEXT to `pLayout` in vkGetImageSubresourceLayout2EXT.

## New Commands

- vkCopyImageToImageEXT

- vkCopyImageToMemoryEXT

- vkCopyMemoryToImageEXT

- vkGetImageSubresourceLayout2EXT

- vkTransitionImageLayoutEXT

## New Structures

- VkCopyImageToImageInfoEXT

- VkCopyImageToMemoryInfoEXT

- VkCopyMemoryToImageInfoEXT

- VkHostImageLayoutTransitionInfoEXT

- VkImageSubresource2EXT

- VkImageToMemoryCopyEXT

- VkMemoryToImageCopyEXT

- VkSubresourceLayout2EXT

- Extending VkImageFormatProperties2:

  - VkHostImageCopyDevicePerformanceQueryEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceHostImageCopyFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceHostImageCopyPropertiesEXT

- Extending VkSubresourceLayout2:

  - VkSubresourceHostMemcpySizeEXT

## New Enums

- VkHostImageCopyFlagBitsEXT

## New Bitmasks

- VkHostImageCopyFlagsEXT

## New Enum Constants

- `VK_EXT_HOST_IMAGE_COPY_EXTENSION_NAME`

- `VK_EXT_HOST_IMAGE_COPY_SPEC_VERSION`

- Extending VkFormatFeatureFlagBits2:

  - `VK_FORMAT_FEATURE_2_HOST_IMAGE_TRANSFER_BIT_EXT`

- Extending VkHostImageCopyFlagBits:

  - `VK_HOST_IMAGE_COPY_MEMCPY_EXT`

- Extending VkImageUsageFlagBits:

  - `VK_IMAGE_USAGE_HOST_TRANSFER_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_COPY_IMAGE_TO_IMAGE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_COPY_IMAGE_TO_MEMORY_INFO_EXT`

  - `VK_STRUCTURE_TYPE_COPY_MEMORY_TO_IMAGE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_HOST_IMAGE_COPY_DEVICE_PERFORMANCE_QUERY_EXT`

  - `VK_STRUCTURE_TYPE_HOST_IMAGE_LAYOUT_TRANSITION_INFO_EXT`

  - `VK_STRUCTURE_TYPE_IMAGE_TO_MEMORY_COPY_EXT`

  - `VK_STRUCTURE_TYPE_MEMORY_TO_IMAGE_COPY_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_IMAGE_COPY_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_IMAGE_COPY_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_SUBRESOURCE_HOST_MEMCPY_SIZE_EXT`

## 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 `VK_QUEUE_GRAPHICS_BIT` queue must support either:

- the `hostImageCopy` feature; or

- an additional queue that supports `VK_QUEUE_TRANSFER_BIT`.

Additionally, all queues supporting `VK_QUEUE_GRAPHICS_BIT` or `VK_QUEUE_COMPUTE_BIT` must also advertise `VK_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 `VkDeviceMemory` bound to a buffer (instead of host memory), and use vkCmdCopyBufferToImage? 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.

## Version History

- Revision 0, 2021-01-20 (Faith Ekstrand)

  - Initial idea and xml

- Revision 1, 2023-04-26 (Shahbaz Youssefi)

  - Initial revision

## See Also

No cross-references are available

## Document Notes

For more information, see the Vulkan Specification

This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.

## Copyright

Copyright 2014-2024 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0