From 93fba403898eb057182777afc9e12aff9a6933c7 Mon Sep 17 00:00:00 2001 From: Lionel Landwerlin Date: Mon, 26 Aug 2024 14:43:58 +0300 Subject: [PATCH] brw: switch mesh/task URB fence prior to EOT to GPU Signed-off-by: Lionel Landwerlin Cc: mesa-stable Reviewed-by: Sagar Ghuge Reviewed-by: Rohan Garg Part-of: --- src/intel/compiler/brw_compile_mesh.cpp | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/intel/compiler/brw_compile_mesh.cpp b/src/intel/compiler/brw_compile_mesh.cpp index dffd5effceb..386e271fa34 100644 --- a/src/intel/compiler/brw_compile_mesh.cpp +++ b/src/intel/compiler/brw_compile_mesh.cpp @@ -270,7 +270,18 @@ brw_emit_urb_fence(fs_visitor &s) brw_imm_ud(true), brw_imm_ud(0)); fence->sfid = BRW_SFID_URB; - fence->desc = lsc_fence_msg_desc(s.devinfo, LSC_FENCE_LOCAL, + /* The logical thing here would likely be a THREADGROUP fence but that's + * still failing some tests like in dEQP-VK.mesh_shader.ext.query.* + * + * Gfx12.5 has a comment about this on BSpec 53533 : + * + * "If fence scope is Local or Threadgroup, HW ignores the flush type + * and operates as if it was set to None (no flush)" + * + * Software workaround from HSD-22014129519 indicates that a GPU fence + * resolves the issue. + */ + fence->desc = lsc_fence_msg_desc(s.devinfo, LSC_FENCE_GPU, LSC_FLUSH_TYPE_NONE, true); bld.exec_all().group(1, 0).emit(FS_OPCODE_SCHEDULING_FENCE,