Skip to content

turnip: Fixes for framebuffer operations with D32S8

Vulkan spec says:

When an image view of a depth/stencil image is used as a depth/stencil framebuffer attachment, the aspectMask is ignored and both depth and stencil image subresources are used.

Since we use two planes for D32S8 format we have to add a special case for depth in addition to already existing case for stencil.

Fixes hang in CTS:

 dEQP-VK.renderpass.depth_stencil_write_conditions.stencil_kill_write_d32sf_s8ui

While I was there - I found that separate stencil was not correctly stored in tu_store_gmem_attachment:

  • When resolving d32s8 to s8 we stored stencil with a wrong format.
  • For unaligned multi-sample store we used wrong gmem offset for stencil.

If unaligined store is forced this change fixes a hang in:

VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d32_sfloat_s8_uint_separate_layouts.compatibility_depth_zero_stencil_zero_testing_stencil

Fixes: b157a5d0 ("tu: Implement non-aligned multisample GMEM STORE_OP_STORE")


I'm not sure that we have a good coverage of slow paths, Maye we should add a debug option to force them and run a small CTS subset that way?


Also when testing on A660 I found that a number of tests fail when being run together, and some of them failing alone. Forcing additional syncs with syncdraw makes them all pass. It happens with and without this commit. E.g dEQP-VK.pipeline.render_to_image.core.2d.huge.width.r8g8b8a8_unorm_d32_sfloat_s8_uint

Edited by Danylo Piliaiev

Merge request reports