Re: [PATCH 2/2 v2] drm/i915: mark GEM objects dirty after overwriting their contents

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2 v2] drm/i915: mark GEM objects dirty after overwriting their contents
Date: Thu, 10 Dec 2015 14:52:57 +0000	[thread overview]
Message-ID: <20151210145257.GA11596@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <20151210140655.GO20822@phenom.ffwll.local>

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@intel.com>
> > Cc: Alex Dai <yu.dai@intel.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> 
> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx