Module: Mesa Branch: main Commit: 563678f310e51b28355f35d0c9763f39616d96e8 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=563678f310e51b28355f35d0c9763f39616d96e8
Author: Paulo Zanoni <[email protected]> Date: Tue Nov 14 16:16:20 2023 -0800 anv/sparse: don't support YCBCR 2x1 compressed formats Regarding supporting these formats, the spec says: "A sparse image created using VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT supports all non-compressed color formats with power-of-two element size that non-sparse usage supports. Additional formats may also be supported and can be queried via vkGetPhysicalDeviceSparseImageFormatProperties. VK_IMAGE_TILING_LINEAR tiling is not supported." Regarding the formats themselves, the spec says: "VK_FORMAT_B8G8R8G8_422_UNORM specifies a four-component, 32-bit format containing a pair of G components, an R component, and a B component, collectively encoding a 2×1 rectangle of unsigned normalized RGB texel data. One G value is present at each i coordinate, with the B and R values shared across both G values and thus recorded at half the horizontal resolution of the image. This format has an 8-bit B component in byte 0, an 8-bit G component for the even i coordinate in byte 1, an 8-bit R component in byte 2, and an 8-bit G component for the odd i coordinate in byte 3. This format only supports images with a width that is a multiple of two. For the purposes of the constraints on copy extents, this format is treated as a compressed format with a 2×1 compressed texel block." Since these formats are to be considered compressed 2x1 blocks and we don't necessarily have to support non-compressed formats that non-sparse support, we can claim them as not supported with sparse. In addition to all of that, if you look at isl_gfx125_filter_tiling() you'll see that we don't even support Tile64 for these formats, so sparse residency (i.e., non-opaque image binds) doesn't really make sense for them yet. The Vulkan spec defines 4 other YCBCR "2x1 compressed" formats like the ones we have in this commit, but we don't support them even without sparse, so there's no reason to check them here. A recent change in VK-GL-CTS made tests that use these formats go from unsupported to failures: 7ecc7716a983 ("Do not use and check for STORAGE image support, when it is not used in the test") This commit "fixes" the following VK-GL-CTS failures (by making them return NotSupported): dEQP-VK.sparse_resources.image_block_shapes.2d.b8g8r8g8_422_unorm.samples_1 dEQP-VK.sparse_resources.image_block_shapes.2d.g8b8g8r8_422_unorm.samples_1 dEQP-VK.sparse_resources.image_block_shapes.2d_array.b8g8r8g8_422_unorm.samples_1 dEQP-VK.sparse_resources.image_block_shapes.2d_array.g8b8g8r8_422_unorm.samples_1 Reviewed-by: Lionel Landwerlin <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25512> --- src/intel/vulkan/anv_sparse.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/intel/vulkan/anv_sparse.c b/src/intel/vulkan/anv_sparse.c index 381ab9c9fc3..933d31e84ce 100644 --- a/src/intel/vulkan/anv_sparse.c +++ b/src/intel/vulkan/anv_sparse.c @@ -815,6 +815,14 @@ anv_sparse_calc_image_format_properties(struct anv_physical_device *pdevice, granularity.height == std_shape.height && granularity.depth == std_shape.depth; + /* TODO: dEQP seems to care about the block shapes being standard even + * for the cases where is_known_nonstandard_format is true. Luckily as + * of today all of those cases are NotSupported but sooner or later we + * may end up getting a failure. + * Notice that in practice we report these cases as having the mip tail + * starting on mip level 0, so the reported block shapes are irrelevant + * since non-opaque binds are not supported. Still, dEQP seems to care. + */ assert(is_standard || is_known_nonstandard_format); } @@ -1210,6 +1218,18 @@ anv_sparse_image_check_support(struct anv_physical_device *pdevice, return VK_ERROR_FORMAT_NOT_SUPPORTED; } + /* These YUV formats are considered by Vulkan to be compressed 2x1 blocks. + * We don't need to support them since they're compressed. On Gfx12 we + * can't even have Tile64 for them. Once we do support these formats we'll + * have to report the correct block shapes because dEQP cares about them, + * and we'll have to adjust for the fact that ISL treats these as 16bpp 1x1 + * blocks instead of 32bpp 2x1 compressed blocks (as block shapes are + * reported in units of compressed blocks). + */ + if (vk_format == VK_FORMAT_G8B8G8R8_422_UNORM || + vk_format == VK_FORMAT_B8G8R8G8_422_UNORM) + return VK_ERROR_FORMAT_NOT_SUPPORTED; + return VK_SUCCESS; }
