From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm/i915: Drop the overzealous warning from i915_gem_set_cache_level Date: Tue, 13 Aug 2013 15:37:56 +0300 Message-ID: <20130813123756.GF7159@intel.com> References: <1376304377-11695-1-git-send-email-chris@chris-wilson.co.uk> <20130813121259.GE7159@intel.com> <20130813122013.GA3885@cantiga.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by gabe.freedesktop.org (Postfix) with ESMTP id 4AEE0E6D9B for ; Tue, 13 Aug 2013 05:38:00 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20130813122013.GA3885@cantiga.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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 cache i= s 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. > You've managed > to shoot yourself in both feet. The kernel can't fix that, so should we > care about the other foot? Yeah, I suppose we shouldn't care too much about problems the user created for himself. -- = Ville Syrj=E4l=E4 Intel OTC