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. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
