All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()
Date: Mon,  8 Jun 2015 19:51:36 +0100	[thread overview]
Message-ID: <1433789496-8365-1-git-send-email-david.s.gordon@intel.com> (raw)

The original idea of preallocating the OLR was implemented in

> 9d773091 drm/i915: Preallocate next seqno before touching the ring

and the sequence of operations was to allocate the OLR, then wrap past
the end of the ring if necessary, then wait for space if necessary.
But subsequently intel_ring_begin() was refactored, in

> 304d695 drm/i915: Flush outstanding requests before allocating new seqno

to ensure that pending work that might need to be flushed used the old
and not the newly-allocated request. This changed the sequence to wrap
and/or wait, then allocate, although the comment still said
	/* Preallocate the olr before touching the ring */
which was no longer true as intel_wrap_ring_buffer() touches the ring.

The reversal didn't introduce any problems until the introduction of
dynamic pinning, in

> 7ba717c drm/i915/bdw: Pin the ringbuffer backing object to GGTT on-demand

With that came the possibility that the ringbuffer might not be pinned
to the GTT or mapped into CPU address space when intel_ring_begin()
is called. It gets pinned when the request is allocated, so it's now
important that this comes before *anything* that can write into the
ringbuffer, specifically intel_wrap_ring_buffer(), as this will fault if
(a) the ringbuffer happens not to be mapped, and (b) tail happens to be
sufficiently close to the end of the ring to trigger wrapping.

The original rationale for this reversal seems to no longer apply,
as we shouldn't ever have anything in the ringbuffer which is not
associated with a specific request, and therefore shouldn't have anything
to flush.  So it should now be safe to reinstate the original sequence
of allocate-wrap-wait :)

Between the original sequence swap and now, the ringbuffer code got
cloned to become the execbuffer code, in

> 82e104c drm/i915/bdw: New logical ring submission mechanism

So now we have to fix it in both paths ...

Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
---
 drivers/gpu/drm/i915/intel_lrc.c        |    6 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c |    6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9b74ffa..4d82d9b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -809,12 +809,12 @@ static int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
 	if (ret)
 		return ret;
 
-	ret = logical_ring_prepare(ringbuf, ctx, num_dwords * sizeof(uint32_t));
+	/* Preallocate the olr before touching the ring */
+	ret = i915_gem_request_alloc(ring, ctx);
 	if (ret)
 		return ret;
 
-	/* Preallocate the olr before touching the ring */
-	ret = i915_gem_request_alloc(ring, ctx);
+	ret = logical_ring_prepare(ringbuf, ctx, num_dwords * sizeof(uint32_t));
 	if (ret)
 		return ret;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b70d25b..9f7a4d2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2222,12 +2222,12 @@ int intel_ring_begin(struct intel_engine_cs *ring,
 	if (ret)
 		return ret;
 
-	ret = __intel_ring_prepare(ring, num_dwords * sizeof(uint32_t));
+	/* Preallocate the olr before touching the ring */
+	ret = i915_gem_request_alloc(ring, ring->default_context);
 	if (ret)
 		return ret;
 
-	/* Preallocate the olr before touching the ring */
-	ret = i915_gem_request_alloc(ring, ring->default_context);
+	ret = __intel_ring_prepare(ring, num_dwords * sizeof(uint32_t));
 	if (ret)
 		return ret;
 
-- 
1.7.9.5

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

             reply	other threads:[~2015-06-08 18:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 18:51 Dave Gordon [this message]
2015-06-13 20:16 ` [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin() shuang.he
2015-06-15  9:15 ` Chris Wilson
2015-06-15 18:11   ` Dave Gordon
2015-06-15 20:41     ` Chris Wilson
2015-06-16 11:03       ` Dave Gordon
2015-06-16 12:18         ` Daniel Vetter
2015-06-16 12:24           ` 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=1433789496-8365-1-git-send-email-david.s.gordon@intel.com \
    --to=david.s.gordon@intel.com \
    --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.