fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-05-09 11:08:03 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

anv/sparse: don't support YCBCR 2x1 compressed formats

Browse source 
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 <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25512>
This commit is contained in:
Paulo Zanoni 2023-11-14 16:16:20 -08:00 • committed by Marge Bot
parent a0559768db
commit 563678f310
1 changed files with 20 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
src/intel/vulkan/anv_sparse.c
View file

@ -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;
}