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/all...
Regards, Benjamin
2013/10/31 Thomas Hellstrom thellstrom@vmware.com:
On 10/31/2013 10:10 PM, Rob Clark wrote:
On Thu, Oct 31, 2013 at 4:40 PM, Thomas Hellstrom thellstrom@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@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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig