Hi Am 18.05.20 um 16:40 schrieb Daniel Vetter: > 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. Thanks to both of you for answering the question. > > 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 > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
