On Wed, 11 Jan 2012 14:19:21 -0500, Adam Jackson <ajax@xxxxxxxxxx> 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.
Attachment:
pgpAapojJCcfQ.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
