dma-buf non-coherent mmap

[Lucas Stach]

Am Donnerstag, den 31.10.2013, 20:57 -0400 schrieb Rob Clark:
> On Thu, Oct 31, 2013 at 8:37 PM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> > On Fri, Nov 1, 2013 at 1:25 AM, Rob Clark <robdclark at gmail.com> wrote:
> >> On Thu, Oct 31, 2013 at 8:17 PM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> >>> On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> >>>> On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote:
> >>>>> On 10/31/2013 09:48 PM, Dave Airlie wrote:
> >>>>> >On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> >>>>> >>Well, I'd be happy to avoid mmap, but then what does optional mean in this
> >>>>> >>context?
> >>>>> >>That all generic user-space apps *must* implement a workaround if mmap isn't
> >>>>> >>implemented?
> >>>>> >>
> >>>>> >>It's unfortunate a bit like implicit synchronization mentioned in section 3)
> >>>>> >>in Direct Userspace Access/mmap Support
> >>>>> >>in the kernel dma-buf doc: It should be avoided, otherwise it might be
> >>>>> >>relied upon by userspace and exporters
> >>>>> >>not implementing it will suffer.
> >>>>> >>
> >>>>> >>In reality, people will start using mmap() and won't care to implement
> >>>>> >>workarounds if it's not supported, and drivers like
> >>>>> >>vmwgfx and non-coherent architectures will suffer.
> >>>>> >>
> >>>>> >>I haven't looked closely at how DRI3 or Wayland/weston use or will use
> >>>>> >>dma-buf, but if they rely on mmap, we're sort
> >>>>> >>of lost. MIR uses the following scheme:
> >>>>> >DRI3 and wayland won't use dma-buf mmap directly,
> >>>>> >
> >>>>> >using dma-buf mmap directly is wrong for anything that shares objects
> >>>>> >with itself.
> >>>>>
> >>>>> That sounds good to hear. Perhaps we should add that to the dma-buf docs.
> >>>>
> >>>> Userspace mmap was essentially added as a concession to the android ion
> >>>> guys since they really, really wanted it. We've tried to tell them that
> >>>> it's a horrible idea (see all the fun with coherency and syncing), but
> >>>> they said that they have userspace for it already and so we let it be.
> >>>>
> >>>> Imo if you're not running Android userspace there's no need for this at
> >>>> all.
> >>>
> >>> But now it turns out that gstreamer is using it and our life is hell. We should
> >>> have made it not work for _any_ driver if CONFIG_ANDRIOD wasn't set.
> >>
> >> well, at the moment mmap is only implemented by a few of the arm
> >> drivers, from the looks of it.  So I guess in the near term it is
> >> mostly going to be of interest to the SoC crowd.
> >
> > Ah okay, I thought this was desktop gstreamer.
> >

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.

> >> Not sure about the long term, perhaps we should see about
> >> turning gallium pipe_transfer/map stuff into a kernel interface
> >> (ioctl's directly on the dmabuf fd, perhaps?)
> >
> > Or they could just create a OpenGL context, I know it sounds heavy weight.
> > But somebody will eventually want to synchronize this with a different client
> > API in a non-blocking way. And OpenGL or some other Khronos API already
> > have that integration, no real need to reinvent the wheel. Then again I think
> > both GBM and DRI have hooks for mapping and unmapping buffers, so those
> > might suffice.
> 
> GL(ES) context might be a bit of a PITA, at least until open src mesa
> drivers are a bit more common in arm world.  But not really against a
> userspace API.. wonder how hard that would be to stuff in GBM?  At
> least that is a simple enough API that some sort of null-gbm "driver"
> could be made for folks who don't have GL(ES)..
> 
I already see the need for a dumb GBM driver for importing buffers into
plain KMS drivers, so we can stick them on a plane or something. The
only thing that crashes in here is GBM being a part of MESA. We
certainly don't want GStreamer to depend on MESA just to access some
buffers the right way.

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 |