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@xxxxxxxxxxxxxxxxxx> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > 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). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
