Likely spurious validation error in texel-view-compatible CTS tests

[rg3igalia]

Environment:

• OS: Linux
• GPU and driver version: AMD RX 7600 with RADV from Mesa
• SDK or header version if building from repo: ea05bf7
• Options enabled (synchronization, best practices, etc.): defaults

Describe the Issue

Some texel-view-compatible CTS tests like dEQP-VK.image.texel_view_compatible.graphic.extended.1d_image.texture_read.bc1_rgb_unorm_block.r16g16b16a16_unorm make the layers generate VUID-vkCmdCopyBufferToImage-dstImage-00207 with the following error message:

vkCmdCopyBufferToImage(): pRegions[0].imageExtent.width (22) must be a multiple of the image (VK_FORMAT_BC1_RGB_UNORM_BLOCK) texel block width (4), or when added to imageOffset.x (0) must equal the image subresource width (24).
The Vulkan spec states: For each element of pRegions, if VkCopyCommandTransformInfoQCOM::transform is equal to VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR, the sum of imageOffset.x and extent.width does not equal the width of the subresource specified by imageSubresource, extent.width must be a multiple of the texel block extent width of the VkFormat of dstImage (https://docs.vulkan.org/spec/latest/chapters/copies.html#VUID-vkCmdCopyBufferToImage-dstImage-00207

The context is that the test generates a 1D image in BC1_RGB_UNORM format with width 22. Value 22 is chosen (apparently) to make the test more interesting because it's not a multiple of the texel block size for that format.

Then, the test generates a buffer with compressed data for the image and tries to copy that data into the image with vkCmdCopyBufferToImage. The buffer appears to meet the needed size requirements because the image size is rounded up to the nearest texel block size when doing buffer size calculations.

During the copy, the layers complain that the specified image extent width, when added to the image offset, does not equal the image subresource width, which they report as 24. If I'm not mistaken, the image subresource width is 22 so the validation error should not be reported.

Expected behavior

No validation errors.

Valid Usage ID

VUID-vkCmdCopyBufferToImage-dstImage-00207

Additional context

N/A

[rg3igalia]

Some other tests in that subset may also report VUID-vkCmdCopyBufferToImage-imageOffset-07738 for the same reason.

/cc @CreativeCylon

[ziga-lunarg]

Related to #6898

[spencer-lunarg]

ya... compressed image copies are on my January radar, please add the other CTS subsets so I can run against when working on this... these fixes would really be good to have a "known good" copy to work with (I can easily lie to myself my copy test in VVL not doing any real copy is correct)