Re: [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages

From: Daniel Vetter <daniel@ffwll.ch>
To: "Chris Wilson" <chris@chris-wilson.co.uk>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, "Goel,
	Akash" <akash.goel@intel.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Jesse Barnes" <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
Date: Wed, 12 Aug 2015 14:35:59 +0200	[thread overview]
Message-ID: <20150812123559.GF17734@phenom.ffwll.local> (raw)
In-Reply-To: <20150807130739.GE6924@nuc-i3427.alporthouse.com>

On Fri, Aug 07, 2015 at 02:07:39PM +0100, Chris Wilson wrote:
> On Fri, Aug 07, 2015 at 01:55:01PM +0200, Daniel Vetter wrote:
> > On Fri, Aug 07, 2015 at 11:10:58AM +0100, Chris Wilson wrote:
> > > On Fri, Aug 07, 2015 at 10:07:28AM +0200, Daniel Vetter wrote:
> > > > On Thu, Aug 06, 2015 at 05:43:39PM +0100, Chris Wilson wrote:
> > > > But it's still salvageable I think since we only care about coherency for
> > > > the gpu (where data might be stuck in cpu caches). From the cpu's pov (and
> > > > hence the entire system except the gpu) we should never see inconsistency
> > > > really - as soon as the gpu does a write to a cacheline it'll win, and
> > > > before that nothing in the system can assume anything about the contents
> > > > of these pages.
> > > 
> > > But the GPU doesn't write to cachelines (except in LLC/snooped+flush).
> > > The issue is what happens when the user lies about writing to the object
> > > through a WB cpu mapping (dirtying a cacheline) and the GPU also does.
> > > Who wins then?
> > > 
> > > We have postulated that it could be entirely possible for the CPU to
> > > trust it cache and return local contents and for those to be also
> > > considered not dirty and so not flushed to memory. Later, we then read
> > > what the gpu wrote and choas ensues.
> > 
> > This was just with an eye towards purged memory where we don't care about
> > correct data anyway. The only thing we care about is that when it's all
> > overwritten again by someone, that someone should win. And since GEM
> > assumes new pages are in the cpu domain and clflushes them first that
> > should hold even for GEM. But the tricky part is that I think we can pull
> > this off only if the backing storage is purged already.
> 
> But what's the difference between:
> 
> lock
>   put_pages
>   purge
> 
> and
> 
> lock
>   purge
>   put_pages
> 
> if you are dismissing the user dirtying CPU cachelines vs already dirty
> GPU data as being a source of worry?

Just worrying that eventually we'll change something and end up without
the purge after put_pages. If we reorder we can't get it wrong.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx