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@xxxxxxxxxx> 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@xxxxxxxx Mobile: +41 (0)79 365 57 48 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
