Re: [PATCH] drm/i915: Use Write-Through cacheing for the display plane on Iris

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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älä 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älä 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 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 stale
> > 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älä
Intel OTC