Mesa (main): broadcom/compiler: disallow tsy barrier in thrsw delay slots

[GitLab Mirror]

Module: Mesa
Branch: main
Commit: 75bd37dc6a33c3b00c7349dcd0295415a9c46d59
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=75bd37dc6a33c3b00c7349dcd0295415a9c46d59

Author: Iago Toral Quiroga <itoral at igalia.com>
Date:   Thu Oct 21 12:06:16 2021 +0200

broadcom/compiler: disallow tsy barrier in thrsw delay slots

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 <apinheiro at igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13468>

---

 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;
 }