On 10/31/2013 09:48 PM, Dave Airlie wrote: > 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.
That sounds good to hear. Perhaps we should add that to the dma-buf docs. > 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. Agreed. /Thomas > > Dave
