[PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

* [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()
@ 2015-06-08 18:51 Dave Gordon
  2015-06-13 20:16 ` shuang.he
  2015-06-15  9:15 ` Chris Wilson
  0 siblings, 2 replies; 8+ messages in thread
From: Dave Gordon @ 2015-06-08 18:51 UTC (permalink / raw)
  To: intel-gfx

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

^ permalink raw reply related	[flat|nested] 8+ messages in thread