intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 2/2] drm/i915: Allocate OLR more safely (workaround until OLR goes away)
Date: Fri, 12 Jun 2015 21:25:38 +0100	[thread overview]
Message-ID: <1434140738-19521-3-git-send-email-david.s.gordon@intel.com> (raw)
In-Reply-To: <1434140738-19521-1-git-send-email-david.s.gordon@intel.com>

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.

However, with the introduction of dynamic pinning, in

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

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, in this
case 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.

So the correct order is neither the original allocate-wait-pad-wait, nor
the subsequent wait-pad-wait-allocate, but wait-allocate-pad, avoiding
both the problems described in the two commits mentioned above. So this
commit moves the calls to i915_gem_request_alloc() into the middle of
{__intel,logical}_ring_prepare() rather than either before or after them.

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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a4bb5d3..3ef5fb6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -764,6 +764,13 @@ static int logical_ring_prepare(struct intel_ringbuffer *ringbuf,
 			return ret;
 	}
 
+	/* Ensure we have a request before touching the ring */
+	if (!ringbuf->ring->outstanding_lazy_request) {
+		ret = i915_gem_request_alloc(ringbuf->ring, ctx);
+		if (ret)
+			return ret;
+	}
+
 	if (unlikely(fill)) {
 		uint32_t __iomem *virt = ringbuf->virtual_start + ringbuf->tail;
 
@@ -812,11 +819,6 @@ static int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
 	if (ret)
 		return ret;
 
-	/* Preallocate the olr before touching the ring */
-	ret = i915_gem_request_alloc(ring, ctx);
-	if (ret)
-		return ret;
-
 	ringbuf->space -= num_dwords * sizeof(uint32_t);
 	return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5a1cd20..ddf580d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2195,6 +2195,13 @@ static int __intel_ring_prepare(struct intel_engine_cs *ring,
 			return ret;
 	}
 
+	/* Ensure we have a request before touching the ring */
+	if (!ringbuf->ring->outstanding_lazy_request) {
+		ret = i915_gem_request_alloc(ringbuf->ring, ring->default_context);
+		if (ret)
+			return ret;
+	}
+
 	if (unlikely(fill)) {
 		uint32_t __iomem *virt = ringbuf->virtual_start + ringbuf->tail;
 
@@ -2228,11 +2235,6 @@ int intel_ring_begin(struct intel_engine_cs *ring,
 	if (ret)
 		return ret;
 
-	/* Preallocate the olr before touching the ring */
-	ret = i915_gem_request_alloc(ring, ring->default_context);
-	if (ret)
-		return ret;
-
 	ring->buffer->space -= num_dwords * sizeof(uint32_t);
 	return 0;
 }
-- 
1.7.9.5

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

  parent reply	other threads:[~2015-06-12 20:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1433789441-8295-1-git-send-email-david.s.gordon@intel.com>
2015-06-12 17:09 ` [PATCH v2] Resolve issues with ringbuffer space management Dave Gordon
2015-06-12 17:09   ` [PATCH 1/2] drm/i915: use effective_size for ringbuffer calculations Dave Gordon
2015-06-12 18:12     ` Chris Wilson
2015-06-12 19:55       ` Dave Gordon
2015-06-12 20:41         ` Chris Wilson
2015-06-12 17:09   ` [PATCH 2/2] drm/i915: Rework order of operations in {__intel, logical}_ring_prepare() Dave Gordon
2015-06-12 18:05     ` Chris Wilson
2015-06-12 18:54       ` Dave Gordon
2015-06-12 19:10         ` Chris Wilson
2015-06-12 20:25   ` (no subject) Dave Gordon
2015-06-12 20:25     ` [PATCH 1/2] drm/i915: Don't wait twice in {__intel, logical}_ring_prepare() Dave Gordon
2015-06-12 20:25     ` Dave Gordon [this message]
2015-06-17 11:04     ` (no subject) Daniel Vetter
2015-06-17 12:41       ` Jani Nikula
2015-06-18 10:30       ` Dave Gordon

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=1434140738-19521-3-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).