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), but that wasn't the point I thought you were making. I thought we were arguing about CPU coherency, and whether the CPU would see the bits evicted from L3 into LLC irrespective of whether the PTE was marked as LLC or UC. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
