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:
- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
- Extending VkPhysicalDeviceProperties2:
- Extending VkSubresourceLayout2KHR:
New Enums
New Bitmasks
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 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
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