On 09/09/2019 10:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-09 10:19:08)
On 09/09/2019 08:12, Chris Wilson wrote:
And give up if we never even make it to the start.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
---
tests/perf_pmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index d392a67d4..8a06e5d44 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -191,10 +191,12 @@ static unsigned long __spin_wait(int fd, igt_spin_t *spin)
while (!igt_spin_has_started(spin)) {
unsigned long t = igt_nsec_elapsed(&start);
+ igt_assert(gem_bo_busy(fd, spin->handle));
if ((t - timeout) > 250e6) {
timeout = t;
igt_warn("Spinner not running after %.2fms\n",
(double)t / 1e6); > +
igt_assert(t < 2e9);
}
}
} else {
@@ -202,6 +204,7 @@ static unsigned long __spin_wait(int fd, igt_spin_t *spin)
usleep(500e3); /* Better than nothing! */
}
+ igt_assert(gem_bo_busy(fd, spin->handle));
return igt_nsec_elapsed(&start);
}
The 2s timeout for batch to start executing sounds okay.
I'd pull up and consolidate the bo_busy checks into one at the top of
the function, since it is only telling us batch has been submitted. Or
you are thinking the second check brings value in checking batch is
still executing, hasn't failed or something?
The thinking is to catch if we terminate the batch via hangcheck before
writing the dword. I think there's value in knowing if we are slow vs
dead.
Yeah as guessed then - agreed.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
