[PATCH] drm/vgem: implement virtual GEM

[Zachary Reizner]

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 at google.com> 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 at redhat.com> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/b72310a0/attachment.html>