From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno
Date: Tue, 12 Jan 2021 09:14:21 +0000 [thread overview]
Message-ID: <5750bcc6-28d9-d599-e108-047d757ac911@linux.intel.com> (raw)
In-Reply-To: <161038144448.28181.2940128230292829562@build.alporthouse.com>
On 11/01/2021 16:10, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2021-01-11 16:03:48)
>>
>> On 11/01/2021 10:57, Chris Wilson wrote:
>>> On the off chance that we need to arbitrate before launching the
>>> payload, perform the check after we signal the request is ready to
>>> start. Assuming instantaneous processing of the CS event, the request
>>> will then be treated as having started when we make the decisions as to
>>> how to process that CS event.
>>
>> What is the wider context with this change?
>
> Just thinking about the impact of MI_ARB_ONOFF. It's the next patch that
> sparked the curiosity at that is trying to address a missed arbitration
> point on the semaphore-wait miss.
>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> ---
>>> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 12 ++++++------
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
>>> index 2e36e0a9d8a6..9a182652a35e 100644
>>> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
>>> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
>>> @@ -361,19 +361,19 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq)
>>> if (IS_ERR(cs))
>>> return PTR_ERR(cs);
>>>
>>> + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
>>> + *cs++ = hwsp_offset(rq);
>>> + *cs++ = 0;
>>> + *cs++ = rq->fence.seqno - 1;
>>> +
>>
>> Strictly this movement even makes the existing comment (below) more correct.
>>
>>> /*
>>> * Check if we have been preempted before we even get started.
>>> *
>>> * After this point i915_request_started() reports true, even if
>>> * we get preempted and so are no longer running.
>>> */
>>> - *cs++ = MI_ARB_CHECK;
>>> *cs++ = MI_NOOP;
>>> -
>>> - *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
>>> - *cs++ = hwsp_offset(rq);
>>> - *cs++ = 0;
>>> - *cs++ = rq->fence.seqno - 1;
>>> + *cs++ = MI_ARB_CHECK;
>>
>> Special reason to have NOOP before MI_ARB_CHECK or would more common
>> NOOP padding at the end be suitable?
>
> The so small it's barely a reason was to put as much distance (those
> whole 6 cycles) between the store and the arbitration point.
Overall on the patch, there could be slight difference on how
i915_request_started reports true and would now allow to be preempted
after that point, even if the user payload itself would not be
preemptable. Obviously that applies on Gen8, maybe on later Gens with
like non-preemptible media batches or so. I can't think that it would
(or should) cause a problem though, just thinking out loud. So don't
know really, sounds safe to experiment.
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:[~2021-01-12 9:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 10:57 [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Chris Wilson
2021-01-11 10:57 ` [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno Chris Wilson
2021-01-11 16:03 ` Tvrtko Ursulin
2021-01-11 16:10 ` Chris Wilson
2021-01-12 9:14 ` Tvrtko Ursulin [this message]
2021-01-11 10:57 ` [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting Chris Wilson
2021-01-11 16:19 ` Tvrtko Ursulin
2021-01-11 16:27 ` Chris Wilson
2021-01-11 17:12 ` Tvrtko Ursulin
2021-01-11 21:54 ` Chris Wilson
2021-01-12 9:21 ` Tvrtko Ursulin
2021-01-11 10:57 ` [Intel-gfx] [PATCH 4/4] drm/i915/selftests: Include engine name after reset failure Chris Wilson
2021-01-11 16:20 ` Tvrtko Ursulin
2021-01-11 12:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Patchwork
2021-01-11 14:19 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-01-11 15:53 ` [Intel-gfx] [PATCH 1/4] " Tvrtko Ursulin
2021-01-11 16:00 ` Chris Wilson
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=5750bcc6-28d9-d599-e108-047d757ac911@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.