Sharing Framebuffers between Client / Server

[Rian Quinn]

Thanks for reply. 


Actually in my case, when I say client/server, I mean replacement for X, so XShmPutImage won’t work. What we are trying to do is actually similar to Wayland, and need to provide each client with a scannot buffer for direct rendering, while at the same time, providing a means for the server to read/write to all of the scannot buffers. 


We have looked into EGL (EGL_DRM_BUFFER_USE_SCANOUT_MESA), but I have yet to code this up (will likely work on that this week), to see if it will work for us.


We started with an example that we found, that was coded wrong in many ways. The biggest issue though, was that the buffer allocated using libkms could not be shared. We also looked into drmAddBuf / drmMapBuf, from what I could tell, nobody was using them. GEM seems to be the option of choice but vmwgfx doesn’t support that yet.


Thanks,
- Rian




Sent with Unibox



> On Jan 20, 2014, at 8:10 AM, Rob Clark <robdclark at gmail.com> wrote:
> 
> 
> 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
>> 
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/53a1370a/attachment.html>