public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] drm/i915: Enable the HiZ RAW Stall Optimization on Gen8.
Date: Mon, 12 Jan 2015 10:02:35 -0800	[thread overview]
Message-ID: <20150112180235.GA7733@bwidawsk.net> (raw)
In-Reply-To: <20150112120234.GD10649@intel.com>

On Mon, Jan 12, 2015 at 02:02:34PM +0200, Ville Syrjälä wrote:
> On Sun, Jan 11, 2015 at 07:14:57PM -0800, Ben Widawsky wrote:
> > On Sun, Jan 11, 2015 at 07:05:21PM -0800, Kenneth Graunke wrote:
> > > On Sunday, January 11, 2015 05:46:09 PM Ben Widawsky wrote:
> > > > On Sun, Jan 11, 2015 at 04:05:25PM -0800, Kenneth Graunke wrote:
> > > > > On Sunday, January 11, 2015 01:49:41 PM Ben Widawsky wrote:
> > > > > > On Sat, Jan 10, 2015 at 06:44:49PM -0800, Kenneth Graunke wrote:
> > > > > > > This is an important optimization for avoiding read-after-write (RAW)
> > > > > > > stalls in the HiZ buffer.  Certain workloads would run very slowly with
> > > > > > > HiZ enabled, but run much faster with the "hiz=false" driconf option.
> > > > > > > With this patch, they run at full speed even with HiZ.
> > > > > > > 
> > > > > > > Improves performance in OglVSInstancing by 3.2x on Broadwell GT3e
> > > > > > > (Iris Pro 6200).
> > > > > > > 
> > > > > > > Thanks to Jesse Barnes for finding this missing bit!
> > > > > > > Thanks to Chris Wilson for helping me find where to set it.
> > > > > > > 
> > > > > > > Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
> > > > > > > Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/intel_ringbuffer.c | 15 +++++++++++++++
> > > > > > >  1 file changed, 15 insertions(+)
> > > > > > > 
> > > > > > > Here's an alternate patch which implements the workaround in the kernel
> > > > > > > instead of Mesa.  It's probably better to do it there, since the kernel
> > > > > > > does it on Haswell already.
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > > > > index dabc1d8..23020d6 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > > > > @@ -796,6 +796,16 @@ static int bdw_init_workarounds(struct intel_engine_cs *ring)
> > > > > > >  			  HDC_DONOT_FETCH_MEM_WHEN_MASKED |
> > > > > > >  			  (IS_BDW_GT3(dev) ? HDC_FENCE_DEST_SLM_DISABLE : 0));
> > > > > > >  
> > > > > > > +	/* From the Haswell PRM, Command Reference: Registers, CACHE_MODE_0:
> > > > > > > +	 * "The Hierarchical Z RAW Stall Optimization allows non-overlapping
> > > > > > > +	 *  polygons in the same 8x4 pixel/sample area to be processed without
> > > > > > > +	 *  stalling waiting for the earlier ones to write to Hierarchical Z
> > > > > > > +	 *  buffer."
> > > > > > > +	 *
> > > > > > > +	 * This optimization is off by default for Broadwell; turn it on.
> > > > > > > +	 */
> > > > > > > +	WA_CLR_BIT_MASKED(CACHE_MODE_0_GEN7, HIZ_RAW_STALL_OPT_DISABLE);
> > > > > > > +
> > > > > > >  	/* Wa4x4STCOptimizationDisable:bdw */
> > > > > > >  	WA_SET_BIT_MASKED(CACHE_MODE_1,
> > > > > > >  			  GEN8_4x4_STC_OPTIMIZATION_DISABLE);
> > > > > > > @@ -836,6 +846,11 @@ static int chv_init_workarounds(struct intel_engine_cs *ring)
> > > > > > >  			  HDC_FORCE_NON_COHERENT |
> > > > > > >  			  HDC_DONOT_FETCH_MEM_WHEN_MASKED);
> > > > > > >  
> > > > > > > +	/* According to the CACHE_MODE_0 default value documentation, some
> > > > > > > +	 * CHV platforms disable this optimization by default.  Turn it on.
> > > > > > > +	 */
> > > > > > > +	WA_CLR_BIT_MASKED(CACHE_MODE_0_GEN7, HIZ_RAW_STALL_OPT_DISABLE);
> > > > > > > +
> > > > > > >  	/* Improve HiZ throughput on CHV. */
> > > > > > >  	WA_SET_BIT_MASKED(HIZ_CHICKEN, CHV_HZ_8X8_MODE_IN_1X);
> > > > > > >  
> > > > > > 
> > > > > > I think you should do this as two separate patches, 1 per platform. For the BSW
> > > > > > patch (given that I had the same functionality in the kernel patch I asked you
> > > > > > to look at ;-) and FWIW, Jordan has numbers on BSW B-step with my kernel patch
> > > > > > which we can use for the commit):
> > > > > > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > > > > 
> > > > > Huh, I don't recall seeing that kernel patch.  Sorry.  I guess I'll split it
> > > > > and resubmit...
> > > > > 
> > > > 
> > > > It's not my call, it's just nice to have platform specific bisection. And the
> > > > patch wasn't on the list, it was the one I kept asking you to look at in my
> > > > branch :-)
> > > > 
> > > > > > I haven't looked at Broadwell docs, so I'll let someone else take care of that.
> > > > > > 
> > > > > > I don't know if I agree with Chris that we should call these in the workaround
> > > > > > section, but whatever. init_clock_gating is equally sucky.
> > > > > 
> > > > > init_clock_gating doesn't work.  The register writes don't stick and they have
> > > > > no effect at all.  Setting them here makes them actually take effect in the
> > > > > context.
> > > > > 
> > > > > --Ken
> > > > 
> > > > Separate thread now, but are you sure? We're setting at least two context
> > > > specific registers in there today, among them: GEN7_FF_THREAD_MODE (which is
> > > > important to performance).
> > > 
> > > It looks like we're setting:
> > > - [BDW] RC_SLEEP_PSMI_CONTROL - 0x2050
> > 
> > dword offset 0x1c in the context image
> 
> power context, not logical context
> 
> > > - [BDW, CHV] FF_THREAD_MODE - 0x20a0
> > 
> > dword offset 0x2a in the context image
> 
> Also power context
> 
> > > - [CHV] RC_SLEEP_PSMI_CONTROL - 0x12050
> > 
> > Kinda surprised this one isn't there. I'm not sure how it can work correctly.
> 
> We're not frobbing with this anywhere but gen6_bsd_ring_write_tail(). In any
> case it's a VCS register. Sadly I've not found any documentation for !RCS
> power context, but I'm assuming every engine has a power context of some sort.
> 

Yeah, Ken and I resolved this offline. Any idea why the bits don't stick when
written via MMIO?

> -- 
> Ville Syrjälä
> Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-01-12 18:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-11  2:44 [PATCH] drm/i915: Enable the HiZ RAW Stall Optimization on Gen8 Kenneth Graunke
2015-01-11 21:49 ` [Mesa-dev] " Ben Widawsky
2015-01-12  0:05   ` Kenneth Graunke
2015-01-12  1:46     ` Ben Widawsky
2015-01-12  2:53       ` Kenneth Graunke
2015-01-12  3:09         ` Ben Widawsky
2015-01-12  3:05       ` Kenneth Graunke
2015-01-12  3:14         ` [Mesa-dev] " Ben Widawsky
2015-01-12 12:02           ` Ville Syrjälä
2015-01-12 18:02             ` Ben Widawsky [this message]
2015-01-12 18:09               ` Dave Gordon
2015-01-13  2:07                 ` Ben Widawsky
2015-01-13 20:03                   ` Ville Syrjälä
2015-01-12 12:32 ` [Intel-gfx] " Ville Syrjälä
2015-01-12 21:41   ` Kenneth Graunke

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=20150112180235.GA7733@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /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