dma-buf non-coherent mmap

[Lucas Stach]

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 at ffwll.ch> wrote:
> > On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach <l.stach at pengutronix.de> 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 |