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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
> > 
> > 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@xxxxxxxxxx>
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@xxxxxxxxxx>
---
 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux