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 1/6] drm/i915: Remove redundant trailing request flush
Date: Mon, 31 Dec 2018 11:24:49 +0000	[thread overview]
Message-ID: <477dd040-4884-2f38-fbc1-e32ffae4c943@linux.intel.com> (raw)
In-Reply-To: <154625233567.12016.9407979544855257508@skylake-alporthouse-com>


On 31/12/2018 10:32, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-12-31 10:25:41)
>>
>> On 28/12/2018 17:16, Chris Wilson wrote:
>>> @@ -616,9 +612,13 @@ i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx)
>>>         * i915_request_add() call can't fail. Note that the reserve may need
>>>         * to be redone if the request is not actually submitted straight
>>>         * away, e.g. because a GPU scheduler has deferred it.
>>> +      *
>>> +      * Note that due to how we add reserved_space to intel_ring_begin()
>>> +      * we need to double our request to ensure that if we need to wrap
>>> +      * around inside i915_request_add() there is sufficient space at
>>> +      * the beginning of the ring as well.
>>
>> Is there a benefit of keeping this intel_ring_begin behaviour? I mean,
>> could we just drop the special casing in there and always wrap the whole
>> space from the beginning if either part does not fit? That would allow
>> this part to pass in the true reserved space size I think.
> 
> I was tempted to rewrite intel_ring_begin() to do the doubling itself it
> it chose to wrap now that we know we only emit one packet. But I chose
> the path of least resistance. The effect is miniscule as we only reserve
> the extra space, but don't actually emit any extra MI_NOOPs. The effect
> is that we may wait for a few bytes more than we actually require -- and
> if the ring is full enough that we wait for this request, in all
> likelihood we would be waiting again for the next.

It's just awfully ugly that upper layer adds a hack to account for how 
lower layer handles things when both are totally ours. But okay, lets 
mark intel_ring_begin for a rewrite when things settle.

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:[~2018-12-31 11:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-28 17:16 [PATCH 1/6] drm/i915: Remove redundant trailing request flush Chris Wilson
2018-12-28 17:16 ` [PATCH 2/6] drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs Chris Wilson
2018-12-31 10:28   ` Tvrtko Ursulin
2018-12-28 17:16 ` [PATCH 3/6] drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs Chris Wilson
2018-12-31 10:31   ` Tvrtko Ursulin
2018-12-28 17:16 ` [PATCH 4/6] drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7 Chris Wilson
2018-12-31 10:43   ` Tvrtko Ursulin
2018-12-31 10:56     ` Chris Wilson
2018-12-28 17:16 ` [PATCH 5/6] drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5 Chris Wilson
2018-12-31 10:49   ` Tvrtko Ursulin
2018-12-31 11:07     ` Chris Wilson
2018-12-31 11:21       ` Tvrtko Ursulin
2018-12-31 15:25     ` Chris Wilson
2018-12-28 17:16 ` [PATCH 6/6] drm/i915: Drop unused engine->irq_seqno_barrier w/a Chris Wilson
2018-12-31 11:35   ` Tvrtko Ursulin
2018-12-28 17:48 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Remove redundant trailing request flush Patchwork
2018-12-28 18:18 ` ✓ Fi.CI.BAT: success " Patchwork
2018-12-31 15:38   ` Chris Wilson
2018-12-28 22:00 ` ✓ Fi.CI.IGT: " Patchwork
2018-12-31 10:25 ` [PATCH 1/6] " Tvrtko Ursulin
2018-12-31 10:32   ` Chris Wilson
2018-12-31 11:24     ` Tvrtko Ursulin [this message]

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=477dd040-4884-2f38-fbc1-e32ffae4c943@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.