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@gmail.com wrote:
On Fri, Jan 17, 2014 at 6:43 AM, Rian Quinn rianquinn@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel