All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
@ 2011-09-26 18:59 Kenneth Graunke
  2011-09-26 19:16 ` Chris Wilson
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Kenneth Graunke @ 2011-09-26 18:59 UTC (permalink / raw)
  To: intel-gfx

From: Jesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
---
 drivers/gpu/drm/i915/i915_reg.h         |    7 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  131 ++++++++++++++++++++++++++++---
 2 files changed, 124 insertions(+), 14 deletions(-)

I've been using this patch on my Ivybridge system for a while; it seems to
work just fine.  The difference between this and Jesse's earlier patch is
that we added the VFC bit.

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 138eae1..9ef448a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -243,6 +243,8 @@
 #define   DISPLAY_PLANE_A           (0<<20)
 #define   DISPLAY_PLANE_B           (1<<20)
 #define GFX_OP_PIPE_CONTROL	((0x3<<29)|(0x3<<27)|(0x2<<24)|2)
+#define GFX_OP_PIPE_CONTROL_GEN6 ((0x3<<29)|(0x3<<27)|(0x2<<24)|3)
+#define   PIPE_CONTROL_CS_STALL (1<<20)
 #define   PIPE_CONTROL_QW_WRITE	(1<<14)
 #define   PIPE_CONTROL_DEPTH_STALL (1<<13)
 #define   PIPE_CONTROL_WC_FLUSH	(1<<12)
@@ -250,9 +252,10 @@
 #define   PIPE_CONTROL_TC_FLUSH (1<<10) /* GM45+ only */
 #define   PIPE_CONTROL_ISP_DIS	(1<<9)
 #define   PIPE_CONTROL_NOTIFY	(1<<8)
+#define   PIPE_CONTROL_VFC	(1<<4)
 #define   PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */
-#define   PIPE_CONTROL_STALL_EN	(1<<1) /* in addr word, Ironlake+ only */
-
+#define   PIPE_CONTROL_STALL_AT_SCOREBOARD (1<<1) /* in addr word, Ironlake+ only */
+#define   PIPE_CONTROL_DEPTH_FLUSH (1<<0)
 
 /*
  * Reset registers
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 0e99589..ad969fa 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -34,6 +34,16 @@
 #include "i915_trace.h"
 #include "intel_drv.h"
 
+/*
+ * 965+ support PIPE_CONTROL commands, which provide finer grained control
+ * over cache flushing.
+ */
+struct pipe_control {
+	struct drm_i915_gem_object *obj;
+	volatile u32 *cpu_page;
+	u32 gtt_offset;
+};
+
 static inline int ring_space(struct intel_ring_buffer *ring)
 {
 	int space = (ring->head & HEAD_ADDR) - (ring->tail + 8);
@@ -123,6 +133,113 @@ render_ring_flush(struct intel_ring_buffer *ring,
 	return 0;
 }
 
+/**
+ * Emits a PIPE_CONTROL with a non-zero post-sync operation, for
+ * implementing two workarounds on gen6.  From section 1.4.7.1
+ * "PIPE_CONTROL" of the Sandy Bridge PRM volume 2 part 1:
+ *
+ * [DevSNB-C+{W/A}] Before any depth stall flush (including those
+ * produced by non-pipelined state commands), software needs to first
+ * send a PIPE_CONTROL with no bits set except Post-Sync Operation !=
+ * 0.
+ *
+ * [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable
+ * =1, a PIPE_CONTROL with any non-zero post-sync-op is required.
+ *
+ * And the workaround for these two requires this workaround first:
+ *
+ * [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
+ * BEFORE the pipe-control with a post-sync op and no write-cache
+ * flushes.
+ *
+ * And this last workaround is tricky because of the requirements on
+ * that bit.  From section 1.4.7.2.3 "Stall" of the Sandy Bridge PRM
+ * volume 2 part 1:
+ *
+ *     "1 of the following must also be set:
+ *      - Render Target Cache Flush Enable ([12] of DW1)
+ *      - Depth Cache Flush Enable ([0] of DW1)
+ *      - Stall at Pixel Scoreboard ([1] of DW1)
+ *      - Depth Stall ([13] of DW1)
+ *      - Post-Sync Operation ([13] of DW1)
+ *      - Notify Enable ([8] of DW1)"
+ *
+ * The cache flushes require the workaround flush that triggered this
+ * one, so we can't use it.  Depth stall would trigger the same.
+ * Post-sync nonzero is what triggered this second workaround, so we
+ * can't use that one either.  Notify enable is IRQs, which aren't
+ * really our business.  That leaves only stall at scoreboard.
+ */
+static int
+intel_emit_post_sync_nonzero_flush(struct intel_ring_buffer *ring)
+{
+	struct pipe_control *pc = ring->private;
+	u32 scratch_addr = pc->gtt_offset + 128;
+	int ret;
+
+
+	ret = intel_ring_begin(ring, 6);
+	if (ret)
+		return ret;
+
+	intel_ring_emit(ring, GFX_OP_PIPE_CONTROL_GEN6);
+	intel_ring_emit(ring, PIPE_CONTROL_CS_STALL |
+			PIPE_CONTROL_STALL_AT_SCOREBOARD);
+	intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT); /* address */
+	intel_ring_emit(ring, 0); /* low dword */
+	intel_ring_emit(ring, 0); /* high dword */
+	intel_ring_emit(ring, MI_NOOP);
+	intel_ring_advance(ring);
+
+	ret = intel_ring_begin(ring, 6);
+	if (ret)
+		return ret;
+
+	intel_ring_emit(ring, GFX_OP_PIPE_CONTROL_GEN6);
+	intel_ring_emit(ring, PIPE_CONTROL_QW_WRITE);
+	intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT); /* address */
+	intel_ring_emit(ring, 0);
+	intel_ring_emit(ring, 0);
+	intel_ring_emit(ring, MI_NOOP);
+	intel_ring_advance(ring);
+
+	return 0;
+}
+
+static int
+gen6_render_ring_flush(struct intel_ring_buffer *ring,
+                         u32 invalidate_domains, u32 flush_domains)
+{
+	u32 flags = 0;
+	struct pipe_control *pc = ring->private;
+	u32 scratch_addr = pc->gtt_offset + 128;
+	int ret;
+
+	/* Force SNB workarounds for PIPE_CONTROL flushes */
+	intel_emit_post_sync_nonzero_flush(ring);
+
+	/* Just flush everything for now */
+	flags |= PIPE_CONTROL_WC_FLUSH;
+	flags |= PIPE_CONTROL_IS_FLUSH;
+	flags |= PIPE_CONTROL_TC_FLUSH;
+	flags |= PIPE_CONTROL_DEPTH_FLUSH;
+	flags |= PIPE_CONTROL_VFC;
+
+	ret = intel_ring_begin(ring, 6);
+	if (ret)
+		return ret;
+
+	intel_ring_emit(ring, GFX_OP_PIPE_CONTROL_GEN6);
+	intel_ring_emit(ring, flags);
+	intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT);
+	intel_ring_emit(ring, 0); /* lower dword */
+	intel_ring_emit(ring, 0); /* uppwer dword */
+	intel_ring_emit(ring, MI_NOOP);
+	intel_ring_advance(ring);
+
+	return 0;
+}
+
 static void ring_write_tail(struct intel_ring_buffer *ring,
 			    u32 value)
 {
@@ -206,16 +323,6 @@ static int init_ring_common(struct intel_ring_buffer *ring)
 	return 0;
 }
 
-/*
- * 965+ support PIPE_CONTROL commands, which provide finer grained control
- * over cache flushing.
- */
-struct pipe_control {
-	struct drm_i915_gem_object *obj;
-	volatile u32 *cpu_page;
-	u32 gtt_offset;
-};
-
 static int
 init_pipe_control(struct intel_ring_buffer *ring)
 {
@@ -296,8 +403,7 @@ static int init_render_ring(struct intel_ring_buffer *ring)
 				   GFX_MODE_ENABLE(GFX_REPLAY_MODE));
 	}
 
-	if (INTEL_INFO(dev)->gen >= 6) {
-	} else if (IS_GEN5(dev)) {
+	if (INTEL_INFO(dev)->gen >= 5) {
 		ret = init_pipe_control(ring);
 		if (ret)
 			return ret;
@@ -1358,6 +1464,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
 	*ring = render_ring;
 	if (INTEL_INFO(dev)->gen >= 6) {
 		ring->add_request = gen6_add_request;
+		ring->flush = gen6_render_ring_flush;
 		ring->irq_get = gen6_render_ring_get_irq;
 		ring->irq_put = gen6_render_ring_put_irq;
 	} else if (IS_GEN5(dev)) {
-- 
1.7.6.1

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 18:59 [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+ Kenneth Graunke
@ 2011-09-26 19:16 ` Chris Wilson
  2011-09-26 19:23   ` Daniel Vetter
                     ` (2 more replies)
  2011-09-26 20:31 ` Daniel Vetter
  2011-10-03 20:00 ` Jesse Barnes
  2 siblings, 3 replies; 16+ messages in thread
