Re: [RFC PATCH] drm/vgem: virtual GEM provider

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Jan 11, 2012 at 02:19:21PM -0500, Adam Jackson wrote:
> 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>

I like this and the userspace abi is pretty much what I expect for such a
beast. I think integration with other drivers/dma_buf can just happen with
prime, nothing special needed. A few quick comments on the code
- no need to allocate a gem mmap offset if you only expose the direct shm
  mmap. This also will make the BUG in _fault correct, otherwise userspace
  could try to mmap well-guessed ranges on the fd and hit this.
- unsigned int in ioctl structs instead if __u32 (and also use __u64).
- I don't see why you have a size arg for the mmap ioctl, simply mapping
  the entire bo is likely all you ever want.
- The fops is inline instead of separate and constified.

Otherwise I couldn't find anything to complain about ;-)

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48