On Thu, Oct 31, 2013 at 8:37 PM, Jakob Bornecrantz <wallbraker@xxxxxxxxx> wrote: > On Fri, Nov 1, 2013 at 1:25 AM, Rob Clark <robdclark@xxxxxxxxx> wrote: >> On Thu, Oct 31, 2013 at 8:17 PM, Jakob Bornecrantz <wallbraker@xxxxxxxxx> wrote: >>> On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxxxx> 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. > >> 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).. BR, -R > Cheers, Jakob. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
