dma-buf non-coherent mmap

[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.
>
>> 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.