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