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@xxxxxxxxxx>: > On 10/31/2013 10:10 PM, Rob Clark wrote: >> >> On Thu, Oct 31, 2013 at 4:40 PM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> >> wrote: >>> >>> On 10/31/2013 06:52 PM, Rob Clark wrote: >>>> >>>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom >>>> <thellstrom@xxxxxxxxxx> >>>> 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@xxxxxxxxxxxxxxxx > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
