Couldn't reproduce the issue so far. So the attached patch is just a
complete shoot into the dark found by rereading the code, but it might
actually be the problem.
Please give it a try.
Going to keep testing in the meantime,
Christian.
Am 10.05.2014 10:23, schrieb Christian König:
I see hangs with kernel 3.15 and SI under memory pressure, e.g. if I
boot with radeon.vramlimit=256 and then run Xonotic timedemo with
high settings. I haven't had a chance to bisect it yet, but it might
be a similar problem.
Sounds like the same issue to me. Thx for the good test case.
Any idea what is wrong with it?
Actually I already wondered that it went so smooth without any
regression so far, didn't noticed the bug in bugzilla.kernel.org yet.
Some of the tests allocate a lot of MSAA textures and the tests also
run in parallel, which creates a lot of memory pressure and probably
causes buffer evictions.
Sounds like the underlying problem to me. We probably evict some part
of a page table without updating the page directory. Going to dig into
it today, it's probably just a one liner missing somewhere in the VM
code.
Christian.
Am 09.05.2014 23:39, schrieb Grigori Goronzy:
On 09.05.2014 20:03, Marek Olšák wrote:
This commit which first appeared in 3.15-rc1 causes hangs on Bonaire:
[...]
The simplest way to reproduce the hangs is to run piglit with these
parameters:
-t texelFetch.fs
Some of the tests allocate a lot of MSAA textures and the tests also
run in parallel, which creates a lot of memory pressure and probably
causes buffer evictions.
I see hangs with kernel 3.15 and SI under memory pressure, e.g. if I
boot with radeon.vramlimit=256 and then run Xonotic timedemo with
high settings. I haven't had a chance to bisect it yet, but it might
be a similar problem.
Grigori
>From 93a89ae1bdf359a4261ae0120ba893039a6f05be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@xxxxxxx>
Date: Sat, 10 May 2014 18:17:09 +0200
Subject: [PATCH] drm/radeon: fix buffer placement under memory pressure
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Some buffers (UVD/VM page tables) must be placed in VRAM,
but the byte restriction for moving buffers didn't took this
into account.
This patch not only fixed that bug, but also improves
the situation when we run out of GART space.
Signed-off-by: Christian König <christian.koenig@xxxxxxx>
---
drivers/gpu/drm/radeon/radeon_object.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index 72705fb..92ff6be 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -447,8 +447,6 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
bo = lobj->robj;
if (!bo->pin_count) {
u32 domain = lobj->domain;
- u32 current_domain =
- radeon_mem_type_to_domain(bo->tbo.mem.mem_type);
/* Check if this buffer will be moved and don't move it
* if we have moved too many buffers for this IB already.
@@ -458,11 +456,10 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
* into account. We don't want to disallow buffer moves
* completely.
*/
- if (current_domain != RADEON_GEM_DOMAIN_CPU &&
- (domain & current_domain) == 0 && /* will be moved */
- bytes_moved > bytes_moved_threshold) {
- /* don't move it */
- domain = current_domain;
+ if (bytes_moved > bytes_moved_threshold) {
+ /* if we already moved to many bytes accept
+ the alternative domain as well */
+ domain = lobj->alt_domain;
}
retry:
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
