Re: [PATCH 1/5] drm/vgem: virtual GEM provider

[Ben Widawsky <benjamin.widawsky@intel.com>]

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.