[Intel-gfx] [PATCH] drm/i915: Avoid using mappable space for relocation processing through the CPU

[Daniel Vetter]

On Tue, Nov 29, 2011 at 06:17:21PM +0100, Daniel Vetter wrote:
> On Tue, Nov 29, 2011 at 06:03:53PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 29, 2011 at 04:48:15PM +0000, Chris Wilson wrote:
> > > On Tue, 29 Nov 2011 16:34:41 +0100, Daniel Vetter <daniel at ffwll.ch> wrote:
> > > > On Tue, Nov 29, 2011 at 03:12:40PM +0000, Chris Wilson wrote:
> > > > > We try to avoid writing the relocations through the uncached GTT, if the
> > > > > buffer is currently in the CPU write domain and so will be flushed out to
> > > > > main memory afterwards anyway. Also on SandyBridge we can safely write
> > > > > to the pages in cacheable memory, so long as the buffer is LLC mapped.
> > > > > In either of these caches, we therefore do not need to force the
> > > > > reallocation of the buffer into the mappable region of the GTT, reducing
> > > > > the aperture pressure.
> > > > > 
> > > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > 
> > > > The error_state capture currently relies on us pinning buffers as mappable
> > > > when they contain relocations (and userspace always submitting a
> > > > batchbuffers containing relocations). You break that guarantee without
> > > > fixing up the error capture code. Otherwise I like this.
> > > 
> > > I may have sent that patch a little earlier. ;-)
> > 
> > Yes, I know. My gripe is that this will reduce our chances of successfully
> > capturing the error_state, because now we expect to hit that case in the
> > error capture code whereas up to now it would have been a bug somewhere.
> > So either
> > - fixup the error_capture to fall back to cpu reads (needs the usual
> >   clflush dance if the object is not llc cached)
> > - or drop the pin mappable change in this patch.
> 
> After some irc discussion with Dave Airlie I think a simple wmb() to flush
> the wc buffer might make more sense. I'll try to run that past testers and
> gather results. Will take at least a week to get anything conclusive.

Meh, replied to the wrong mail ...
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48