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