dma-buf non-coherent mmap

[Dave Airlie]

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.

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.

Dave.