From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/perf: don't forget noa wait after oa config
Date: Wed, 13 Nov 2019 20:07:59 +0200 [thread overview]
Message-ID: <6e487e55-43a7-8c95-7c31-e21318f9b2e3@intel.com> (raw)
In-Reply-To: <157366294079.22201.646622427460368767@skylake-alporthouse-com>
On 13/11/2019 18:35, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-11-13 15:46:39)
>> I'm observing incoherence metric values, changing from run to run.
>>
>> It appears the patches introducing noa wait & reconfiguration from
>> command stream switched places in the series multiple times during the
>> review. This lead to the dependency of one onto the order to go
>> missing...
> I don't think I dropped it; if I did my apologies. I do feel the
> egg-on-face for writing a selftest to verify that noa_wait does what you
> said it did, but completely missing that it went unused :)
>
>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command stream")
>> ---
>> drivers/gpu/drm/i915/i915_perf.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
>> index 507236bd41ae..31e47ee23357 100644
>> --- a/drivers/gpu/drm/i915/i915_perf.c
>> +++ b/drivers/gpu/drm/i915/i915_perf.c
>> @@ -1870,7 +1870,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
>> config_length += num_lri_dwords(oa_config->mux_regs_len);
>> config_length += num_lri_dwords(oa_config->b_counter_regs_len);
>> config_length += num_lri_dwords(oa_config->flex_regs_len);
>> - config_length++; /* MI_BATCH_BUFFER_END */
>> + config_length += 3; /* MI_BATCH_BUFFER_START */
>> config_length = ALIGN(sizeof(u32) * config_length, I915_GTT_PAGE_SIZE);
>>
>> obj = i915_gem_object_create_shmem(stream->perf->i915, config_length);
>> @@ -1895,7 +1895,12 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
>> oa_config->flex_regs,
>> oa_config->flex_regs_len);
>>
>> - *cs++ = MI_BATCH_BUFFER_END;
>> + /* Jump into the active wait. */
>> + *cs++ = (INTEL_GEN(stream->perf->i915) < 8 ?
>> + MI_BATCH_BUFFER_START :
>> + MI_BATCH_BUFFER_START_GEN8);
>> + *cs++ = i915_ggtt_offset(stream->noa_wait);
>> + *cs++ = 0;
> Yikes, stream->noa_wait is unused.
>
> Hmm, the noa_wait doesn't have any arbitration points internally, so we
> probably do need to make it non-preemptable as well?
>
> With a rq->flags |= I915_REQUEST_NOPREEMPT in emit_oa_config,
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> We need to wrap emit_oa_config() in a similar selftest and verify
> that a read of the oa regs are correct and that the TIMESTAMP indicates
> the appropriate delay before the read. If you feel bored.
> -Chris
As long as we wait long enough, it should be okay.
Why making it nopreempt?
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/perf: don't forget noa wait after oa config
Date: Wed, 13 Nov 2019 20:07:59 +0200 [thread overview]
Message-ID: <6e487e55-43a7-8c95-7c31-e21318f9b2e3@intel.com> (raw)
Message-ID: <20191113180759.SvDZ85K5BEyq0VcYRG4T96mvPCZtIf_OSyOQyRPk8-U@z> (raw)
In-Reply-To: <157366294079.22201.646622427460368767@skylake-alporthouse-com>
On 13/11/2019 18:35, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-11-13 15:46:39)
>> I'm observing incoherence metric values, changing from run to run.
>>
>> It appears the patches introducing noa wait & reconfiguration from
>> command stream switched places in the series multiple times during the
>> review. This lead to the dependency of one onto the order to go
>> missing...
> I don't think I dropped it; if I did my apologies. I do feel the
> egg-on-face for writing a selftest to verify that noa_wait does what you
> said it did, but completely missing that it went unused :)
>
>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command stream")
>> ---
>> drivers/gpu/drm/i915/i915_perf.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
>> index 507236bd41ae..31e47ee23357 100644
>> --- a/drivers/gpu/drm/i915/i915_perf.c
>> +++ b/drivers/gpu/drm/i915/i915_perf.c
>> @@ -1870,7 +1870,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
>> config_length += num_lri_dwords(oa_config->mux_regs_len);
>> config_length += num_lri_dwords(oa_config->b_counter_regs_len);
>> config_length += num_lri_dwords(oa_config->flex_regs_len);
>> - config_length++; /* MI_BATCH_BUFFER_END */
>> + config_length += 3; /* MI_BATCH_BUFFER_START */
>> config_length = ALIGN(sizeof(u32) * config_length, I915_GTT_PAGE_SIZE);
>>
>> obj = i915_gem_object_create_shmem(stream->perf->i915, config_length);
>> @@ -1895,7 +1895,12 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
>> oa_config->flex_regs,
>> oa_config->flex_regs_len);
>>
>> - *cs++ = MI_BATCH_BUFFER_END;
>> + /* Jump into the active wait. */
>> + *cs++ = (INTEL_GEN(stream->perf->i915) < 8 ?
>> + MI_BATCH_BUFFER_START :
>> + MI_BATCH_BUFFER_START_GEN8);
>> + *cs++ = i915_ggtt_offset(stream->noa_wait);
>> + *cs++ = 0;
> Yikes, stream->noa_wait is unused.
>
> Hmm, the noa_wait doesn't have any arbitration points internally, so we
> probably do need to make it non-preemptable as well?
>
> With a rq->flags |= I915_REQUEST_NOPREEMPT in emit_oa_config,
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> We need to wrap emit_oa_config() in a similar selftest and verify
> that a read of the oa regs are correct and that the TIMESTAMP indicates
> the appropriate delay before the read. If you feel bored.
> -Chris
As long as we wait long enough, it should be okay.
Why making it nopreempt?
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-11-13 18:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-13 15:46 [PATCH] drm/i915/perf: don't forget noa wait after oa config Lionel Landwerlin
2019-11-13 15:46 ` [Intel-gfx] " Lionel Landwerlin
2019-11-13 16:35 ` Chris Wilson
2019-11-13 16:35 ` [Intel-gfx] " Chris Wilson
2019-11-13 18:07 ` Lionel Landwerlin [this message]
2019-11-13 18:07 ` Lionel Landwerlin
2019-11-13 18:10 ` Chris Wilson
2019-11-13 18:10 ` [Intel-gfx] " Chris Wilson
2019-11-13 18:11 ` Chris Wilson
2019-11-13 18:11 ` [Intel-gfx] " Chris Wilson
2019-11-13 18:33 ` Lionel Landwerlin
2019-11-13 18:33 ` [Intel-gfx] " Lionel Landwerlin
2019-11-14 7:19 ` Chris Wilson
2019-11-14 7:19 ` [Intel-gfx] " Chris Wilson
2019-11-13 16:56 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-11-13 16:56 ` [Intel-gfx] " Patchwork
2019-11-14 6:44 ` ✓ Fi.CI.IGT: " Patchwork
2019-11-14 6:44 ` [Intel-gfx] " 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=6e487e55-43a7-8c95-7c31-e21318f9b2e3@intel.com \
--to=lionel.g.landwerlin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox