Sharing Framebuffers between Client / Server

[Rob Clark]

On Fri, Jan 17, 2014 at 6:43 AM, Rian Quinn <rianquinn at gmail.com> wrote:
> I am working on a client/server program, where the server creates (and has
> access to a framebuffer), and then needs to share this framebuffer with a
> client program so that this client program can draw into the framebuffer
> directly (i.e. no memcpy).
>
> I am trying to figureout what the “cleanest” way to do this is, such that I
> can support Intel’s proprietary driver, the open source AMD and NVidia
> drivers, and the VMWare driver (I have no need for the proprietary
> ADM/NVidia drivers right now). From what I can tell, GEM is one way to do
> this. The problem is VMWare doesn’t support GEM.
>
> I tried (knowing it would not work), using KMS to create the framebuffer,
> and then sending the information needed to mmap to the client. This of
> course failed because the framebuffer is marked non-sharable in the kernel.

Dmabuf (or just plain old egl/glx which uses dri2 under the hood)
would probably be what I suggest *except* you mention mmap.  If you
are doing software rendering, I guess you probably just want to suck
it up and do XShmPutImage.

>From what I understand, any sort of mmap access to vmwgfx buffers is
tricky, because they end up being backed by normal GL textures on the
host OS side (IIUC).  So the single copy upload path in XShmPutImage
might be close to the ideal path for sw rendered content.

> To be clear, I am fine having to manually write ioctls for each driver, if
> thats what it takes. But at this point, I am at a loss on the best method to
> share scannot buffers (or at least in a way that doesn’t make someone cringe
> when they see my code).

Some sort of prepare/finish access ioctls for dmabuf to bracket mmap
access are, I think, what vmwgfx is missing in order to implement
dmabuf mmap.  But no one so far has needed them badly enough to come
up with something and send patches.

IIUC, for vmwgfx there would still be a copy back to original texture
on the host on finish-access, so it might not amount to anything much
different from XShmPutImage.  Probably better to ask some vmwgfx folks
to clarify, since the virtual driver has some unique constraints which
I may not be adequately representing.

BR,
-R

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