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 --- drivers/gpu/drm/Kconfig | 8 ++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/vgem/Makefile | 4 + drivers/gpu/drm/vgem/vgem_drv.c | 262 +++++++++++++++++++++++++++++++++++++++ include/drm/vgem_drm.h | 51 ++++++++ 5 files changed, 326 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/vgem/Makefile create mode 100644 drivers/gpu/drm/vgem/vgem_drv.c create mode 100644 include/drm/vgem_drm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 1368826..46322ba 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -159,6 +159,14 @@ config DRM_SAVAGE Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister chipset. If M is selected the module will be called savage.
+config DRM_VGEM + tristate "Virtual GEM provider" + depends on DRM + help + Choose this option to get a virtual graphics memory manager, + as used by Mesa's software renderer for enhanced performance. + If M is selected the module will be called vgem. + source "drivers/gpu/drm/exynos/Kconfig"
source "drivers/gpu/drm/vmwgfx/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index c0496f6..132de0e 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_DRM_SIS) += sis/ obj-$(CONFIG_DRM_SAVAGE)+= savage/ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ obj-$(CONFIG_DRM_VIA) +=via/ +obj-$(CONFIG_DRM_VGEM) += vgem/ obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ obj-y += i2c/ diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile new file mode 100644 index 0000000..3f4c7b8 --- /dev/null +++ b/drivers/gpu/drm/vgem/Makefile @@ -0,0 +1,4 @@ +ccflags-y := -Iinclude/drm +vgem-y := vgem_drv.o + +obj-$(CONFIG_DRM_VGEM) += vgem.o diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c new file mode 100644 index 0000000..82c6787 --- /dev/null +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -0,0 +1,262 @@ +/* + * Copyright 2011 Red Hat, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software") + * to deal in the software without restriction, including without limitation + * on the rights to use, copy, modify, merge, publish, distribute, sub + * license, and/or sell copies of the Software, and to permit persons to whom + * them Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTIBILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER + * IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: + * Adam Jackson ajax@redhat.com + */ + +/** + * This is vgem, a (non-hardware-backed) GEM service. This is used by Mesa's + * software renderer and the X server for efficient buffer sharing. + */ + +#include "drmP.h" +#include "drm.h" +#include "vgem_drm.h" +#include <linux/module.h> +#include <linux/ramfs.h> + +#define DRIVER_NAME "vgem" +#define DRIVER_DESC "Virtual GEM provider" +#define DRIVER_DATE "20120112" +#define DRIVER_MAJOR 1 +#define DRIVER_MINOR 0 + +static int vgem_load(struct drm_device *dev, unsigned long flags) +{ + return 0; +} + +static int vgem_unload(struct drm_device *dev) +{ + return 0; +} + +static void vgem_preclose(struct drm_device *dev, struct drm_file *file) +{ +} + +static void vgem_lastclose(struct drm_device *dev) +{ +} + +static int vgem_gem_init_object(struct drm_gem_object *obj) +{ + return 0; +} + +static void vgem_gem_free_object(struct drm_gem_object *obj) +{ + if (obj->map_list.map) + drm_gem_free_mmap_offset(obj); + + drm_gem_object_release(obj); +} + +/* XXX I don't think this is ever hit */ +static int vgem_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf) +{ + BUG(); +} + +static struct vm_operations_struct vgem_gem_vm_ops = { + .fault = vgem_gem_fault, + .open = drm_gem_vm_open, + .close = drm_gem_vm_close, +}; + +/* ioctls */ + +static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, + struct drm_file *file, + unsigned int *handle, + unsigned long size) +{ + int err; + struct drm_gem_object *gem_object; + + size = roundup(size, PAGE_SIZE); + + gem_object = kzalloc(sizeof(*gem_object), GFP_KERNEL); + if (!gem_object) + return ERR_PTR(-ENOMEM); + + if ((err = drm_gem_object_init(dev, gem_object, size))) + goto out; + + if ((err = drm_gem_create_mmap_offset(gem_object))) + goto mmap_out; + + if ((err = drm_gem_handle_create(file, gem_object, handle))) + goto handle_out; + + drm_gem_object_unreference_unlocked(gem_object); + + return gem_object; + +handle_out: + drm_gem_free_mmap_offset(gem_object); + +mmap_out: + drm_gem_object_release(gem_object); + +out: + kfree(gem_object); + + return ERR_PTR(err); +} + +static int vgem_gem_create_ioctl(struct drm_device *dev, void *data, + struct drm_file *file) +{ + struct vgem_gem_create *args = data; + struct drm_gem_object *gem_object; + + gem_object = vgem_gem_create(dev, file, &args->handle, args->size); + + if (IS_ERR(gem_object)) + return PTR_ERR(gem_object); + + return 0; +} + +static int vgem_gem_mmap_ioctl(struct drm_device *dev, void *data, + struct drm_file *file) +{ + struct vgem_gem_mmap *args = data; + struct drm_gem_object *obj; + uintptr_t addr; + + obj = drm_gem_object_lookup(dev, file, args->handle); + if (!obj) + return -ENOENT; + + obj->filp->private_data = obj; + + down_write(¤t->mm->mmap_sem); + addr = do_mmap(obj->filp, 0, args->size, PROT_READ | PROT_WRITE, + MAP_SHARED, 0); + up_write(¤t->mm->mmap_sem); + + drm_gem_object_unreference_unlocked(obj); + + if (IS_ERR((void *)addr)) + return PTR_ERR((void *)addr); + + args->mapped = addr; + + return 0; +} + +static struct drm_ioctl_desc vgem_ioctls[] = { + DRM_IOCTL_DEF_DRV(VGEM_GEM_CREATE, vgem_gem_create_ioctl, + DRM_UNLOCKED | DRM_AUTH), + DRM_IOCTL_DEF_DRV(VGEM_GEM_MMAP, vgem_gem_mmap_ioctl, + DRM_UNLOCKED | DRM_AUTH), +}; + +static struct drm_driver vgem_driver = { + .driver_features = DRIVER_BUS_PLATFORM | DRIVER_GEM, + .load = vgem_load, + .unload = vgem_unload, + .preclose = vgem_preclose, + .lastclose = vgem_lastclose, + .gem_init_object = vgem_gem_init_object, + .gem_free_object = vgem_gem_free_object, + .gem_vm_ops = &vgem_gem_vm_ops, + .ioctls = vgem_ioctls, + .fops = { + .owner = THIS_MODULE, + .open = drm_open, + .mmap = drm_gem_mmap, + .poll = drm_poll, + .read = drm_read, + .unlocked_ioctl = drm_ioctl, + .release = drm_release, + }, + .name = DRIVER_NAME, + .desc = DRIVER_DESC, + .date = DRIVER_DATE, + .major = DRIVER_MAJOR, + .minor = DRIVER_MINOR, +}; + +static int vgem_platform_probe(struct platform_device *pdev) +{ + vgem_driver.num_ioctls = DRM_ARRAY_SIZE(vgem_ioctls); + + return drm_platform_init(&vgem_driver, pdev); +} + +static int vgem_platform_remove(struct platform_device *pdev) +{ + drm_platform_exit(&vgem_driver, pdev); + + return 0; +} + +static struct platform_driver vgem_platform_driver = { + .probe = vgem_platform_probe, + .remove = __devexit_p(vgem_platform_remove), + .driver = { + .owner = THIS_MODULE, + .name = DRIVER_NAME, + }, +}; + +static struct platform_device *vgem_device; + +static int __init vgem_init(void) +{ + int ret; + + if ((ret = platform_driver_register(&vgem_platform_driver))) + return ret; + + vgem_device = platform_device_alloc("vgem", -1); + if (!vgem_device) { + ret = -ENOMEM; + goto out; + } + + ret = platform_device_add(vgem_device); + if (!ret) + return 0; + +out: + platform_device_put(vgem_device); + platform_driver_unregister(&vgem_platform_driver); + + return ret; +} + +static void __exit vgem_exit(void) +{ + platform_device_unregister(vgem_device); + platform_driver_unregister(&vgem_platform_driver); +} + +module_init(vgem_init); +module_exit(vgem_exit); + +MODULE_AUTHOR("Red Hat, Inc."); +MODULE_DESCRIPTION(DRIVER_DESC); +MODULE_LICENSE("GPL and additional rights"); diff --git a/include/drm/vgem_drm.h b/include/drm/vgem_drm.h new file mode 100644 index 0000000..d73b537 --- /dev/null +++ b/include/drm/vgem_drm.h @@ -0,0 +1,51 @@ +/* + * Copyright 2011 Red Hat, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software") + * to deal in the software without restriction, including without limitation + * on the rights to use, copy, modify, merge, publish, distribute, sub + * license, and/or sell copies of the Software, and to permit persons to whom + * them Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTIBILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER + * IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + */ + +#ifndef VGEM_DRM_H +#define VGEM_DRM_H + +/* Bare API largely ripped off from exynos driver */ + +struct vgem_gem_create { + unsigned int size; + unsigned int flags; + unsigned int handle; +}; + +struct vgem_gem_mmap { + unsigned int handle; + unsigned int size; + uint64_t mapped; +}; + +#define DRM_VGEM_GEM_CREATE 0x00 +#define DRM_VGEM_GEM_MMAP 0x01 + +#define DRM_IOCTL_VGEM_GEM_CREATE \ + DRM_IOWR(DRM_COMMAND_BASE + DRM_VGEM_GEM_CREATE, \ + struct vgem_gem_create) + +#define DRM_IOCTL_VGEM_GEM_MMAP \ + DRM_IOWR(DRM_COMMAND_BASE + DRM_VGEM_GEM_MMAP, \ + struct vgem_gem_mmap) + +#endif
On Wed, 11 Jan 2012 14:19:21 -0500, Adam Jackson ajax@redhat.com 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.
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.
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.
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
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
On 2/7/12 6:28 PM, Ben Widawsky wrote:
On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
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.
Go for it, I've been ratholed getting vesa working again on 1.12.
- ajax
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.
Otherwise I couldn't find anything to complain about ;-)
Cheers, Daniel
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.
dri-devel@lists.freedesktop.org
-
Adam Jackson -
Ben Widawsky -
Daniel Vetter -
Dave Airlie -
Eric Anholt