All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.