fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2025-12-28 03:50:13 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

anv/sparse: reject 1D sparse residency images

Browse source 
The Vulkan spec splits sparse resources in two different features:
sparse binding and sparse residency.

Sparse binding is much simpler. It requires the resources to be fully
bound before being used and it treats them as a black box. We're
required to support sparse binding for all the formats that are
supported by non-sparse, but that's easy beacause this feature is
simpler.

Now sparse residency is the one where we're allowed to partially bind
resources, and the one that comes with more complicated features such
as block shapes and non-opaque binding of images. This feature is
subdivided into:
  - sparseResidencyBuffer
  - sparseResidencyImage2D
  - sparseResidencyImage3D
  - sparseResidency{2,4,8,16}Samples (which refers to 2D images)

Notice that there's no sparseResidencyImage1D. And if you read the
specs it's clear that sparse residency is meant for non-1D images.
Still, supporting it didn't require any extra effort in Anv so we just
did it.

That's until we started running GL CTS tests on Zink. There's a CTS
test that checks for the standard block shapes. It creates 1D images
and expects the block shapes for them to be the standard 2D block
shapes. While we could very well just patch
anv_sparse_calc_image_format_properties() to return the standard 2D
block shapes for 1D images, that's just wrong (block shapes for 1D
images are just line segments, not rectangles!) so let's just reject
this all until maybe one day Vulkan defines sparseResidencyImage1D and
we get GL_ARB_sparse_texture3 to match it, or somebody decides to
change the GL CTS test.

Testcase: KHR-GL46.sparse_texture2_tests.StandardPageSizesTestCase
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/29337>
This commit is contained in:
Paulo Zanoni 2024-05-16 12:28:33 -07:00 • committed by Marge Bot
parent 21d3eacd23
commit 5c18ccd2d3
2 changed files with 40 additions and 40 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
src/gallium/drivers/zink/ci/zink-anv-tgl-fails.txt
View file

@ -584,9 +584,6 @@ spec@arb_fragment_layer_viewport@layer-no-gs,Fail
# issues.
KHR-GL46.sparse_texture_tests.SparseTextureCommitment,Crash
# Test fails because it expects 1D images to have 2D block shapes
KHR-GL46.sparse_texture2_tests.StandardPageSizesTestCase,Fail
# Issue 11073 constains a big explanation on why this fails. The test is using a
# 2D_3D compatible format that ends up being marked by Anv as "everything is
# miptail" and the test is not expecting that.

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

@ -890,46 +890,46 @@ anv_sparse_calc_image_format_properties(struct anv_physical_device *pdevice,
bool is_standard = false;
bool is_known_nonstandard_format = false;
if (vk_image_type != VK_IMAGE_TYPE_1D) {
VkExtent3D std_shape =
anv_sparse_get_standard_image_block_shape(surf->format,
vk_image_type, vk_samples,
bpb);
/* YUV formats don't work with Tile64, which is required if we want to
* claim standard block shapes. The spec requires us to support all
* non-compressed color formats that non-sparse supports, so we can't
* just say YUV formats are not supported by Sparse. So we end
* supporting this format and anv_sparse_calc_miptail_properties() will
* say that everything is part of the miptail.
*
* For more details on the hardware restriction, please check
* isl_gfx125_filter_tiling().
*/
if (pdevice->info.verx10 >= 125 && isl_format_is_yuv(surf->format))
is_known_nonstandard_format = true;
/* We shouldn't be able to reach this function with a 1D image. */
assert(vk_image_type != VK_IMAGE_TYPE_1D);
/* The standard block shapes (and by extension, the tiling formats they
* require) are simply incompatible with getting a 2D view of a 3D
* image.
*/
if (surf->usage & ISL_SURF_USAGE_2D_3D_COMPATIBLE_BIT)
is_known_nonstandard_format = true;
VkExtent3D std_shape =
anv_sparse_get_standard_image_block_shape(surf->format,
vk_image_type, vk_samples,
bpb);
/* YUV formats don't work with Tile64, which is required if we want to
* claim standard block shapes. The spec requires us to support all
* non-compressed color formats that non-sparse supports, so we can't just
* say YUV formats are not supported by Sparse. So we end supporting this
* format and anv_sparse_calc_miptail_properties() will say that everything
* is part of the miptail.
*
* For more details on the hardware restriction, please check
* isl_gfx125_filter_tiling().
*/
if (pdevice->info.verx10 >= 125 && isl_format_is_yuv(surf->format))
is_known_nonstandard_format = true;
is_standard = granularity.width == std_shape.width &&
granularity.height == std_shape.height &&
granularity.depth == std_shape.depth;
/* The standard block shapes (and by extension, the tiling formats they
* require) are simply incompatible with getting a 2D view of a 3D image.
*/
if (surf->usage & ISL_SURF_USAGE_2D_3D_COMPATIBLE_BIT)
is_known_nonstandard_format = true;
/* 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);
assert(!(is_standard && is_known_nonstandard_format));
}
is_standard = granularity.width == std_shape.width &&
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);
assert(!(is_standard && is_known_nonstandard_format));
uint32_t block_size = granularity.width * granularity.height *
granularity.depth * Bpb;
@ -1278,6 +1278,9 @@ anv_sparse_image_check_support(struct anv_physical_device *pdevice,
if (!(flags & VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT))
return VK_SUCCESS;
if (type == VK_IMAGE_TYPE_1D)
return VK_ERROR_FORMAT_NOT_SUPPORTED;
/* From here on, these are the rules:
* "A sparse image created using VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT
* supports all non-compressed color formats with power-of-two element