From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH] drm/i915: Drop the overzealous warning from
 i915_gem_set_cache_level
Date: Wed, 14 Aug 2013 12:01:46 +0200
Message-ID: <20130814100146.GS9296@phenom.ffwll.local>
References: <1376304377-11695-1-git-send-email-chris@chris-wilson.co.uk>
	<20130813121259.GE7159@intel.com>
	<20130813122013.GA3885@cantiga.alporthouse.com>
	<20130813123756.GF7159@intel.com>
	<20130814084911.GP9296@phenom.ffwll.local>
	<20130814085405.GK6390@cantiga.alporthouse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com
	[209.85.215.182])
	by gabe.freedesktop.org (Postfix) with ESMTP id 2F230439C8
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 14 Aug 2013 03:01:39 -0700 (PDT)
Received: by mail-ea0-f182.google.com with SMTP id o10so4679589eaj.41
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 14 Aug 2013 03:01:38 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20130814085405.GK6390@cantiga.alporthouse.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Chris Wilson <chris@chris-wilson.co.uk>, Daniel Vetter <daniel@ffwll.ch>, Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Wed, Aug 14, 2013 at 09:54:05AM +0100, Chris Wilson wrote:
> On Wed, Aug 14, 2013 at 10:49:11AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 13, 2013 at 03:37:56PM +0300, Ville Syrj=E4l=E4 wrote:
> > > On Tue, Aug 13, 2013 at 01:20:13PM +0100, Chris Wilson wrote:
> > > > On Tue, Aug 13, 2013 at 03:12:59PM +0300, Ville Syrj=E4l=E4 wrote:
> > > > > Thinking about this stuff a bit, I think I actually came up with a
> > > > > scenario where we would currently fail to invalidate the CPU cache
> > > > > between non-snooped GPU/GTT access and CPU access:
> > > > > =

> > > > > 1. make bo non-snooped w/ pin_display=3Dtrue (wd=3D0, rd|=3Dgtt)
> > > > > 2. set to CPU read domain (wd=3D0 rd|=3Dcpu)
> > > > > 3. set to GTT (or GPU) write domain (wd=3Dgtt, rd=3Dgtt) -> CPU c=
ache is stale after this point
> > > > > 4. make bo snooped -> pin_display=3Dtrue still so we directly set=
 (wd=3Dcpu, rd=3Dcpu)
> > > > > 5. set to CPU domain -> CPU cache is still stale
> > > > =

> > > > You will also find the scanout reads stale data as well.
> > > =

> > > Well, assuming you actually write something to the bo w/ the CPU. If
> > > not, then it keeps scanning out the correct data.
> > =

> > I think an if (obj->pin_display) return -EBUSY; in the set_caching ioctl
> > would be good to fix this.
> =

> And we already do that check (as a result of obj->pin_count).
> Sorted.

Indeed. Patch merged to dinq (with a pimped commit message), thanks.
-Daniel
-- =

Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch