1// Copyright 2021-2024 The Khronos Group Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_EXT_host_image_copy.adoc[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2023-04-26 11*Contributors*:: 12 - Shahbaz Youssefi, Google 13 - Faith Ekstrand, Collabora 14 - Hans-Kristian Arntzen, Valve 15 - Piers Daniell, NVIDIA 16 - Jan-Harald Fredriksen, Arm 17 - James Fitzpatrick, Imagination 18 - Daniel Story, Nintendo 19 20=== Description 21 22This extension allows applications to copy data between host memory and 23images on the host processor, without staging the data through a 24GPU-accessible buffer. 25This removes the need to allocate and manage the buffer and its associated 26memory. 27On some architectures it may also eliminate an extra copy operation. 28This extension additionally allows applications to copy data between images 29on the host. 30 31To support initializing a new image in preparation for a host copy, it is 32now possible to transition a new image to ename:VK_IMAGE_LAYOUT_GENERAL or 33other host-copyable layouts via flink:vkTransitionImageLayoutEXT. 34Additionally, it is possible to perform copies that preserve the swizzling 35layout of the image by using the ename:VK_HOST_IMAGE_COPY_MEMCPY_EXT flag. 36In that case, the memory size needed for copies to or from a buffer can be 37retrieved by chaining slink:VkSubresourceHostMemcpySizeEXT to pname:pLayout 38in flink:vkGetImageSubresourceLayout2EXT. 39 40include::{generated}/interfaces/VK_EXT_host_image_copy.adoc[] 41 42=== Issues 43 441) When uploading data to an image, the data is usually loaded from disk. 45Why not have the application load the data directly into a `VkDeviceMemory` 46bound to a buffer (instead of host memory), and use 47flink:vkCmdCopyBufferToImage? The same could be done when downloading data 48from an image. 49 50*RESOLVED*: This may not always be possible. 51Complicated Vulkan applications such as game engines often have decoupled 52subsystems for streaming data and rendering. 53It may be unreasonable to require the streaming subsystem to coordinate with 54the rendering subsystem to allocate memory on its behalf, especially as 55Vulkan may not be the only API supported by the engine. 56In emulation layers, the image data is necessarily provided by the 57application in host memory, so an optimization as suggested is not possible. 58Most importantly, the device memory may not be mappable by an application, 59but still accessible to the driver. 60 612) Are `optimalBufferCopyOffsetAlignment` and 62`optimalBufferCopyRowPitchAlignment` applicable to host memory as well with 63the functions introduced by this extension? Or should there be new limits? 64 65*RESOLVED*: No alignment requirements for the host memory pointer. 66 673) Should there be granularity requirements for image offsets and extents? 68 69*RESOLVED*: No granularity requirements, i.e. a granularity of 1 pixel (for 70non-compressed formats) and 1 texel block (for compressed formats) is 71assumed. 72 734) How should the application deal with layout transitions before or after 74copying to or from images? 75 76*RESOLVED*: An existing issue with linear images is that when emulating 77other APIs, it is impossible to know when to transition them as they are 78written to by the host and then used bindlessly. 79The copy operations in this extension are affected by the same limitation. 80A new command is thus introduced by this extension to address this problem 81by allowing the host to perform an image layout transition between a handful 82of layouts. 83 84=== Version History 85 86 * Revision 0, 2021-01-20 (Faith Ekstrand) 87 ** Initial idea and xml 88 89 * Revision 1, 2023-04-26 (Shahbaz Youssefi) 90 ** Initial revision 91