In
dEQP-VK.renderpass.dedicated_allocation.attachment_allocation.input_output.94
we have the following:
- There is more than one subpass, but only one depth attachment.
- The first subpass doesn't use depth.
- The subpass that does use depth has a draw call in a secondary.
We wouldn't hit the case where there's more than one depth attachment,
but because tu_begin_resumed_renderpass() only looked at the first
subpass it wouldn't find the depth attachment and would leave LRZ
invalid and thus a NULL LRZ fast-clear base. Then
tu_begin_secondary_cmdbuf() would leave LRZ enabled and the draw would
have LRZ enabled, leading to a hang.
Fix this by making tu_begin_resumed_renderpass() match
tu_begin_renderpass() with how it finds the depth attachment.
Fixes:
4b5f0d98 ("tu: Overhaul LRZ, implement on-GPU dir tracking and LRZ fast-clear")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18369>
{
/* Track LRZ valid state */
memset(&cmd->state.lrz, 0, sizeof(cmd->state.lrz));
- uint32_t a = cmd->state.subpass->depth_stencil_attachment.attachment;
- if (a != VK_ATTACHMENT_UNUSED) {
+
+ uint32_t a;
+ for (a = 0; a < cmd->state.pass->attachment_count; a++) {
+ if (cmd->state.attachments[a]->image->lrz_height)
+ break;
+ }
+
+ if (a != cmd->state.pass->attachment_count) {
const struct tu_render_pass_attachment *att = &cmd->state.pass->attachments[a];
tu_lrz_init_state(cmd, att, cmd->state.attachments[a]);
if (att->clear_mask & (VK_IMAGE_ASPECT_COLOR_BIT | VK_IMAGE_ASPECT_DEPTH_BIT)) {