mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-06 07:18:17 +02:00
tu: Only emit the conditional gmem subpass resolves when gmem is possible.
No sense emitting this work when the subpass deps or attachment size prevents gmem. Noticed when I had uninit values in the tiling layout. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21004>
This commit is contained in:
parent
aae679e221
commit
3c3bd12af7
1 changed files with 25 additions and 22 deletions
|
|
@ -4518,39 +4518,42 @@ tu_CmdNextSubpass2(VkCommandBuffer commandBuffer,
|
|||
cmd->state.dirty |= TU_CMD_DIRTY_LRZ;
|
||||
}
|
||||
|
||||
tu_cond_exec_start(cs, CP_COND_EXEC_0_RENDER_MODE_GMEM);
|
||||
if (cmd->state.tiling->possible) {
|
||||
tu_cond_exec_start(cs, CP_COND_EXEC_0_RENDER_MODE_GMEM);
|
||||
|
||||
if (subpass->resolve_attachments) {
|
||||
tu6_emit_blit_scissor(cmd, cs, true);
|
||||
if (subpass->resolve_attachments) {
|
||||
tu6_emit_blit_scissor(cmd, cs, true);
|
||||
|
||||
for (unsigned i = 0; i < subpass->resolve_count; i++) {
|
||||
uint32_t a = subpass->resolve_attachments[i].attachment;
|
||||
if (a == VK_ATTACHMENT_UNUSED)
|
||||
continue;
|
||||
for (unsigned i = 0; i < subpass->resolve_count; i++) {
|
||||
uint32_t a = subpass->resolve_attachments[i].attachment;
|
||||
if (a == VK_ATTACHMENT_UNUSED)
|
||||
continue;
|
||||
|
||||
uint32_t gmem_a = tu_subpass_get_attachment_to_resolve(subpass, i);
|
||||
uint32_t gmem_a = tu_subpass_get_attachment_to_resolve(subpass, i);
|
||||
|
||||
tu_store_gmem_attachment(cmd, cs, a, gmem_a, fb->layers,
|
||||
subpass->multiview_mask, false);
|
||||
tu_store_gmem_attachment(cmd, cs, a, gmem_a, fb->layers,
|
||||
subpass->multiview_mask, false);
|
||||
|
||||
if (!pass->attachments[a].gmem)
|
||||
continue;
|
||||
if (!pass->attachments[a].gmem)
|
||||
continue;
|
||||
|
||||
/* check if the resolved attachment is needed by later subpasses,
|
||||
* if it is, should be doing a GMEM->GMEM resolve instead of GMEM->MEM->GMEM..
|
||||
*/
|
||||
perf_debug(cmd->device, "TODO: missing GMEM->GMEM resolve path\n");
|
||||
tu_load_gmem_attachment(cmd, cs, a, false, true);
|
||||
/* check if the resolved attachment is needed by later subpasses,
|
||||
* if it is, should be doing a GMEM->GMEM resolve instead of GMEM->MEM->GMEM..
|
||||
*/
|
||||
perf_debug(cmd->device, "TODO: missing GMEM->GMEM resolve path\n");
|
||||
tu_load_gmem_attachment(cmd, cs, a, false, true);
|
||||
}
|
||||
}
|
||||
|
||||
tu_cond_exec_end(cs);
|
||||
|
||||
tu_cond_exec_start(cs, CP_COND_EXEC_0_RENDER_MODE_SYSMEM);
|
||||
}
|
||||
|
||||
tu_cond_exec_end(cs);
|
||||
|
||||
tu_cond_exec_start(cs, CP_COND_EXEC_0_RENDER_MODE_SYSMEM);
|
||||
|
||||
tu6_emit_sysmem_resolves(cmd, cs, subpass);
|
||||
|
||||
tu_cond_exec_end(cs);
|
||||
if (cmd->state.tiling->possible)
|
||||
tu_cond_exec_end(cs);
|
||||
|
||||
/* Handle dependencies for the next subpass */
|
||||
tu_subpass_barrier(cmd, &cmd->state.subpass->start_barrier, false);
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue