Re: [PATCH v2 2/2] drm/i915/bxt: work around HW coherency issue for cached GEM mappings

From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>,
	intel-gfx@lists.freedesktop.org,
	Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH v2 2/2] drm/i915/bxt: work around HW coherency issue for cached GEM mappings
Date: Fri, 14 Aug 2015 16:29:13 +0300	[thread overview]
Message-ID: <1439558953.31146.11.camel@intel.com> (raw)
In-Reply-To: <20150814131146.GD27217@nuc-i3427.alporthouse.com>

On pe, 2015-08-14 at 14:11 +0100, Chris Wilson wrote:
> On Fri, Aug 14, 2015 at 03:38:57PM +0300, Imre Deak wrote:
> > Due to a coherency issue on BXT A steppings we can't guarantee a
> > coherent view of cached GPU mappings, so fall back to uncached mappings.
> > Note that this still won't fix cases where userspace expects a coherent
> > view without synchronizing (via a set domain call). It still makes sense
> > to limit the kernel's notion of the mapping to be uncached, for example
> > for relocations to work properly during execbuffer time. Also in case
> > user space does synchronize the buffer, this will still guarantee that
> > we'll do the proper clflushing for the buffer.
> > 
> > v2:
> > - limit the WA to A steppings, on later stepping this HW issue is fixed
> 
> This has to report the failure, ENODEV otherwise userspace will be
> terribly confused (it will try to CPU coherent access assuming it will
> be fast, when it is better to use alternative paths).

Ok, I was not sure how existing user space would handle the failure, but
if it has the fall-back logic then ENODEV is the better solution. Will
change this.

> -Chris
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx