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@xxxxxxxxx> wrote:On Fri, Jan 17, 2014 at 6:43 AM, Rian Quinn <rianquinn@xxxxxxxxx> 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,
-RThanks,
- Rian_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
