From 75bd37dc6a33c3b00c7349dcd0295415a9c46d59 Mon Sep 17 00:00:00 2001 From: Iago Toral Quiroga Date: Thu, 21 Oct 2021 12:06:16 +0200 Subject: [PATCH] broadcom/compiler: disallow tsy barrier in thrsw delay slots MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A TSY barrier becomes effective at the point of the next thread switch, so if we have one coming after a previous thread switch we need to be careful not to emit it in its delay slots, or we would be effectively moving the barrier earlier than intended. Fixes simulator assert crash in: dEQP-VK.graphicsfuzz.two-for-loops-with-barrier-function Reviewed-by: Alejandro Piñeiro Part-of: --- src/broadcom/compiler/qpu_schedule.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/broadcom/compiler/qpu_schedule.c b/src/broadcom/compiler/qpu_schedule.c index c559814b9ea..63436735f57 100644 --- a/src/broadcom/compiler/qpu_schedule.c +++ b/src/broadcom/compiler/qpu_schedule.c @@ -1648,6 +1648,14 @@ qpu_inst_after_thrsw_valid_in_delay_slot(struct v3d_compile *c, if (v3d_qpu_writes_flags(&qinst->qpu)) return false; + /* TSY sync ops materialize at the point of the next thread switch, + * therefore, if we have a TSY sync right after a thread switch, we + * cannot place it in its delay slots, or we would be moving the sync + * to the thrsw before it instead. + */ + if (qinst->qpu.alu.add.op == V3D_QPU_A_BARRIERID) + return false; + return true; }