drm/vgem: drop DRIVER_PRIME
Subsystems (2)
PATCH 1/1 drm/vgem: drop DRIVER_PRIME
For actual sharing of buffers with other drivers (ie. actual hardware) we'll need to pimp things out a bit better to deal w/ caching, multiple memory domains, etc. See thread:
http://lists.freedesktop.org/archives/dri-devel/2015-May/083160.html
But for the llvmpipe use-case this isn't a problem. Nor do we really need prime/dri3 (dri2 is sufficient). So until the other issues are sorted lets remove DRIVER_PRIME.
NOTE this ends up leaving some basically dead code for prime import/ export (mostly because I was rushing to send this before a meeting).
---
This is an alternative to removing vgem completely for 4.1, so that llvmpipe work can get started in parallel with sorting out the other issues for sw + hw access..
drivers/gpu/drm/vgem/vgem_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/vgem/vgem_drv.c +1 -1
@@ -302,7 +302,7 @@ static const struct file_operations vgem_driver_fops = { };static struct drm_driver vgem_driver = { - .driver_features =DRIVER_GEM |DRIVER_PRIME , + .driver_features =DRIVER_GEM , .gem_free_object = vgem_gem_free_object, .gem_vm_ops = &vgem_gem_vm_ops, .ioctls = vgem_ioctls,
Signature · 6 lines
2.4.1 _______________________________________________ dri-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi, Rob!
Quoted 4 lines · Rob Clark
For actual sharing of buffers with other drivers (ie. actual hardware) we'll need to pimp things out a bit better to deal w/ caching, multiple memory domains, etc. See thread:
Quoted 8 lines
But for the llvmpipe use-case this isn't a problem. Nor do we really need prime/dri3 (dri2 is sufficient). So until the other issues are sorted lets remove
DRIVER_PRIME.NOTE this ends up leaving some basically dead code for prime import/ export (mostly because I was rushing to send this before a meeting).
What worries me a little is what Daniel brought up in his commit message, that let's say in the end people add a reasonable interface to dma_buf mmap, vgem also needs a corresponding interface... Makes me think that the best solution for now
is perhaps to revert it.
/Thomas
Quoted 15 lines
Signed-off-by Rob Clark <[email protected]>---
This is an alternative to removing vgem completely for 4.1, so that llvmpipe work can get started in parallel with sorting out the other issues for sw + hw access..drivers/gpu/drm/vgem/vgem_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/gpu/drm/vgem/vgem_drv.c +0
-0
drivers/gpu/drm/vgem/vgem_drv.c static const struct file_operations vgem_driver_fops = { · line 308
Quoted 8 lines
drivers/gpu/drm/vgem/vgem_drv.c +1
-1@@ -302,7 +302,7 @@ static const struct file_operations vgem_driver_fops = { };static struct drm_driver vgem_driver = { - .driver_features =DRIVER_GEM |DRIVER_PRIME , + .driver_features =DRIVER_GEM , .gem_free_object = vgem_gem_free_object, .gem_vm_ops = &vgem_gem_vm_ops, .ioctls = vgem_ioctls,
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoted 13 lines · Thomas Hellstrom
Hi, Rob!
Quoted 10 lines · Rob Clark
For actual sharing of buffers with other drivers (ie. actual hardware) we'll need to pimp things out a bit better to deal w/ caching, multiple memory domains, etc. See thread:
But for the llvmpipe use-case this isn't a problem. Nor do we really need prime/dri3 (dri2 is sufficient). So until the other issues are sorted lets remove
DRIVER_PRIME.
Quoted 8 lines
Quoted 2 lines
NOTE this ends up leaving some basically dead code for prime import/ export (mostly because I was rushing to send this before a meeting).
What worries me a little is what Daniel brought up in his commit message, that let's say in the end people add a reasonable interface to
dma_bufmmap, vgem also needs a corresponding interface... Makes me think that the best solution for now
is perhaps to revert it.
Yeah if we just drop the prime parts vgem is pretty much only for llvmpipe and other software renderers. And if we add prime it'd be purely self-import only which rejects any foreign access and reject any foreign objects. At least I haven't understood yet why we need to import the dma-bufs first when we could just directly mmap the passed-in fd ...
Anyway I think removing the dead code makes sense - we can easily resurrect it with git again. Also the current prime code for vgem doesn't handle self-imports correctly, so isnt' even really useable for llvmpipe-on-vgem as-is.
-Daniel
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoted 13 lines · Thomas Hellstrom
Hi, Rob!
Quoted 10 lines · Rob Clark
For actual sharing of buffers with other drivers (ie. actual hardware) we'll need to pimp things out a bit better to deal w/ caching, multiple memory domains, etc. See thread:
But for the llvmpipe use-case this isn't a problem. Nor do we really need prime/dri3 (dri2 is sufficient). So until the other issues are sorted lets remove
DRIVER_PRIME.
Quoted 8 lines
Quoted 2 lines
NOTE this ends up leaving some basically dead code for prime import/ export (mostly because I was rushing to send this before a meeting).
What worries me a little is what Daniel brought up in his commit message, that let's say in the end people add a reasonable interface to
dma_bufmmap, vgem also needs a corresponding interface... Makes me think that the best solution for now
is perhaps to revert it.
Well, I think that is solvable.. ie. when vgem regains PRIME support, disallow mmap'ing of imported buffers (and disallow export?), and do all cpu-prep/fini stuff via dmabuf handle, for example.
Without prime, vgem is at least for now useful for allocating a dumb buffer and sharing it between X and client (for llvmpipe rendering).
BR,
-R
Quoted 20 lines
/Thomas
Quoted 17 lines
Signed-off-by Rob Clark <[email protected]>---
This is an alternative to removing vgem completely for 4.1, so that llvmpipe work can get started in parallel with sorting out the other issues for sw + hw access..drivers/gpu/drm/vgem/vgem_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/gpu/drm/vgem/vgem_drv.c +0
-0@@ -302,7 +302,7 @@ static const struct file_operations vgem_driver_fops = { };
Quoted 7 lines
drivers/gpu/drm/vgem/vgem_drv.c static const struct file_operations vgem_driver_fops = { · line 308
Quoted 6 lines
drivers/gpu/drm/vgem/vgem_drv.c +1
-1static struct drm_driver vgem_driver = { - .driver_features =DRIVER_GEM |DRIVER_PRIME , + .driver_features =DRIVER_GEM , .gem_free_object = vgem_gem_free_object, .gem_vm_ops = &vgem_gem_vm_ops, .ioctls = vgem_ioctls,
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel