Direct rendering infrastructure (DRI) is a means of safely accessing graphics hardware in X

j.glisse | 8 Aug 2012 16:36

[PATCH] drm/radeon: delay virtual address destruction to bo destruction

From: Jerome Glisse <jglisse <at> redhat.com>

Use the ttm bo delayed destruction queue so that we don't block
userspace when destroying bo. The virtual address destruction
will happen at same time as the real bo destruction when everythings
using the bo is done.

Signed-off-by: Jerome Glisse <jglisse <at> redhat.com>
---
 drivers/gpu/drm/radeon/radeon_drv.c |    2 +-
 drivers/gpu/drm/radeon/radeon_gem.c |   20 --------------------
 2 files changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
index dcea6f0..38443e7 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
 <at>  <at>  -368,7 +368,7  <at>  <at>  static struct drm_driver kms_driver = {
 	.gem_init_object = radeon_gem_object_init,
 	.gem_free_object = radeon_gem_object_free,
 	.gem_open_object = radeon_gem_object_open,
-	.gem_close_object = radeon_gem_object_close,
+	.gem_close_object = NULL,
 	.dma_ioctl = radeon_dma_ioctl_kms,
 	.dumb_create = radeon_mode_dumb_create,
 	.dumb_map_offset = radeon_mode_dumb_mmap,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
index 1b57b00..b5835c8 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c

(Continue reading)

headers

Jerome Glisse | 8 Aug 2012 16:13

Re: [PATCH] drm/radeon: delay virtual address destruction to bo destruction

On Wed, Aug 8, 2012 at 10:36 AM,  <j.glisse <at> gmail.com> wrote:
> From: Jerome Glisse <jglisse <at> redhat.com>
>
> Use the ttm bo delayed destruction queue so that we don't block
> userspace when destroying bo. The virtual address destruction
> will happen at same time as the real bo destruction when everythings
> using the bo is done.

Haven't had time to test this extensively. Probably won't have time to
seriously test this before next week. This is mostly an optimization
to avoid stalling userspace when destroying bo.

Cheers,
Jerome

>
> Signed-off-by: Jerome Glisse <jglisse <at> redhat.com>
> ---
>  drivers/gpu/drm/radeon/radeon_drv.c |    2 +-
>  drivers/gpu/drm/radeon/radeon_gem.c |   20 --------------------
>  2 files changed, 1 insertion(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
> index dcea6f0..38443e7 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>  <at>  <at>  -368,7 +368,7  <at>  <at>  static struct drm_driver kms_driver = {
>         .gem_init_object = radeon_gem_object_init,
>         .gem_free_object = radeon_gem_object_free,
>         .gem_open_object = radeon_gem_object_open,

(Continue reading)

headers

Michel Dänzer | 8 Aug 2012 17:19

Re: [PATCH] drm/radeon: delay virtual address destruction to bo destruction

On Mit, 2012-08-08 at 10:36 -0400, j.glisse <at> gmail.com wrote: 
> From: Jerome Glisse <jglisse <at> redhat.com>
> 
> Use the ttm bo delayed destruction queue so that we don't block
> userspace when destroying bo. The virtual address destruction
> will happen at same time as the real bo destruction when everythings
> using the bo is done.

I'm on the fence about whether it's better to block or not here. If we
don't, userspace will still need to defer at least the virtual address
space deallocation. It might be easier (and less prone to subtle bugs)
to just defer the BO destruction in userspace to avoid blocking here.

--

-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer

headers

Jerome Glisse | 8 Aug 2012 17:28

Re: [PATCH] drm/radeon: delay virtual address destruction to bo destruction

On Wed, Aug 8, 2012 at 11:19 AM, Michel Dänzer <michel <at> daenzer.net> wrote:
> On Mit, 2012-08-08 at 10:36 -0400, j.glisse <at> gmail.com wrote:
>> From: Jerome Glisse <jglisse <at> redhat.com>
>>
>> Use the ttm bo delayed destruction queue so that we don't block
>> userspace when destroying bo. The virtual address destruction
>> will happen at same time as the real bo destruction when everythings
>> using the bo is done.
>
> I'm on the fence about whether it's better to block or not here. If we
> don't, userspace will still need to defer at least the virtual address
> space deallocation. It might be easier (and less prone to subtle bugs)
> to just defer the BO destruction in userspace to avoid blocking here.
>

Doesn't mean user space should not do thing properly like using pool
of bo or sub allocation. User space might get the wrong impression
with that patch. Anyway just proposing it as it might be usefull in
some case to not force user space to wait on bo idle when destroying
bo.

Cheers,
Jerome