[PATCH] drm/vgem: drop DRIVER_PRIME

[PATCH] drm/vgem: drop DRIVER_PRIME

[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:

  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).

Signed-off-by: Rob Clark <robdclark@gmail.com>
---
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(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index cb3b435..b0316f9 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -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,
-- 
2.4.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vgem: drop DRIVER_PRIME

[Thomas Hellstrom]

Hi, Rob!

On 05/21/2015 04:53 PM, Rob Clark wrote:
> 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:
>
>   https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DMay_083160.html&d=AwIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=hZDsGjgypZF71rQfORpnkvT34UoNymdOdW0M3RyIIpQ&s=6QpYr_rF5y3fBjm48gY5zTJp6Fu87bv2HJYGGJ7VX7s&e= 
>
> 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


>
> Signed-off-by: Rob Clark <robdclark@gmail.com>
> ---
> 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(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index cb3b435..b0316f9 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -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
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vgem: drop DRIVER_PRIME

[Rob Clark]

On Thu, May 21, 2015 at 11:03 AM, Thomas Hellstrom
<thellstrom@vmware.com> wrote:
> Hi, Rob!
>
> On 05/21/2015 04:53 PM, Rob Clark wrote:
>> 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:
>>
>>   https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DMay_083160.html&d=AwIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=hZDsGjgypZF71rQfORpnkvT34UoNymdOdW0M3RyIIpQ&s=6QpYr_rF5y3fBjm48gY5zTJp6Fu87bv2HJYGGJ7VX7s&e=
>>
>> 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.

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

> /Thomas
>
>
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>> ---
>> 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(-)
>>
>> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
>> index cb3b435..b0316f9 100644
>> --- a/drivers/gpu/drm/vgem/vgem_drv.c
>> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>> @@ -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
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vgem: drop DRIVER_PRIME

[Daniel Vetter]

On Thu, May 21, 2015 at 05:03:58PM +0200, Thomas Hellstrom wrote:
> Hi, Rob!
> 
> On 05/21/2015 04:53 PM, Rob Clark wrote:
> > 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:
> >
> >   https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DMay_083160.html&d=AwIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=hZDsGjgypZF71rQfORpnkvT34UoNymdOdW0M3RyIIpQ&s=6QpYr_rF5y3fBjm48gY5zTJp6Fu87bv2HJYGGJ7VX7s&e= 
> >
> > 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.

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel