On Fri, Nov 1, 2013 at 6:40 AM, 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? > > 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. 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. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
