On Fri, Nov 1, 2013 at 6:17 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: >> GStreamer needs _some_ way of accessing the buffer contents with the >> CPU, this doesn't necessarily have to be the dumb mmap we have right >> now. >> DMA-BUF support in GSt is not really finished (I know we have a lot of >> patches internally to make it actually work with anything, which are >> trickling upstream right now), so this might be a good time to hammer >> out how it should be done, so we can adapt GSt before people start to >> rely on the dma-buf fallback mmap. >> >> I would think the bracketed mmap idea that was thrown around by Rob some >> time ago when the mmap topic first surfaced is simple enough that we >> don't need additional userspace helpers and should be enough to make the >> coherency issue disappear. > > Yeah, if we add a BEGIN_MMAP/END_MMAP ioctl or so to the dma-buf mmap > stuff and simply demand that userspace calls that we'd have something > half-sane at least. Since we currently don't really have any real > users we could still do this abi change I think. > > One open issue is whether the BEGIN_MMAP ioctl should also synchronize > with any outstanding gpu access. Imo it should, since that's pretty > much how all the current drm drivers work, but maybe we should reserve > space for a few flags so that this can be extended later on - Android > seems to be pretty insistent on using explicit syncpoints everywhere > instead of implicit synchronization. Or maybe we should have the flag > already, but reject implicit syncing until Maarten's dma_fence stuff > is in and enabled, dunno. Adding him to cc. I suppose I wouldn't mind if we made BEGIN/END_MMAP as sort of clones of the CPU_PREP/FINI ioctls I have in msm.. where the CPU_PREP takes a flag/bitmask to indicate READ/WRITE/NOSYNC That doesn't really help with partial buffer access, like you'd get if you were using the buffer for vertex upload. Although not really sure if we'd be seeing dmabuf's for that sort of use-case. We could make a more elaborate kernel interface that maps better to all the different cases in pipe_transfer. Or we could just say that that is overkill. I don't really have strong opinion about that (so someone who does, send an RFC). But I do agree with the "barriers only, not locks". BR, -R > The clear thing otoh is that these two ioctls should only serve as > barriers, not as locks as has been proposed in some other RFCs > floating around (iirc the one from exynos was borked in this fashion). > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
