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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
