On 23/11/2017 08:22, Chris Wilson wrote:
gem_quiescent_gpu() is supposed to ensure that the HW is idle, and in
the process kick the GPU into rc6, so we should not need a long delay
afterwards to ensure that we are indeed in rc6. We do however need a
small delay in order to be sure that rc6 cycle counter has started and
stopped.
v2: Apply to rc6p as well.
v3: The longest rc6 timeout (before the HW kicks in and enables rc6 on
an idle GPU) is 50ms, so make sure that at least that time has passed
since we were busy.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
---
tests/perf_pmu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index ef5de658..5118c023 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1003,7 +1003,7 @@ test_rc6(int gem_fd)
fd = open_pmu(I915_PMU_RC6_RESIDENCY);
gem_quiescent_gpu(gem_fd);
- usleep(1e6);
+ usleep(100e3); /* wait for the rc6 cycle counter to kick in */
/* Go idle and check full RC6. */
prev = pmu_read_single(fd);
@@ -1015,6 +1015,7 @@ test_rc6(int gem_fd)
/* Wake up device and check no RC6. */
fw = igt_open_forcewake_handle(gem_fd);
igt_assert(fw >= 0);
+ usleep(1e3); /* wait for the rc6 cycle counter to stop ticking */
prev = pmu_read_single(fd);
usleep(duration_ns / 1000);
@@ -1047,7 +1048,7 @@ test_rc6p(int gem_fd)
igt_require(num_pmu == 3);
gem_quiescent_gpu(gem_fd);
- usleep(1e6);
+ usleep(100e3); /* wait for the rc6 cycle counter to kick in */
/* Go idle and check full RC6. */
pmu_read_multi(fd, num_pmu, prev);
@@ -1060,6 +1061,7 @@ test_rc6p(int gem_fd)
/* Wake up device and check no RC6. */
fw = igt_open_forcewake_handle(gem_fd);
igt_assert(fw >= 0);
+ usleep(1e3); /* wait for the rc6 cycle counter to stop ticking */
pmu_read_multi(fd, num_pmu, prev);
usleep(duration_ns / 1000);
As we talked yesterday I added the sleep thinking I am letting the GPU
go to RC6, but I missed the fact gem_queiscent_gpu already does that. So
as you explain here it is actually about hardware behaviour.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
