Re: [PATCH 4/4] drm/i915: Opportunistically reduce flushing at execbuf

From: Ben Widawsky <ben@bwidawsk.net>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	Intel GFX <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Ben Widawsky <benjamin.widawsky@intel.com>
Subject: Re: [PATCH 4/4] drm/i915: Opportunistically reduce flushing at execbuf
Date: Tue, 16 Dec 2014 11:38:41 -0800	[thread overview]
Message-ID: <20141216193840.GA25214@bwidawsk.net> (raw)
In-Reply-To: <20141216075739.GC26498@nuc-i3427.alporthouse.com>

On Tue, Dec 16, 2014 at 07:57:39AM +0000, Chris Wilson wrote:
> On Mon, Dec 15, 2014 at 01:06:40PM -0800, Ben Widawsky wrote:
> > On Mon, Dec 15, 2014 at 08:39:35PM +0000, Chris Wilson wrote:
> > > On Mon, Dec 15, 2014 at 11:56:05AM -0800, Ben Widawsky wrote:
> > > > On Mon, Dec 15, 2014 at 08:20:50AM +0000, Chris Wilson wrote:
> > > > > On Mon, Dec 15, 2014 at 08:55:32AM +0100, Daniel Vetter wrote:
> > > > > > On Sun, Dec 14, 2014 at 03:37:36PM -0800, Ben Widawsky wrote:
> > > > > > > It's not hard, and I think that's a good idea as well. One reason I didn't put
> > > > > > > such code in this series is that moves away from a global DRM solution (and like
> > > > > > > I said in the cover-letter, I am fine with that). Implementing this, I think in
> > > > > > > the i915 code we'd just iterate through the BOs until we got to a certain
> > > > > > > threshold, then just call wbinvd() from i915 and not even both with drm_cache.
> > > > > > > You could also maybe try to shorcut if there are more than X buffers.
> > > > > > 
> > > > > > I don't mind an i915 specific solution (we have them already in many
> > > > > > places). So will wait for the results of this experiments before merging
> > > > > > more patches.
> > > > > 
> > > > > I actually think an i915 specific solution is required, as the making
> > > > > drm_clflush_pages autoselect is likely to cause regressions on unaware
> > > > > drivers (e.g. anything that has a reservation loop in execbuf like i915).
> > > > 
> > > > Assuming the stall is gone as Jesse said in the other thread, I can't envision a
> > > > scenario where wbinvd would do worse on large objects.
> > > 
> > > It is the multiple wbinvd performed at each execbuffer that is worrisome.
> > 
> > This patch attempts to avoid that by dropping all flushing after the first
> > WBINVD.
> 
> But you can't make the central change to drm_clflush_* without driver
> specific workarounds like this patch...

Good point. I'll do an i915 one when I find the time. I was still hoping to get
some numbers from Eero on this series.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx