From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm/i915: Use Write-Through cacheing for the display plane on Iris Date: Wed, 31 Jul 2013 18:16:14 +0300 Message-ID: <20130731151614.GF5004@intel.com> References: <1375206312-8107-1-git-send-email-chris@chris-wilson.co.uk> <1375212356-8665-1-git-send-email-chris@chris-wilson.co.uk> <20130731131640.GD5004@intel.com> <20130731133639.GA3637@cantiga.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id A94D3E73DE for ; Wed, 31 Jul 2013 08:16:17 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20130731133639.GA3637@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, Kenneth Graunke List-Id: intel-gfx@lists.freedesktop.org On Wed, Jul 31, 2013 at 02:36:39PM +0100, Chris Wilson wrote: > On Wed, Jul 31, 2013 at 04:16:40PM +0300, Ville Syrj=E4l=E4 wrote: > > Also while looking through BSpec I noticed a slightly worrying note. > > Apparently, on HSW at least, L3/not-LLC cacheable surfaces can > > still evict dirty lines from L3 to LLC. The IVB flow diagrams leave me = to > > think IVB could behave the same way, even though it's not really spelled > > out there. This would only be an issue when using MOCS since you can't > > configure such a caching mode through the PTEs alone. > = > Afaict, the render write flush is sufficient to write the dirty cache > lines to LLC/UC memory, so from the kernel/CPU perspective it never has > to worry about L3. The problem would only occur when we have a an non-LLC cached scanout buffer which gets marked as L3 cacheable via MOCS. BSpec says that if stuff is evi= cted from L3 it may land in LLC regardless of the LLC cacheability bits. The data would then remain in LLC and would not get flushed to memory as that would require an explicit clflush. And in the end we'd scan out some stale garbage. That's for HSW at least. For IVB I'm not sure. It may be that L3 and LLC are supposed to be inclusive so if you have something in L3 it must also be present in LLC. I've seen some old training material about MLC that stated as much, but I don't know if that design was actually carried over to IVB. -- = Ville Syrj=E4l=E4 Intel OTC