On Wed, Jan 11, 2012 at 8:32 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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. Not anymore, it just got moved :-) I'm with Eric implement the mmap the other way, they ioctls look very like the dumb ioctls, maybe just use them if they are. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
