[Intel-gfx] [PATCH] drm/i915: Treat foreign dma-buf imports as uncached

[Chris Wilson]

On Tue, Aug 11, 2015 at 02:58:59PM +0200, Daniel Vetter wrote:
> On Tue, Aug 11, 2015 at 11:24:58AM +0100, Chris Wilson wrote:
> > On Tue, Aug 11, 2015 at 12:12:08PM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 10, 2015 at 09:16:46PM +0100, Chris Wilson wrote:
> > > > If the set of pages is being imported from another device, we cannot
> > > > assume that it is fully coherent with the CPU cache, so mark it as such.
> > > > However, if the source is the shared memory vgem allocator, we could
> > > > treat the buffer as being cached (so long as all parties agree in the
> > > > case the same buffer is shared between multiple devices) but as of
> > > > today, vgem cannot export dma-bufs.
> > > > 
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > 
> > > Yay for x86 dma api to refuse acknowleding that incoherent devices exist
> > > (since this should be done in the dma-ap/sg stuff imo for dma-bufs).
> > > 
> > > But since x86 assumes that everything is coherent shouldn't we do the
> > > inverse and use snooping/cacheable always?
> > 
> > Actually, the convention for PRIME is that transfer bos are uncached
> > because we have to be sure that any write makes it into the foriegn
> > pages, that applies to both GPU and CPU writes, precisely because the
> > target is *incoherent*.
> > 
> > > That should be correct for everything modern at least, and for old agp
> > > crap (do we care even, is sharing possible there?) snooping should only
> > > result in a bit more overhead.
> > > 
> > > Or where exactly does this blow up?
> > 
> > Consider a kms_crc-esque test using a radeon/nouveau bo imported into
> > i915 and accessed using i915 ioctls (with the CRC testing on the radeon
> > scanout).
> 
> Scanout on radeon must be in vram afaik, and that's a place i915 can't get
> at. I think that even holds true for the integrated radones (they just use
> stolen for vram then).
> 
> The other way round also doesn't work I think since i915 can't change the
> caching policy for radoen/nouveau access if radeon/nouveau want to write
> directly to main memory. Otoh I think pcie transactions just snoop the
> cache and never put anything in there.
> 
> I still think that everything we import and don't have a clue about should
> probably be treated as snooped conceptually. But practically who knows
> what's going on ...

I'd say setting as uncached is safer. But at the moment, the policy is
just whatever the platform default is and that leads to interesting
platform specific behaviour.

At the very least we do want snooping if we ever do get a shmem dma-buf
source.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre