[Linaro-mm-sig] dma-buf non-coherent mmap

[Benjamin Gaignard]

user-space cpu access to dma-buf is needed for example in Gstreamer
pipeline when you have mix of harware element (a video decoder) and
software element (like colorspace converter).

Gstreamer already support dma-buf in a specific gstallocator:
http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst-libs/gst/allocators/gstdmabuf.c

Regards,
Benjamin

2013/10/31 Thomas Hellstrom <thellstrom at vmware.com>:
> On 10/31/2013 10:10 PM, Rob Clark wrote:
>>
>> 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.
>
>
> I think that if direct user-space cpu-access to dma-buf is ever needed by
> linux,
> something like that is a better option. Best IMHO would be to avoid
> user-space
> cpu-access completely.
>
> Regards,
> /Thomas
>
>
>>
>> BR,
>> -R
>>
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog