[RFC PATCH] drm/vgem: virtual GEM provider
ajax at redhat.com
Wed Jan 11 13:04:20 PST 2012
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the dri-devel