Re: [PATCH] drm/vgem: implement virtual GEM

[Zachary Reizner <zachr@xxxxxxxxxx>]

After looking into removing platform_device, I found that using dma_buf_attach with a NULL device always returns an error, thereby preventing me from using VGEM for import and mmap. The solution seems to be to skip using dma_buf_attach, and instead use dma_buf_mmap when user-space tries to mmap a gem object that was imported into VGEM. The drawback to this approach is that most drivers stub their dma_buf_ops->mmap implementation. Presumably mmap could be implemented for the drivers that this would make sense for. Are there any comments, questions, or concerns for this proposed solution?

On Fri Nov 21 2014 at 10:45:08 AM Zachary Reizner <zachr@xxxxxxxxxx> wrote:

ajax: The consumer of this will be software renderers. We're working on one right now that will be using dma-bufs from userspace.
Daniel: Thanks for your suggestions. I'll work on it and submit a v2.

On Fri Nov 21 2014 at 6:02:45 AM Adam Jackson <ajax@xxxxxxxxxx> wrote:

On Thu, 2014-11-20 at 16:26 -0800, Zach Reizner wrote:
> This patch implements the virtual GEM driver with PRIME sharing which
> allows vgem to import a gem object from other drivers for the purpose
> of mmap-ing them to userspace.

The reason I initially wanted this was to get zero-copy llvmpipe, since
(besides making GLX conformance impossible) the image transfer parts of
drisw are easily the biggest part of the runtime overhead.  Is there a
userspace consumer of this anywhere?

- ajax

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel