dma-buf non-coherent mmap

[Rob Clark]

On Thu, Oct 31, 2013 at 4:40 PM, 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?

well, mmap was mostly just added because it was needed by android for
ION on dmabuf.

I think it is an option to just not use dmabuf mmap in a linux
userspace.  I mean, we could also define some ioctls to give us pwrite
and other similar sort of functionality if it is needed.

BR,
-R

> 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:
> 1) Create a GBM buffer
> 2) Get a Prime handle, export to client
> 3) Client imports prime handle, casts into a GBM buffer which is typecast to
> a dumb buffer
> 4) Client uses DRM dumb mmap().   :(.
>
> Now, step 3) and step 4) are clearly API violations, but it works by
> coincidence on major drivers.
> Now this usage-pattern could easily (and IMHO should) be blocked in DRM by
> refusing to map dumb buffers
> that haven't been created as dumb buffers, but If dma-bufs are to be shared
> by user-space apps to transfer
> contents in this manner, we need a reliable replacement that works also for
> non-coherent situations.
>
> Ideally I'd like to see tex[sub]image-like operations, but with dma-buf mmap
> in place, I'm afraid that's what will
> be used...
>
> Regars,
> Thomas
>
>
>
>
>
>
>
>
>
>
>
>
>>
>>> /Thomas
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel