[RFC PATCH] drm/vgem: virtual GEM provider

[Eric Anholt]

On Wed, 11 Jan 2012 14:19:21 -0500, Adam Jackson <ajax at redhat.com> 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.

I remember at one point you had a plan along the lines of passing shmem
fds across the protocol.  I'm curious what happened to that -- too hard
to get the passing to work, or something else?  I'm just thinking of
kernel developer grumbling that you've duplicated something that pretty
much existed before.

If you can, I recommend using the intel gtt mapping type of mmap ioctl,
where it gives you back an offset that you use the mmap syscall on, and
implement the vgem_gem_fault to map its pages, instead.  It should avoid
tricking userland tools like valgrind, which really sucks with the
do_mmap()-calling ioctl we have today.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120111/185ec22f/attachment.pgp>