All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <deathsimple@vodafone.de>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: CIK hangs with kernel 3.15, bisected
Date: Mon, 12 May 2014 14:50:51 +0200	[thread overview]
Message-ID: <5370C3AB.1080903@vodafone.de> (raw)
In-Reply-To: <536F3D93.6050604@vodafone.de>

[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]

I could reproduce the problem with xonotic and I think I've found the issue.

Please test the attached patch.

Thanks,
Christian.

Am 11.05.2014 11:06, schrieb Christian König:
>> I have tested it and it doesn't fix the hangs.
> Yeah, thought so. Well it was just a guess.
>
>> (Also, I don't like the patch, because it reverts the behavior I added
>> for userspace buffers.)
> Actually it shouldn't affect that. The alternative domain always 
> contains GART even when userspace only specified VRAM as placement (as 
> long as it is technical possible to do so).
>
> So what should happen is that TTM sees the current placement, matches 
> that with the desired placement and should find that it doesn't need 
> to move the buffer (we should just test if this behavior really works 
> as expected).
>
> Christian.
>
> Am 10.05.2014 23:38, schrieb Marek Olšák:
>> Hi Christian,
>>
>> I have tested it and it doesn't fix the hangs.
>>
>> (Also, I don't like the patch, because it reverts the behavior I added
>> for userspace buffers.)
>>
>> Marek
>>
>>
>>
>> On Sat, May 10, 2014 at 6:34 PM, Christian König
>> <deathsimple@vodafone.de> wrote:
>>> 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
>>>>
>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-drm-radeon-fix-page-directory-update-size-estimation.patch --]
[-- Type: text/x-diff; name="0001-drm-radeon-fix-page-directory-update-size-estimation.patch", Size: 1017 bytes --]

>From a81682b06f702ea35ccc7fdc176c3f8db6cff138 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Mon, 12 May 2014 14:46:11 +0200
Subject: [PATCH] drm/radeon: fix page directory update size estimation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Take padding into account as well.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/radeon_vm.c
index 2aae6ce..d9ab99f 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -595,7 +595,7 @@ int radeon_vm_update_page_directory(struct radeon_device *rdev,
 	ndw = 64;
 
 	/* assume the worst case */
-	ndw += vm->max_pde_used * 12;
+	ndw += vm->max_pde_used * 16;
 
 	/* update too big for an IB */
 	if (ndw > 0xfffff)
-- 
1.9.1


[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2014-05-12 12:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 18:03 CIK hangs with kernel 3.15, bisected Marek Olšák
2014-05-09 18:10 ` Rafał Miłecki
2014-05-09 21:39 ` Grigori Goronzy
2014-05-10  8:23   ` Christian König
2014-05-10 16:34     ` Christian König
2014-05-10 21:38       ` Marek Olšák
2014-05-11  9:06         ` Christian König
2014-05-12 12:50           ` Christian König [this message]
2014-05-12 23:38             ` Grigori Goronzy
2014-05-13 13:22               ` Alex Deucher
2014-05-13 13:57                 ` Christian König
2014-05-13 15:19                   ` Marek Olšák
2014-05-13 15:31                     ` Christian König
2014-05-13 16:08                       ` Marek Olšák
2014-05-13 19:50                       ` Marek Olšák
2014-05-13 20:19                         ` Grigori Goronzy
2014-05-13 20:27                           ` Marek Olšák
2014-05-30  0:30                             ` Grigori Goronzy
2014-05-30 11:30                               ` Marek Olšák
2014-05-30 11:46                                 ` Grigori Goronzy
2014-05-30 11:51                                   ` Marek Olšák
2014-05-30 18:01                                   ` Grigori Goronzy
2014-05-13 21:21 ` Marek Olšák
2014-05-14 12:11   ` Christian König
2014-05-27 21:55     ` Marek Olšák
2014-05-28 10:38       ` Christian König
2014-05-29 16:30         ` Christian König
2014-05-29 16:51           ` Marek Olšák
2014-05-29 16:59             ` Christian König
2014-05-29 16:52           ` Alex Deucher
2014-05-30 15:57             ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5370C3AB.1080903@vodafone.de \
    --to=deathsimple@vodafone.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maraeo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.