[RFC PATCH] drm/vgem: virtual GEM provider

[Dave Airlie]

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