From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH igt 1/3] igt/perf_pmu: Reduce arbitrary delays
Date: Thu, 23 Nov 2017 13:35:32 +0000 [thread overview]
Message-ID: <8e5b1eea-a27e-1bd9-2e43-e83e3dd2c34a@linux.intel.com> (raw)
In-Reply-To: <20171123082237.9733-2-chris@chris-wilson.co.uk>
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@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
> 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@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-11-23 13:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 8:22 igt/perf_pmu roundup Chris Wilson
2017-11-23 8:22 ` [PATCH igt 1/3] igt/perf_pmu: Reduce arbitrary delays Chris Wilson
2017-11-23 13:35 ` Tvrtko Ursulin [this message]
2017-11-23 8:22 ` [PATCH igt 2/3] igt/perf_pmu: Stop peeking at intel_mmio registers Chris Wilson
2017-11-24 8:55 ` Tvrtko Ursulin
2017-11-24 9:20 ` Chris Wilson
2017-11-24 10:47 ` Chris Wilson
2017-11-23 8:22 ` [PATCH igt 3/3] igt/perf_pmu: Idle the GPU before starting to measure busyness Chris Wilson
2017-11-23 13:37 ` Tvrtko Ursulin
2017-11-23 16:02 ` Chris Wilson
2017-11-23 16:07 ` Chris Wilson
2017-11-24 7:32 ` Tvrtko Ursulin
2017-11-24 9:15 ` Chris Wilson
2017-11-23 18:53 ` ✓ Fi.CI.BAT: success for series starting with [1/3] igt/perf_pmu: Reduce arbitrary delays Patchwork
2017-11-23 22:14 ` ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8e5b1eea-a27e-1bd9-2e43-e83e3dd2c34a@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.