Skip to content

Mapping between Optimal Tiling Image Data and Memory with VK_HOST_IMAGE_COPY_MEMCPY_BIT  #2754

Description

@Erfan-Ahmadi

What is this about?

In certain applications, we'd like to know how TILING_OPTIMAL image data maps to memory. not per-pixel level, but knowing memory offsets of arrayLayers or mipLevels could be advantageous. as it allows aliasing multi-layer images with less restrictions on format and texel block size. (See Following #2723)

Additionally we'd like to be able to retrieve optimal tiling images, cache them (in case of VT pages), and re-upload them to GPU.
I am aware of VK_HOST_IMAGE_COPY_MEMCPY_BIT as it does exactly that. but it doesn't give us the information about memory offset of a layer or mipmap.

host_image_copy indirectly hints that the mapping exists.

When VK_HOST_IMAGE_COPY_MEMCPY_BIT is used when using vkCopyMemoryToImage and vkCopyImageToMemory there are a few restrictions

VUID-VkCopyMemoryToImageInfo-imageOffset-09114
If flags contains VK_HOST_IMAGE_COPY_MEMCPY_BIT, the x, y, and z members of the imageOffset member of each element of pRegions must be 0

VUID-VkCopyMemoryToImageInfo-dstImage-09115
If flags contains VK_HOST_IMAGE_COPY_MEMCPY_BIT, the imageExtent member of each element of pRegions must equal the extents of dstImage identified by imageSubresource

which restricts offset and extents of the subresources. but it doesn't restrict arrayLayers or mipLevel

What does that mean?

That means we could access TILING_OPTIMAL images layer by layer and mip by mip.
which means the images are all one continuous array of textiles.

Yes we could know their size by using VkSubresourceHostMemcpySize in pNext chain of VkSubresourceLayout2 structure in a call to vkGetImageSubresourceLayout2.

The documentation regarding layout of TILING_OPTIMAL states:

It is legal to call vkGetImageSubresourceLayout2 with an image created with tiling equal to VK_IMAGE_TILING_OPTIMAL, but the members of VkSubresourceLayout2::subresourceLayout will have undefined values in this case.

which essentially says, we only can know about the host size needed to copy each subresource.

What do we want?

Other than the size of each optimal tiling subresource, we want functionality to know the memory offset of each subresource and potentially it's arrayPitch.

Suggestion:
I know there is probably a lot of interactions with other features such as SPARSE_RESIDENCY but under normal conditions it would be great if vkGetImageSubresourceLayout2 would have defined valid values for offset and arrayPitch for TILING_OPTIMAL images as well

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions