From: Jerome Glisse jglisse@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@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 @@ -368,7 +368,7 @@ 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 @@ -127,26 +127,6 @@ int radeon_gem_object_open(struct drm_gem_object *obj, struct drm_file *file_pri return 0; }
-void radeon_gem_object_close(struct drm_gem_object *obj, - struct drm_file *file_priv) -{ - struct radeon_bo *rbo = gem_to_radeon_bo(obj); - struct radeon_device *rdev = rbo->rdev; - struct radeon_fpriv *fpriv = file_priv->driver_priv; - struct radeon_vm *vm = &fpriv->vm; - - if (rdev->family < CHIP_CAYMAN) { - return; - } - - if (radeon_bo_reserve(rbo, false)) { - dev_err(rdev->dev, "leaking bo va because we fail to reserve bo\n"); - return; - } - radeon_vm_bo_rmv(rdev, vm, rbo); - radeon_bo_unreserve(rbo); -} - static int radeon_gem_handle_lockup(struct radeon_device *rdev, int r) { if (r == -EDEADLK) {
On Wed, Aug 8, 2012 at 10:36 AM, j.glisse@gmail.com wrote:
From: Jerome Glisse jglisse@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@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 @@ -368,7 +368,7 @@ 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 @@ -127,26 +127,6 @@ int radeon_gem_object_open(struct drm_gem_object *obj, struct drm_file *file_pri return 0; }
-void radeon_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv)-{
struct radeon_bo *rbo = gem_to_radeon_bo(obj);struct radeon_device *rdev = rbo->rdev;struct radeon_fpriv *fpriv = file_priv->driver_priv;struct radeon_vm *vm = &fpriv->vm;if (rdev->family < CHIP_CAYMAN) {return;}if (radeon_bo_reserve(rbo, false)) {dev_err(rdev->dev, "leaking bo va because we fail to reserve bo\n");return;}radeon_vm_bo_rmv(rdev, vm, rbo);radeon_bo_unreserve(rbo);-}
static int radeon_gem_handle_lockup(struct radeon_device *rdev, int r) { if (r == -EDEADLK) { -- 1.7.10.4
On Mit, 2012-08-08 at 10:36 -0400, j.glisse@gmail.com wrote:
From: Jerome Glisse jglisse@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.
On Wed, Aug 8, 2012 at 11:19 AM, Michel Dänzer michel@daenzer.net wrote:
On Mit, 2012-08-08 at 10:36 -0400, j.glisse@gmail.com wrote:
From: Jerome Glisse jglisse@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
dri-devel@lists.freedesktop.org
-
j.glisse＠gmail.com -
Jerome Glisse
-
Michel Dänzer