[Intel-gfx] [PATCH 4/4] drm/i915: Opportunistically reduce flushing at execbuf

[Chris Wilson]

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...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre