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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
