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

[Chris Wilson]

On Wed, Jul 31, 2013 at 06:54:07PM +0300, Ville Syrjälä wrote:
> 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 :(

Yes. GFDT worked quite well, WT appears much easier to use though.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre