Am Freitag, den 01.11.2013, 09:22 -0400 schrieb Rob Clark: > 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 don't think we need that right now. We may prepare for implicit sync by having the flag ready in the API, but don't force the exporters to implement it right now. > 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". > I just checked back with our GStreamer guy and he thinks that for the use-cases he sees today it would make a lot of sense to have some way to indicate that userspace is only going to access a partial range of the buffer. I think this may be a crucial optimization on all kinds of devices where you have to ensure coherency manually. Personally I would like to have the same kind of partial access indicators in DRMs cpu_prep/fini to optimize all the userspace suballocations we have today. I think we are all on the same page with the barriers only thing. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
