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:54:07 +0300 Message-ID: <20130731155407.GG5004@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> <20130731151614.GF5004@intel.com> <20130731152641.GD3637@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 C9492E6A68 for ; Wed, 31 Jul 2013 08:54:13 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20130731152641.GD3637@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 04:26:41PM +0100, Chris Wilson wrote: > On Wed, Jul 31, 2013 at 06:16:14PM +0300, Ville Syrj=E4l=E4 wrote: > > 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 sp= elled > > > > out there. This would only be an issue when using MOCS since you ca= n'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 h= as > > > to worry about L3. > > = > > The problem would only occur when we have a an non-LLC cached scanout b= uffer > > which gets marked as L3 cacheable via MOCS. BSpec says that if stuff is= evicted > > 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 st= ale > > garbage. > = > That's true (for all LLC machines), Well, I guess all LLC machines w/ L3, ie. IVB+. So basically it means that scanout surfaces should never be marked as either L3 or LLC cacheable via MOCS. I suppose GFDT would save us here, even in the L3 evicition case, except it's not guaranteed to work on HSW :( -- = Ville Syrj=E4l=E4 Intel OTC