From: Chris Wilson @ 2011-09-26 19:16 UTC (permalink / raw)
  To: Kenneth Graunke, intel-gfx

On Mon, 26 Sep 2011 11:59:23 -0700, Kenneth Graunke <kenneth@whitecape.org> wrote:
> From: Jesse Barnes <jbarnes@virtuousgeek.org>

>From the school of "If ain't broke, don't fix it" there needs to be a real
explanation of why this change is required here.

PIPE_CONTROL and its workarounds is a very bitter pill to swallow if
MI_FLUSH continues to function.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 19:16 ` Chris Wilson
@ 2011-09-26 19:23   ` Daniel Vetter
  2011-09-26 19:43     ` Chris Wilson
  2011-09-26 20:15   ` Keith Packard
  2011-09-26 20:21   ` Kenneth Graunke
  2 siblings, 1 reply; 16+ messages in thread
From: Daniel Vetter @ 2011-09-26 19:23 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Mon, Sep 26, 2011 at 08:16:04PM +0100, Chris Wilson wrote:
> On Mon, 26 Sep 2011 11:59:23 -0700, Kenneth Graunke <kenneth@whitecape.org> wrote:
> > From: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> From the school of "If ain't broke, don't fix it" there needs to be a real
> explanation of why this change is required here.
> 
> PIPE_CONTROL and its workarounds is a very bitter pill to swallow if
> MI_FLUSH continues to function.

Lazy tlb flush, gfdt flush, seperate depth cache flush. In short, I want
this ;-)
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 19:23   ` Daniel Vetter
@ 2011-09-26 19:43     ` Chris Wilson
  0 siblings, 0 replies; 16+ messages in thread
From: Chris Wilson @ 2011-09-26 19:43 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

On Mon, 26 Sep 2011 21:23:02 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Sep 26, 2011 at 08:16:04PM +0100, Chris Wilson wrote:
> > On Mon, 26 Sep 2011 11:59:23 -0700, Kenneth Graunke <kenneth@whitecape.org> wrote:
> > > From: Jesse Barnes <jbarnes@virtuousgeek.org>
> > 
> > From the school of "If ain't broke, don't fix it" there needs to be a real
> > explanation of why this change is required here.
> > 
> > PIPE_CONTROL and its workarounds is a very bitter pill to swallow if
> > MI_FLUSH continues to function.
> 
> Lazy tlb flush, gfdt flush, seperate depth cache flush. In short, I want
> this ;-)

I feel jaded, I could have swore you just said "bug, bugs, bugs." ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 19:16 ` Chris Wilson
  2011-09-26 19:23   ` Daniel Vetter
@ 2011-09-26 20:15   ` Keith Packard
  2011-09-26 20:21   ` Kenneth Graunke
  2 siblings, 0 replies; 16+ messages in thread
From: Keith Packard @ 2011-09-26 20:15 UTC (permalink / raw)
  To: Chris Wilson, Kenneth Graunke, intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 553 bytes --]

On Mon, 26 Sep 2011 20:16:04 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:

> PIPE_CONTROL and its workarounds is a very bitter pill to swallow if
> MI_FLUSH continues to function.

If you look at the simulator source code, you'll see that it implements
MI_FLUSH as a specific kind of PIPE_CONTROL. And that MI_FLUSH isn't
being validated anymore. If this is all true, then this isn't a huge
change, other than exposing which PIPE_CONTROL workarounds we're
supposed to be using in the MI_FLUSH paths...

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 19:16 ` Chris Wilson
  2011-09-26 19:23   ` Daniel Vetter
  2011-09-26 20:15   ` Keith Packard
