[Intel-gfx] [PATCH 61/66] drm/i915: Use multiple VMs

[Daniel Vetter]

On Tue, Jul 02, 2013 at 12:38:33PM +0100, Chris Wilson wrote:
> On Tue, Jul 02, 2013 at 02:34:59PM +0300, Ville Syrjälä wrote:
> > On Tue, Jul 02, 2013 at 12:07:10PM +0100, Chris Wilson wrote:
> > > On Tue, Jul 02, 2013 at 01:58:13PM +0300, Ville Syrjälä wrote:
> > > > Also IIRC someone told me that w/ uncached mappings the caches aren't
> > > > snooped even on LLC platforms. If that's true, MOCS seems even more
> > > > dangerous since the client could easily mix cached and uncached
> > > > accesses. I don't really understand why uncached mappings wouldn't
> > > > snoop on LLC platforms since the snooping should be more or less free.
> > > 
> > > Who said that? Doesn't appear to be the case on SNB/IVB/HSW as far as I
> > > can tell.
> > 
> > Can't remember now who said it, or could be I just misunderstood. But if
> > it's not true, then MOCS seems actually useful. Otherwise it's going to
> > be a clflush fest when you want to change from cached to uncached.
> 
> Well MOCS doesn't apply for GTT access by the CPU, so there you only
> need to be concerned about whether you are rendering to a scanout. That
> is tracked in the ddx, but as you point out mesa would have to assume
> that any winsys buffer is a potential scanout unless we add an interface
> for it to ask the display server.

I think userspace should make damn sure that it doesn't change the cache
level (i.e. snooped vs. non-snooped or that special write-back mode we
have on some hsw machines). Otherwise we'd be indeed screwed up since the
clflush tracking done by the kernel would be screwed up.

But thus far all the MOCS stuff seems to only be used to select in which
caches and at what age we should allocate cachelines ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch