brw: Eliminate the BTI source from MEMORY_FENCE/INTERLOCK opcodes

Memory fences do not refer to an element of a binding table.  Rather,
the reason we had "BTI" in these opcodes was to distinguish what in
modern terms are called UGM (untyped memory data cache) vs. SLM
(cross-thread shared local memory) fences.

Icelake and older platforms used the "data cache" SFID for both
purposes, distinguishing them by having a special binding table
index, 254, meaning "this is actually SLM access".  This is where
the notion that fences had BTIs came in.  (In fact, prior to Icelake,
separate SLM fences were not a thing, so BTI wasn't used there either.)

To avoid confusion about BTI being involved, we choose a simpler lie: we
have Icelake SLM fences target GFX12_SFID_SLM (like modern platforms
would), even though it didn't really exist back then.  Later lowering
code sets it back to the correct Data Cache SFID with magic SLM binding
table index.  This eliminates BTI everywhere and an unnecessary source.

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33297>
This commit is contained in:
Kenneth Graunke
2025-01-18 00:48:10 -08:00
committed by Marge Bot
parent 43d0ac9eb4
commit b9de19f917
8 changed files with 35 additions and 36 deletions
+1 -3
View File
@@ -1196,7 +1196,6 @@ brw_generator::generate_code(const cfg_t *cfg, int dispatch_width,
case SHADER_OPCODE_INTERLOCK:
case SHADER_OPCODE_MEMORY_FENCE: {
assert(src[1].file == IMM);
assert(src[2].file == IMM);
const enum opcode send_op = inst->opcode == SHADER_OPCODE_INTERLOCK ?
BRW_OPCODE_SENDC : BRW_OPCODE_SEND;
@@ -1204,8 +1203,7 @@ brw_generator::generate_code(const cfg_t *cfg, int dispatch_width,
brw_memory_fence(p, dst, src[0], send_op,
brw_message_target(inst->sfid),
inst->desc,
/* commit_enable */ src[1].ud,
/* bti */ src[2].ud);
/* commit_enable */ src[1].ud);
send_count++;
break;
}