@ 2011-09-26 20:21   ` Kenneth Graunke
  2 siblings, 0 replies; 16+ messages in thread
From: Kenneth Graunke @ 2011-09-26 20:21 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On 09/26/2011 12:16 PM, Chris Wilson wrote:
> On Mon, 26 Sep 2011 11:59:23 -0700, Kenneth Graunke <kenneth@whitecape.org> wrote:
>> From: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> From the school of "If ain't broke, don't fix it" there needs to be a real
> explanation of why this change is required here.
> 
> PIPE_CONTROL and its workarounds is a very bitter pill to swallow if
> MI_FLUSH continues to function.
> -Chris

I hear you.

The issue is that (from Eric's reading of the simulator) MI_FLUSH seems
to be equivalent to PIPE_CONTROL with some unknown set of bits
enabled...which means we likely do need workarounds.  It's just not
clear which ones.

Also, according to the BSpec, MI_FLUSH is no longer validated or
guaranteed to work on Ivybridge.  I heard they said that about
Sandybridge as well but later recanted...I don't know if they will this
time, though.

I suspect that it actually is broke, and we do need to fix it.  This
seems like a first step.

--Kenneth

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 18:59 [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+ Kenneth Graunke
  2011-09-26 19:16 ` Chris Wilson
@ 2011-09-26 20:31 ` Daniel Vetter
  2011-09-26 20:38   ` Kenneth Graunke
  2011-10-03 20:00 ` Jesse Barnes
  2 siblings, 1 reply; 16+ messages in thread
From: Daniel Vetter @ 2011-09-26 20:31 UTC (permalink / raw)
  To: Kenneth Graunke; +Cc: intel-gfx

On Mon, Sep 26, 2011 at 11:59:23AM -0700, Kenneth Graunke wrote:
> +static int
> +gen6_render_ring_flush(struct intel_ring_buffer *ring,
> +                         u32 invalidate_domains, u32 flush_domains)
> +{
> +	u32 flags = 0;
> +	struct pipe_control *pc = ring->private;
> +	u32 scratch_addr = pc->gtt_offset + 128;
> +	int ret;
> +
> +	/* Force SNB workarounds for PIPE_CONTROL flushes */
> +	intel_emit_post_sync_nonzero_flush(ring);
> +
> +	/* Just flush everything for now */
> +	flags |= PIPE_CONTROL_WC_FLUSH;
> +	flags |= PIPE_CONTROL_IS_FLUSH;
> +	flags |= PIPE_CONTROL_TC_FLUSH;
> +	flags |= PIPE_CONTROL_DEPTH_FLUSH;
> +	flags |= PIPE_CONTROL_VFC;

Any reason you're not also setting the constant cache and state cache
invalidate bits?
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 20:31 ` Daniel Vetter
@ 2011-09-26 20:38   ` Kenneth Graunke
  2011-09-26 22:25     ` Eric Anholt
  0 siblings, 1 reply; 16+ messages in thread
