On 04/12/17 09:37, Chris Wilson wrote:
Quoting Antonio Argenziano (2017-12-04 17:23:14)
This patch adds a test where a low priority batch is going to be
declared hung while a preemption is pending. The test wants to verify
that a 'bad' low priority batch will not disrupt the execution of a high
priority context and that the driver does due diligence in managing a
reset while a preemption is pending.
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Michal Winiarski <michal.winiarski@xxxxxxxxx>
Signed-off-by: Antonio Argenziano <antonio.argenziano@xxxxxxxxx>
---
tests/gem_exec_schedule.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 1e6b0ae7..ae44a6c0 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -356,7 +356,8 @@ static void promotion(int fd, unsigned ring)
munmap(ptr, 4096);
}
-#define NEW_CTX 0x1
+#define NEW_CTX (0x1 << 0)
+#define HANG_LP (0x1 << 1)
static void preempt(int fd, unsigned ring, unsigned flags)
{
uint32_t result = gem_create(fd, 4096);
@@ -370,6 +371,9 @@ static void preempt(int fd, unsigned ring, unsigned flags)
ctx[HI] = gem_context_create(fd);
gem_context_set_priority(fd, ctx[HI], MAX_PRIO);
+ if (flags & HANG_LP)
+ igt_spin_batch_new(fd, ctx[LO], ring, 0, false);
Both of the hanging batch usecases fit into igt_hang_t batch, which doesn't
allow preempting atm. (Though I'd be quite happy to see patches towards
unifying the two interfaces, probably with an opts struct rather than
continuing to add new params ad nauseam.) Before injecting a hang, you
must check with igt_allow_hang etc that hangs/resets are allowed by igt,
and to clean up afterwards.
I'll re-spin using igt_hang and send an RFC to put the two things
together afterwards. Is that OK with you?
-Antonio
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
