dma-buf non-coherent mmap

[Thomas Hellstrom]

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:
>> On 10/31/2013 06:52 PM, Rob Clark wrote:
>>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom <thellstrom at vmware.com>
>>> wrote:
>>>> Hi!
>>>>
>>>> I'm just looking over what's needed to implement drm Prime / dma-buf
>>>> exports
>>>> + imports in the vmwgfx driver. It seems like most dma-bufs ops are quite
>>>> straightforward to implement except user-space mmap().
>>>>
>>>> The reason being that vmwgfx dma-bufs will be using completely
>>>> non-coherent
>>>> memory, whenever there needs to be CPU accesses.
>>>>
>>>> The accelerated contents resides in an opaque structure on the device
>>>> into
>>>> which we can DMA to and from, so for mmap to work we need to zap ptes and
>>>> DMA to the device when doing something accelerated, and on the first
>>>> page-fault DMA data back and wait for idle if the device did a write to
>>>> the
>>>> dma-buf.
>>>>
>>>> Now this shouldn't really be a problem if dma-bufs were only used for
>>>> cross-device sharing, but since people apparently want to use dma-buf
>>>> file
>>>> handles to share CPU data between processes it really becomes a serious
>>>> problem.
>>>>
>>>> Needless to say we'd want to limit the size of the DMAs, and have mmap
>>>> users
>>>> request regions for read, and mark regions dirty for write, something
>>>> similar to gallium's texture transfer objects.
>>>>
>>>> Any ideas?
>>> well, I think vmwgfx is part of the reason we decided mmap would be
>>> optional for dmabuf.  So perhaps it is an option to simply ignore
>>> mmap?
>>>
>>> BR,
>>> -R
>>
>> 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.

> I personally wish we hadn't added mmap support to dma-buf at all, but
> some people
> had some use cases that they'll never implement.
>
> If you export a dma-buf to be used by a client it should be using
> drivers on the client
> to import the dma-buf and then it should be using mesa.
Agreed.

/Thomas

>
> Dave