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