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

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, "Goel,
	Akash" <akash.goel@intel.com>
Subject: Re: [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
Date: Fri, 7 Aug 2015 11:10:58 +0100	[thread overview]
Message-ID: <20150807101058.GB6924@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <20150807080728.GJ17734@phenom.ffwll.local>

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.
-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