[PATCH] drm/radeon/bo: add some fallback placements for VRAM only objects. (v2)

Michel Dänzer michel at daenzer.net
Wed Apr 28 05:11:28 PDT 2010


On Die, 2010-04-27 at 10:31 +0200, Michel Dänzer wrote: 
> On Die, 2010-04-27 at 12:34 +1000, Dave Airlie wrote: 
> > From: Dave Airlie <airlied at redhat.com>
> > 
> > On constrained r100 systems compiz would fail to start due to a lack
> > of memory, we can just fallback place the objects rather than completely
> > failing it works a lot better.
> > 
> > v2:
> > fixes issue identified by Michel when pinning could happen in a busy placement domain.
> 
> [...]
> 
> How about something like the below (completely untested) instead? This
> should try to respect the userspace request first and only allow falling
> back from VRAM to GTT if that failed. (Maybe the new bool parameter
> shouldn't be called 'pinned' then but something like
> 'allow_vram_fallback' and its sense inverted)

The alternative patch below is tested to not regress for me, but of
course I'm not affected by the failure to put things in VRAM. Uwe /
'Chicken Shack', does this fix your problem with compiz?

This doesn't cover radeon_bo_fault_reserve_notify() because my tree
doesn't have the invisible VRAM stuff yet, but it'll be easy to extend
this approach to there as well, and it shouldn't affect the immediate
problem we're trying to solve.


From c3009dd4df63a65fd15a485265fbdabfb1360c97 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <daenzer at vmware.com>
Date: Wed, 28 Apr 2010 09:24:38 +0200
Subject: [PATCH] drm/radeon/kms: Fall back to GTT if BO creation in / validation to VRAM failed.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Michel Dänzer <daenzer at vmware.com>
---
 drivers/gpu/drm/radeon/radeon_object.c |   31 ++++++++++++++++++++-----------
 1 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index d10f246..1dfb056 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -109,16 +109,22 @@ int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj,
 	bo->surface_reg = -1;
 	INIT_LIST_HEAD(&bo->list);
 
+retry:
 	radeon_ttm_placement_from_domain(bo, domain);
 	/* Kernel allocation are uninterruptible */
 	r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
 			&bo->placement, 0, 0, !kernel, NULL, size,
 			&radeon_ttm_bo_destroy);
 	if (unlikely(r != 0)) {
-		if (r != -ERESTARTSYS)
+		if (r != -ERESTARTSYS) {
+			if (domain == RADEON_GEM_DOMAIN_VRAM) {
+				domain |= RADEON_GEM_DOMAIN_GTT;
+				goto retry;
+			}
 			dev_err(rdev->dev,
 				"object_init failed for (%lu, 0x%08X)\n",
 				size, domain);
+		}
 		return r;
 	}
 	*bo_ptr = bo;
@@ -313,6 +319,7 @@ int radeon_bo_list_validate(struct list_head *head)
 {
 	struct radeon_bo_list *lobj;
 	struct radeon_bo *bo;
+	u32 domain;
 	int r;
 
 	r = radeon_bo_list_reserve(head);
@@ -322,17 +329,19 @@ int radeon_bo_list_validate(struct list_head *head)
 	list_for_each_entry(lobj, head, list) {
 		bo = lobj->bo;
 		if (!bo->pin_count) {
-			if (lobj->wdomain) {
-				radeon_ttm_placement_from_domain(bo,
-								lobj->wdomain);
-			} else {
-				radeon_ttm_placement_from_domain(bo,
-								lobj->rdomain);
-			}
-			r = ttm_bo_validate(&bo->tbo, &bo->placement,
-						true, false);
-			if (unlikely(r))
+			domain = lobj->wdomain ? lobj->wdomain : lobj->rdomain;
+
+retry:
+			radeon_ttm_placement_from_domain(bo, domain);
+			r = ttm_bo_validate(&bo->tbo, &bo->placement, true, false);
+			if (unlikely(r)) {
+				if (r != -ERESTARTSYS &&
+				    domain == RADEON_GEM_DOMAIN_VRAM) {
+					domain |= RADEON_GEM_DOMAIN_GTT;
+					goto retry;
+				}
 				return r;
+			}
 		}
 		lobj->gpu_offset = radeon_bo_gpu_offset(bo);
 		lobj->tiling_flags = bo->tiling_flags;
-- 
1.7.0.5



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


More information about the dri-devel mailing list