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?<br><br><div class="gmail_quote">On Fri Nov 21 2014 at 10:45:08 AM Zachary Reizner <<a href="mailto:zachr@google.com">zachr@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ajax: The consumer of this will be software renderers. We're working on one right now that will be using dma-bufs from userspace.<br>Daniel: Thanks for your suggestions. I'll work on it and submit a v2.<br><div class="gmail_quote">On Fri Nov 21 2014 at 6:02:45 AM Adam Jackson <<a href="mailto:ajax@redhat.com" target="_blank">ajax@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2014-11-20 at 16:26 -0800, Zach Reizner wrote:<br>
> This patch implements the virtual GEM driver with PRIME sharing which<br>
> allows vgem to import a gem object from other drivers for the purpose<br>
> of mmap-ing them to userspace.<br>
<br>
The reason I initially wanted this was to get zero-copy llvmpipe, since<br>
(besides making GLX conformance impossible) the image transfer parts of<br>
drisw are easily the biggest part of the runtime overhead.  Is there a<br>
userspace consumer of this anywhere?<br>
<br>
- ajax<br>
<br>
</blockquote></div></blockquote></div>