[RFC PATCH] drm/vgem: virtual GEM provider

[Ben Widawsky]

On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
> On Wed, 2012-01-11 at 12:16 -0800, Eric Anholt wrote:
> 
> > 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.
> 
> There's no way to pass an fd without passing an extra byte of in-stream
> data, and it's weirdly invasive to try to thread that into the existing
> protocol.  Sort of the same way getting socket peer credentials with
> recvmsg(SCM_CREDENTIALS) sucks, which is why we have
> getsockopt(SO_PEERCRED) instead.  But unlike process credentials,
> SCM_RIGHTS is a queue, which is a funny kind of API to bolt into
> setsockopt.
> 
> Making something that looked like a hardware driver seemed way more
> symmetric.  And, in the long-range future of being able to pass GEM
> objects among DRM devices, you'll probably want to apply any constraints
> like tiling round-up at object creation time.  Doing it the other way
> around - xserver allocates with shm_open() then promotes to GEM - just
> introduces a way userspace can get it wrong.
> 
> > 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.
> 
> That makes sense.  Having two paths by which you could hit
> drm_gem_mmap() seemed weird when I was writing it.
> 
> I think the clean way of doing that requires exporting at least
> shmem_fault and possibly some other shmfs details.
> 
> - ajax

I'm working on this presently unless you've already done it.
~Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120208/2fd9a4d3/attachment.pgp>