On Thu, 16 Feb 2012 05:52:12 -0800 (PST) Jakob Bornecrantz jakob@vmware.com wrote:
----- Original Message -----
From: Adam Jackson ajax@redhat.com
This is about as minimal of a virtual GEM service as possible. My plan is to use this with non-native-3D hardware for buffer sharing between X and DRI.
The current drisw winsys assumes an unmodified X server, which means it's hopelessly inefficient for both the push direction of SwapBuffers/DrawPixels and the pull direction of GLX_EXT_texture_from_pixmap. I'm still working through the details of what the xserver support will look like, but in broad strokes it's "use vgem for CreatePixmap and optionally the shadowfb".
Obviously alpha quality, mostly looking for feedback on the approach or any glaring bugs. Eventually I'd like to see solutions for sharing gem objects between drm devices and/or the dma_buf API, but that's a ways down the road.
Signed-off-by: Adam Jackson ajax@redhat.com
Any reason why you are not using the dumb_bo interface? I at least would like to be able to offer vgem on the vmwgfx device when the host has disabled 3D.
Cheers, Jakob.
I thought dumb bo interface was an extension for an existing DRM GEM driver. In my case, for prototyping dma_buf support, this is non-ideal. I'm not sure what Adam thinks of this though (I imagine he wants a device independent driver though).
I may be completely off.