Re: [PATCH] drm/i915: Disable caches for Global GTT.

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Nov 06, 2014 at 10:55:12AM +0000, Chris Wilson wrote:
> On Wed, Nov 05, 2014 at 12:11:41PM +0100, Daniel Vetter wrote:
> > On Thu, Oct 30, 2014 at 5:18 PM, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> > > Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000;
> > > So the only way to avoid screen corruptions is setting PAT 0 to Uncached.
> > >
> > > MOCS can still be used though. But if userspace is trusting PTE for
> > > cache selection the safest thing to do is to let caches disabled.
> > >
> > > BSpec: "For GGTT, there is NO pat_sel[2:0] from the entry,
> > > so RTL will always use the value corresponding to pat_sel = 000"
> > >
> > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85576
> > > Cc: James Ausmus <james.ausmus@intel.com>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > 
> > Ok, I think this is -fixes + cc: stable material, but we need to be a
> > bit more elaborate on the commit message:
> > 
> > - System agent ggtt writes (i.e. cpu gtt mmaps) already work before
> > this patch, i.e. the same uncached + snooping access like on gen6/7
> > seems to be in effect.
> > - So this just fixes blitter/render access. Again it looks like it's
> > not just uncached access, but uncached + snooping. So we can still
> > hold onto all our assumptions wrt cpu clflushing on LLC machines.
> > 
> > I think this should be both in the commit message and code.
> > 
> > Chris, please correct if I've summarized this wrongly.
> 
> Me, I just get confused by the statement that writes through the System
> Agent to main memory are snooped.
> 
> But the statement that GTT + WC is coherent with the display as it was
> on SNB+ is certainly true.

I have a supicious mind so I simply had to go and verify this on my
IVB. Writes to a LLC cacheable scanout buffer through a GTT mmap did
not result in any cache dirt on the screen. So I must admit defeat.

I also did another experiment where I wrote the data through a cpu
mmap, which obviously resulted in plenty of cache dirt. But I then
followed it with a read through the GTT mmap (obj still mapped as
cacheable in GTT), and the data matched what I wrote, and it also
cleared the cache dirt from the screen. So any CPU GTT access will
snoop the caches and also causes a writeback of the cacheline. I
suspect it also invalidates the cacheline, but I didn't verify that
in any way.

So I guess I can rest easier now having witnessed it all with mine
own eyes :)

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx