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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
