[RFC PATCH] drm/vgem: virtual GEM provider
eric at anholt.net
Wed Jan 11 12:16:08 PST 2012
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
Size: 197 bytes
Desc: not available
More information about the dri-devel