On 10/31/2013 09:48 PM, Dave Airlie wrote:
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.
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