From: Kenneth Graunke @ 2011-09-26 20:38 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

On 09/26/2011 01:31 PM, Daniel Vetter wrote:
> On Mon, Sep 26, 2011 at 11:59:23AM -0700, Kenneth Graunke wrote:
>> +static int
>> +gen6_render_ring_flush(struct intel_ring_buffer *ring,
>> +                         u32 invalidate_domains, u32 flush_domains)
>> +{
>> +	u32 flags = 0;
>> +	struct pipe_control *pc = ring->private;
>> +	u32 scratch_addr = pc->gtt_offset + 128;
>> +	int ret;
>> +
>> +	/* Force SNB workarounds for PIPE_CONTROL flushes */
>> +	intel_emit_post_sync_nonzero_flush(ring);
>> +
>> +	/* Just flush everything for now */
>> +	flags |= PIPE_CONTROL_WC_FLUSH;
>> +	flags |= PIPE_CONTROL_IS_FLUSH;
>> +	flags |= PIPE_CONTROL_TC_FLUSH;
>> +	flags |= PIPE_CONTROL_DEPTH_FLUSH;
>> +	flags |= PIPE_CONTROL_VFC;
> 
> Any reason you're not also setting the constant cache and state cache
> invalidate bits?
> -Daniel

Bits 2 and 3?  No particular reason; perhaps they should be.

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 20:38   ` Kenneth Graunke
@ 2011-09-26 22:25     ` Eric Anholt
  0 siblings, 0 replies; 16+ messages in thread
From: Eric Anholt @ 2011-09-26 22:25 UTC (permalink / raw)
  To: Kenneth Graunke, Daniel Vetter; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 1200 bytes --]

