On Wed, Jan 11, 2012 at 8:32 PM, Daniel Vetter daniel@ffwll.ch 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@redhat.com
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.