dri-devel Archive on 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox