On Mon, May 18, 2020 at 12:11:32PM +0200, Gerd Hoffmann wrote: > On Mon, May 18, 2020 at 10:50:15AM +0200, Thomas Zimmermann wrote: > > Hi Gerd > > > > Am 18.05.20 um 10:23 schrieb Gerd Hoffmann: > > >>> $ git grep drm_gem_shmem_mmap > > >>> > > >>> We also need correct access from userspace, otherwise the gpu is going to > > >>> be sad. > > >> > > >> I've been thinking about this, and I think it means that we can never > > >> have cached mappings anywhere. Even if shmem supports it internally for > > >> most drivers, as soon as the page are exported, the importer could > > >> expect uncached memory. > > > > > > The importer should not expect anything but call dma-buf ops so the > > > exporter has a chance to handle this correctly. > > > > I have the following case in mind: Suppose the exporter maps cached > > pages and the importer expects uncached pages for DMA. There is > > map_dma_buf/unmap_dma_buf, which can implement a cache flush for the > > cached pages. Is it guaranteed that the importer calls this around each > > DMA operation? > > I think the importer is supposed to do that, but I wouldn't surprised if > there are cases in tree where this isn't implemented correctly ... Yup, this is very much a case of "supposed to" but "in practice, many actually dont". The reason is that setting up mappings is expensive, so best avoid. We filled that gap a few years after dma-buf landed with the begin/end_cpu_access hooks, which allow the exporter to do cache flushing (using something like dma_sync_sg_for_device/cpu) and for this to all work properly. We even added ioctl so that the mmap on the dma-buf works correctly. But most importers still ignore this, so it's all fail :-/ But in theory the pieces to make cached mappings work over dma-buf, even for importers that need uncached, are all there. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