On Mon, 26 Sep 2011 13:38:26 -0700, Kenneth Graunke <kenneth@whitecape.org> wrote:
> On 09/26/2011 01:31 PM, Daniel Vetter wrote:
> > On Mon, Sep 26, 2011 at 11:59:23AM -0700, Kenneth Graunke wrote:
> >> +static int
> >> +gen6_render_ring_flush(struct intel_ring_buffer *ring,
> >> +                         u32 invalidate_domains, u32 flush_domains)
> >> +{
> >> +	u32 flags = 0;
> >> +	struct pipe_control *pc = ring->private;
> >> +	u32 scratch_addr = pc->gtt_offset + 128;
> >> +	int ret;
> >> +
> >> +	/* Force SNB workarounds for PIPE_CONTROL flushes */
> >> +	intel_emit_post_sync_nonzero_flush(ring);
> >> +
> >> +	/* Just flush everything for now */
> >> +	flags |= PIPE_CONTROL_WC_FLUSH;
> >> +	flags |= PIPE_CONTROL_IS_FLUSH;
> >> +	flags |= PIPE_CONTROL_TC_FLUSH;
> >> +	flags |= PIPE_CONTROL_DEPTH_FLUSH;
> >> +	flags |= PIPE_CONTROL_VFC;
> > 
> > Any reason you're not also setting the constant cache and state cache
> > invalidate bits?
> > -Daniel
> 
> Bits 2 and 3?  No particular reason; perhaps they should be.

IIRC we're not using the constant cache today, but it would be nice to,
so let's get it set.

We definitely need state cache invalidate.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-09-26 18:59 [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+ Kenneth Graunke
  2011-09-26 19:16 ` Chris Wilson
  2011-09-26 20:31 ` Daniel Vetter
@ 2011-10-03 20:00 ` Jesse Barnes
  2011-10-03 21:14   ` Keith Packard
  2011-10-03 22:59   ` Eric Anholt
  2 siblings, 2 replies; 16+ messages in thread
From: Jesse Barnes @ 2011-10-03 20:00 UTC (permalink / raw)
  To: Kenneth Graunke; +Cc: intel-gfx

On Mon, 26 Sep 2011 11:59:23 -0700
Kenneth Graunke <kenneth@whitecape.org> wrote:

> +	/* Just flush everything for now */
> +	flags |= PIPE_CONTROL_WC_FLUSH;
> +	flags |= PIPE_CONTROL_IS_FLUSH;
> +	flags |= PIPE_CONTROL_TC_FLUSH;
> +	flags |= PIPE_CONTROL_DEPTH_FLUSH;
> +	flags |= PIPE_CONTROL_VFC;

This is the only bit I'd like to see changed.  While we still have the
domain tracking code we may as well try to honor it and limit our
flushing here like we do with MI_FLUSH.

Unless someone has a "remove all domain tracking" patch already posted
that is. :)

-- 
Jesse Barnes, Intel Open Source Technology Center

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-10-03 20:00 ` Jesse Barnes
@ 2011-10-03 21:14   ` Keith Packard
  2011-10-03 21:21     ` Jesse Barnes
  2011-10-03 22:59   ` Eric Anholt
  1 sibling, 1 reply; 16+ messages in thread
From: Keith Packard @ 2011-10-03 21:14 UTC (permalink / raw)
  To: Jesse Barnes, Kenneth Graunke; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]

On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> This is the only bit I'd like to see changed.  While we still have the
> domain tracking code we may as well try to honor it and limit our
> flushing here like we do with MI_FLUSH.

I'd like to see this patch put in place, and then any 'optimization'
added afterwards so we can avoid having to revert this change when it
breaks.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-10-03 21:14   ` Keith Packard
@ 2011-10-03 21:21     ` Jesse Barnes
  0 siblings, 0 replies; 16+ messages in thread
From: Jesse Barnes @ 2011-10-03 21:21 UTC (permalink / raw)
  To: Keith Packard; +Cc: intel-gfx

On Mon, 03 Oct 2011 14:14:53 -0700
Keith Packard <keithp@keithp.com> wrote:

> On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
> > This is the only bit I'd like to see changed.  While we still have the
> > domain tracking code we may as well try to honor it and limit our
> > flushing here like we do with MI_FLUSH.
> 
> I'd like to see this patch put in place, and then any 'optimization'
> added afterwards so we can avoid having to revert this change when it
> breaks.

Sounds good.  I guess Ken needs to re-post anyway to add the two extra
bits...

-- 
Jesse Barnes, Intel Open Source Technology Center

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-10-03 20:00 ` Jesse Barnes
  2011-10-03 21:14   ` Keith Packard
@ 2011-10-03 22:59   ` Eric Anholt
  2011-10-03 23:16     ` Jesse Barnes
  1 sibling, 1 reply; 16+ messages in thread
From: Eric Anholt @ 2011-10-03 22:59 UTC (permalink / raw)
  To: Jesse Barnes, Kenneth Graunke; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 997 bytes --]

On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 26 Sep 2011 11:59:23 -0700
> Kenneth Graunke <kenneth@whitecape.org> wrote:
> 
> > +	/* Just flush everything for now */
> > +	flags |= PIPE_CONTROL_WC_FLUSH;
> > +	flags |= PIPE_CONTROL_IS_FLUSH;
> > +	flags |= PIPE_CONTROL_TC_FLUSH;
> > +	flags |= PIPE_CONTROL_DEPTH_FLUSH;
> > +	flags |= PIPE_CONTROL_VFC;
> 
> This is the only bit I'd like to see changed.  While we still have the
> domain tracking code we may as well try to honor it and limit our
> flushing here like we do with MI_FLUSH.
> 
> Unless someone has a "remove all domain tracking" patch already posted
> that is. :)

I don't think we "might as well try to honor it".  Working out the
workarounds for various combinations is difficult to do even for a fixed
set of bits.  Let's not make the workarounds more complicated by varying
them, when experiments showed no evidence for removing bits improving
performance.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-10-03 22:59   ` Eric Anholt
@ 2011-10-03 23:16     ` Jesse Barnes
  0 siblings, 0 replies; 16+ messages in thread
From: Jesse Barnes @ 2011-10-03 23:16 UTC (permalink / raw)
  To: Eric Anholt; +Cc: intel-gfx

On Mon, 03 Oct 2011 15:59:29 -0700
Eric Anholt <eric@anholt.net> wrote:

> On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Mon, 26 Sep 2011 11:59:23 -0700
> > Kenneth Graunke <kenneth@whitecape.org> wrote:
> > 
> > > +	/* Just flush everything for now */
> > > +	flags |= PIPE_CONTROL_WC_FLUSH;
> > > +	flags |= PIPE_CONTROL_IS_FLUSH;
> > > +	flags |= PIPE_CONTROL_TC_FLUSH;
> > > +	flags |= PIPE_CONTROL_DEPTH_FLUSH;
> > > +	flags |= PIPE_CONTROL_VFC;
> > 
> > This is the only bit I'd like to see changed.  While we still have the
> > domain tracking code we may as well try to honor it and limit our
> > flushing here like we do with MI_FLUSH.
> > 
> > Unless someone has a "remove all domain tracking" patch already posted
> > that is. :)
> 
> I don't think we "might as well try to honor it".  Working out the
> workarounds for various combinations is difficult to do even for a fixed
> set of bits.  Let's not make the workarounds more complicated by varying
> them, when experiments showed no evidence for removing bits improving
> performance.

Oh if you have experiments showing that the individual bits provide no
benefit that's fine.

-- 
Jesse Barnes, Intel Open Source Technology Center

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

* Re: [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-10-16  8:23 ` [PATCH] " Daniel Vetter
@ 2011-10-17  1:27   ` Ben Widawsky
  0 siblings, 0 replies; 16+ messages in thread
From: Ben Widawsky @ 2011-10-17  1:27 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

On Sun, 16 Oct 2011 10:23:31 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> From: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> v2 by danvet: Use a new flag to flush the render target cache on gen6+
> (hw reuses the old write flush bit), as suggested by Ben Widawsdy.
> 
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
> [danvet: this seems to fix cairo-perf-trace hangs on my snb]
> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>

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

* [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+.
  2011-10-11 21:41 [PATCH 3/3] " Daniel Vetter
@ 2011-10-16  8:23 ` Daniel Vetter
  2011-10-17  1:27   ` Ben Widawsky
  0 siblings, 1 reply; 16+ messages in thread
From: Daniel Vetter @ 2011-10-16  8:23 UTC (permalink / raw)
  To: intel-gfx; +Cc: Daniel Vetter, Ben Widawsky

From: Jesse Barnes <jbarnes@virtuousgeek.org>

v2 by danvet: Use a new flag to flush the render target cache on gen6+
(hw reuses the old write flush bit), as suggested by Ben Widawsdy.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
[danvet: this seems to fix cairo-perf-trace hangs on my snb]
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_reg.h         |    6 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c |  136 ++++++++++++++++++++++++++++---
 2 files changed, 130 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7f496a1..a432b06 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -243,14 +243,20 @@
 #define   DISPLAY_PLANE_A           (0<<20)
 #define   DISPLAY_PLANE_B           (1<<20)
 #define GFX_OP_PIPE_CONTROL(len)	((0x3<<29)|(0x3<<27)|(0x2<<24)|(len-2))
+#define   PIPE_CONTROL_CS_STALL				(1<<20)
 #define   PIPE_CONTROL_QW_WRITE				(1<<14)
 #define   PIPE_CONTROL_DEPTH_STALL			(1<<13)
 #define   PIPE_CONTROL_WRITE_FLUSH			(1<<12)
+#define   PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH	(1<<12) /* gen6+ */
 #define   PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE	(1<<11) /* MBZ on Ironlake */
 #define   PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE		(1<<10) /* GM45+ only */
 #define   PIPE_CONTROL_INDIRECT_STATE_DISABLE		(1<<9)
 #define   PIPE_CONTROL_NOTIFY				(1<<8)
+#define   PIPE_CONTROL_VF_CACHE_INVALIDATE		(1<<4)
+#define   PIPE_CONTROL_CONST_CACHE_INVALIDATE		(1<<3)
+#define   PIPE_CONTROL_STATE_CACHE_INVALIDATE		(1<<2)
 #define   PIPE_CONTROL_STALL_AT_SCOREBOARD		(1<<1)
+#define   PIPE_CONTROL_DEPTH_CACHE_FLUSH		(1<<0)
 #define   PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */
 
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2f3c3e1..3c30dba 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -34,6 +34,16 @@
 #include "i915_trace.h"
 #include "intel_drv.h"
 
+/*
+ * 965+ support PIPE_CONTROL commands, which provide finer grained control
+ * over cache flushing.
+ */
+struct pipe_control {
+	struct drm_i915_gem_object *obj;
+	volatile u32 *cpu_page;
+	u32 gtt_offset;
+};
+
 static inline int ring_space(struct intel_ring_buffer *ring)
 {
 	int space = (ring->head & HEAD_ADDR) - (ring->tail + 8);
@@ -123,6 +133,118 @@ render_ring_flush(struct intel_ring_buffer *ring,
 	return 0;
 }
 
+/**
+ * Emits a PIPE_CONTROL with a non-zero post-sync operation, for
+ * implementing two workarounds on gen6.  From section 1.4.7.1
+ * "PIPE_CONTROL" of the Sandy Bridge PRM volume 2 part 1:
+ *
+ * [DevSNB-C+{W/A}] Before any depth stall flush (including those
+ * produced by non-pipelined state commands), software needs to first
+ * send a PIPE_CONTROL with no bits set except Post-Sync Operation !=
+ * 0.
+ *
+ * [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable
+ * =1, a PIPE_CONTROL with any non-zero post-sync-op is required.
+ *
+ * And the workaround for these two requires this workaround first:
+ *
+ * [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
+ * BEFORE the pipe-control with a post-sync op and no write-cache
+ * flushes.
+ *
+ * And this last workaround is tricky because of the requirements on
+ * that bit.  From section 1.4.7.2.3 "Stall" of the Sandy Bridge PRM
+ * volume 2 part 1:
+ *
+ *     "1 of the following must also be set:
+ *      - Render Target Cache Flush Enable ([12] of DW1)
+ *      - Depth Cache Flush Enable ([0] of DW1)
+ *      - Stall at Pixel Scoreboard ([1] of DW1)
+ *      - Depth Stall ([13] of DW1)
+ *      - Post-Sync Operation ([13] of DW1)
+ *      - Notify Enable ([8] of DW1)"
+ *
+ * The cache flushes require the workaround flush that triggered this
+ * one, so we can't use it.  Depth stall would trigger the same.
+ * Post-sync nonzero is what triggered this second workaround, so we
+ * can't use that one either.  Notify enable is IRQs, which aren't
+ * really our business.  That leaves only stall at scoreboard.
+ */
+static int
+intel_emit_post_sync_nonzero_flush(struct intel_ring_buffer *ring)
+{
+	struct pipe_control *pc = ring->private;
+	u32 scratch_addr = pc->gtt_offset + 128;
+	int ret;
+
+
+	ret = intel_ring_begin(ring, 6);
+	if (ret)
+		return ret;
+
+	intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(5));
+	intel_ring_emit(ring, PIPE_CONTROL_CS_STALL |
+			PIPE_CONTROL_STALL_AT_SCOREBOARD);
+	intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT); /* address */
+	intel_ring_emit(ring, 0); /* low dword */
+	intel_ring_emit(ring, 0); /* high dword */
+	intel_ring_emit(ring, MI_NOOP);
+	intel_ring_advance(ring);
+
+	ret = intel_ring_begin(ring, 6);
+	if (ret)
+		return ret;
+
+	intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(5));
+	intel_ring_emit(ring, PIPE_CONTROL_QW_WRITE);
+	intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT); /* address */
+	intel_ring_emit(ring, 0);
+	intel_ring_emit(ring, 0);
+	intel_ring_emit(ring, MI_NOOP);
+	intel_ring_advance(ring);
+
+	return 0;
+}
+
+static int
+gen6_render_ring_flush(struct intel_ring_buffer *ring,
+                         u32 invalidate_domains, u32 flush_domains)
+{
+	u32 flags = 0;
+	struct pipe_control *pc = ring->private;
+	u32 scratch_addr = pc->gtt_offset + 128;
+	int ret;
+
+	/* Force SNB workarounds for PIPE_CONTROL flushes */
+	intel_emit_post_sync_nonzero_flush(ring);
+
+	/* Just flush everything.  Experiments have shown that reducing the
+	 * number of bits based on the write domains has little performance
+	 * impact.
+	 */
+	flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+	flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
+	flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
+	flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+	flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
+	flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
+	flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
+
+	ret = intel_ring_begin(ring, 6);
+	if (ret)
+		return ret;
+
+	intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(5));
+	intel_ring_emit(ring, flags);
+	intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT);
+	intel_ring_emit(ring, 0); /* lower dword */
+	intel_ring_emit(ring, 0); /* uppwer dword */
+	intel_ring_emit(ring, MI_NOOP);
+	intel_ring_advance(ring);
+
+	return 0;
+}
+
 static void ring_write_tail(struct intel_ring_buffer *ring,
 			    u32 value)
 {
@@ -206,16 +328,6 @@ static int init_ring_common(struct intel_ring_buffer *ring)
 	return 0;
 }
 
-/*
- * 965+ support PIPE_CONTROL commands, which provide finer grained control
- * over cache flushing.
- */
-struct pipe_control {
-	struct drm_i915_gem_object *obj;
-	volatile u32 *cpu_page;
-	u32 gtt_offset;
-};
-
 static int
 init_pipe_control(struct intel_ring_buffer *ring)
 {
@@ -296,8 +408,7 @@ static int init_render_ring(struct intel_ring_buffer *ring)
 				   GFX_MODE_ENABLE(GFX_REPLAY_MODE));
 	}
 
-	if (INTEL_INFO(dev)->gen >= 6) {
-	} else if (IS_GEN5(dev)) {
+	if (INTEL_INFO(dev)->gen >= 5) {
 		ret = init_pipe_control(ring);
 		if (ret)
 			return ret;
@@ -1369,6 +1480,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
 	*ring = render_ring;
 	if (INTEL_INFO(dev)->gen >= 6) {
 		ring->add_request = gen6_add_request;
+		ring->flush = gen6_render_ring_flush;
 		ring->irq_get = gen6_render_ring_get_irq;
 		ring->irq_put = gen6_render_ring_put_irq;
 	} else if (IS_GEN5(dev)) {
-- 
1.7.6.4

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

end of thread, other threads:[~2011-10-17  1:28 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-26 18:59 [PATCH] drm/i915: Use PIPE_CONTROL for flushing on gen6+ Kenneth Graunke
2011-09-26 19:16 ` Chris Wilson
2011-09-26 19:23   ` Daniel Vetter
2011-09-26 19:43     ` Chris Wilson
2011-09-26 20:15   ` Keith Packard
2011-09-26 20:21   ` Kenneth Graunke
2011-09-26 20:31 ` Daniel Vetter
2011-09-26 20:38   ` Kenneth Graunke
2011-09-26 22:25     ` Eric Anholt
2011-10-03 20:00 ` Jesse Barnes
2011-10-03 21:14   ` Keith Packard
2011-10-03 21:21     ` Jesse Barnes
2011-10-03 22:59   ` Eric Anholt
2011-10-03 23:16     ` Jesse Barnes
2011-10-11 21:41 [PATCH 3/3] " Daniel Vetter
2011-10-16  8:23 ` [PATCH] " Daniel Vetter
2011-10-17  1:27   ` Ben Widawsky

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.