On Thu, Dec 10, 2015 at 03:06:55PM +0100, Daniel Vetter wrote: > On Wed, Dec 09, 2015 at 03:52:52PM +0000, Dave Gordon wrote: > > In a few places, we fill a GEM object with data, or overwrite some > > portion of its contents other than a single page. In such cases, we > > should mark the object dirty so that its pages in the pagecache are > > written to backing store (rather than discarded) if the object is > > evicted due to memory pressure. > > > > The cases where only a single page is touched are dealt with in a > > separate patch. > > > > This incorporates and supercedes Alex Dai's earlier patch > > [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted > > > > Signed-off-by: Dave Gordon <david.s.gordon@xxxxxxxxx> > > Cc: Alex Dai <yu.dai@xxxxxxxxx> > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Hm, did you drop the begin_cpu_access dma-buf one here? See my other mail, > I think that one was legit. I thought begin-access was the sync point around the per-page mmap(), but reading the current code "in kernel users", of which it is just drm/udl. How would we interact with a future dma-buf mmap()? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx