pvr: fix handling of invalid attachment info in pvr_init_fs_outputs_mrt

The attachments field of the render pass state could be
MESA_VK_RP_ATTACHMENT_INFO_INVALID, which indicates no attachment
information is valid. If such situation really happens when initializing
the fragment state of a pipeline, this means neither a render pass nor a
VkPipelineRenderingCreateInfo structure is available -- in this case,
the specificiation for that structure says colorAttachmentCount is
considered as 0, so the loop iterating color attachments should just not
happen.

Skip iterating color attachments if the render pass has a attachments
field with value MESA_VK_RP_ATTACHMENT_INFO.

This fixes some regression on the Vulkan CTS testcase
dEQP-VK.pipeline.monolithic.misc.no_rendering introduced by !40870, in
which MESA_VK_RP_ATTACHMENT_INFO instead of 0 is set as the value of the
attachments field of the render pass state, if neither a render pass nor
the VkPipelineRenderingCreateInfo structure is available.

Fixes: 1950b6c1a7 ("vulkan: mark RP attachments as invalid when no rendering create info")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Acked-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41032>
This commit is contained in:
Icenowy Zheng 2026-04-17 23:38:45 +08:00 committed by Marge Bot
parent 85cb633871
commit 351eaffdc5

View file

@ -2016,6 +2016,9 @@ static void pvr_init_fs_outputs_mrt(pco_data *data,
unsigned u;
pco_fs_data *fs = &data->fs;
if (!vk_render_pass_state_has_attachment_info(rp))
goto early_exit;
for (u = 0; u < PVR_MAX_COLOR_ATTACHMENTS; u++) {
if (!(rp->attachments & MESA_VK_RP_ATTACHMENT_COLOR_BIT(u)))
continue;
@ -2036,6 +2039,7 @@ static void pvr_init_fs_outputs_mrt(pco_data *data,
}
}
early_exit:
fs->z_replicate = ~0u;
}