panvk/csf: no need to flush caches after query copy

The spec says

  vkCmdCopyQueryPoolResults is considered to be a transfer operation,
  and its writes to buffer memory must be synchronized using
  VK_PIPELINE_STAGE_TRANSFER_BIT and VK_ACCESS_TRANSFER_WRITE_BIT before
  using the results.

While STORE_MULTIPLE is not exactly VK_PIPELINE_STAGE_TRANSFER_BIT /
VK_ACCESS_TRANSFER_WRITE_BIT, we can still rely on user barriers to do
the right thing (e.g., flush caches for host access).

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32697>
This commit is contained in:
Chia-I Wu 2024-12-17 21:17:46 -08:00 committed by Marge Bot
parent 8948ca1024
commit 655b7c464a

View file

@ -168,15 +168,6 @@ panvk_copy_occlusion_query_results(struct panvk_cmd_buffer *cmd,
cs_wait_slot(b, SB_ID(LS), false);
}
}
struct cs_index flush_id = cs_scratch_reg32(b, 0);
cs_move32_to(b, flush_id, 0);
/* Finally flush the cache to ensure everything is visible to
* everyone */
cs_flush_caches(b, MALI_CS_FLUSH_MODE_CLEAN, MALI_CS_FLUSH_MODE_CLEAN, false,
flush_id, cs_defer(SB_IMM_MASK, SB_ID(IMM_FLUSH)));
cs_wait_slot(b, SB_ID(IMM_FLUSH), false);
}
VKAPI_ATTR void VKAPI_CALL