[Intel-gfx] [PATCH] drm/i915: Use Write-Through cacheing for the display plane on Iris
Ville Syrjälä
ville.syrjala at linux.intel.com
Wed Jul 31 17:16:14 CEST 2013
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 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älä
Intel OTC
More information about the Intel-gfx
mailing list