dma-buf non-coherent mmap

[Rob Clark]

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

> /Thomas
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel