On Thu, 16 Feb 2012 05:52:12 -0800 (PST) Jakob Bornecrantz <jakob@xxxxxxxxxx> wrote: > ----- Original Message ----- > > From: Adam Jackson <ajax@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
