Am 13.10.2017 um 16:34 schrieb Michel Dänzer:
On 12/10/17 07:11 PM, Christian König wrote:
Am 12.10.2017 um 18:49 schrieb Michel Dänzer:
On 12/10/17 01:00 PM, Michel Dänzer wrote:
[0] I also got this, but I don't know yet if it's related:
No, that seems to be a separate issue; I can still
On 12/10/17 07:11 PM, Christian König wrote:
> Am 12.10.2017 um 18:49 schrieb Michel Dänzer:
>> On 12/10/17 01:00 PM, Michel Dänzer wrote:
>>> [0] I also got this, but I don't know yet if it's related:
>> No, that seems to be a separate issue; I can still reproduce it with the
>> huge page related
Am 12.10.2017 um 18:49 schrieb Michel Dänzer:
On 12/10/17 01:00 PM, Michel Dänzer wrote:
[0] I also got this, but I don't know yet if it's related:
No, that seems to be a separate issue; I can still reproduce it with the
huge page related changes reverted. Unfortunately, it doesn't seem to
On 12/10/17 01:00 PM, Michel Dänzer wrote:
>
> [0] I also got this, but I don't know yet if it's related:
No, that seems to be a separate issue; I can still reproduce it with the
huge page related changes reverted. Unfortunately, it doesn't seem to
happen reliably on every piglit run.
Even
On 12/10/17 03:50 PM, Christian König wrote:
> Am 12.10.2017 um 15:42 schrieb Michel Dänzer:
>> On 12/10/17 01:44 PM, Christian König wrote:
>>> Am 12.10.2017 um 13:00 schrieb Michel Dänzer:
>>>
Anyway, unless anyone knows which commits from amd-staging-drm-next are
needed to make
On 12/10/17 01:44 PM, Christian König wrote:
> Am 12.10.2017 um 13:00 schrieb Michel Dänzer:
>
>> Anyway, unless anyone knows which commits from amd-staging-drm-next are
>> needed to make 1d00402b4da2 stable in 4.14, the safe course of action
>> seems to be reverting it (and ac7afe6b3cf3, which
Am 12.10.2017 um 13:00 schrieb Michel Dänzer:
On 12/10/17 10:05 AM, Christian König wrote:
[SNIP]
Is amd-staging-drm-next stable for you?
It seemed stable before the changes you pushed this morning. :) As of
cfb6dee86711 "drm/ttm: add transparent huge page support for cached
allocations v2", I
On 12/10/17 10:05 AM, Christian König wrote:
> Am 11.10.2017 um 18:30 schrieb Michel Dänzer:
>> On 28/09/17 04:55 PM, Nicolai Hähnle wrote:
>>> From: Nicolai Hähnle
>>>
>>> Highly concurrent Piglit runs can trigger a race condition where a
>>> pending
>>> SDMA job on a
Am 11.10.2017 um 18:30 schrieb Michel Dänzer:
On 28/09/17 04:55 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Highly concurrent Piglit runs can trigger a race condition where a pending
SDMA job on a buffer object is never executed because the corresponding
process is
On 28/09/17 04:55 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Highly concurrent Piglit runs can trigger a race condition where a pending
> SDMA job on a buffer object is never executed because the corresponding
> process is killed (perhaps due to a crash). Since
bingley...@amd.com>
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining fences in
amd_sched_entity_fini
Am 09.10.2017 um 13:27 schrieb Nicolai Hähnle:
> On 09.10.2017 13:12, Christian König wrote:
>>>
>>>> Nicolai, how hard would it be to handle ENODE
;
amd-gfx@lists.freedesktop.org; Olsak, Marek
Cc: Li, Bingley
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining fences in
amd_sched_entity_fini
On 09.10.2017 14:33, Christian König wrote:
> Am 09.10.2017 um 13:27 schrieb Nicolai Hähnle:
>> On 09.10.2017 13:12, Christian König wrote:
>
talking about community rules we shouldn't let MESA
handle -ECANCELED , we should have a unified error code
+ Marek
BR Monk
-Original Message-
From: Haehnle, Nicolai
Sent: 2017年10月9日 18:14
To: Koenig, Christian <christian.koe...@amd.com>; Liu, Monk
<monk@amd.com>; Ni
Sent: 2017年10月9日 18:14
To: Koenig, Christian <christian.koe...@amd.com>; Liu, Monk
<monk@amd.com>; Nicolai Hähnle <nhaeh...@gmail.com>;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining
fences in amd_sched_entity_fini
On 09.10.2017 10:
have a unified error code
+ Marek
BR Monk
-Original Message-
From: Haehnle, Nicolai
Sent: 2017年10月9日 18:14
To: Koenig, Christian <christian.koe...@amd.com>; Liu, Monk
<monk....@amd.com>; Nicolai Hähnle <nhaeh...@gmail.com>;
amd-gfx@lists.freedesktop.org
Subject: Re:
gfx-boun...@lists.freedesktop.org] On
Behalf Of Christian K?nig
Sent: 2017年9月28日 23:01
To: Nicolai Hähnle <nhaeh...@gmail.com>;
amd-gfx@lists.freedesktop.org
Cc: Haehnle, Nicolai <nicolai.haeh...@amd.com>
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining
fences in amd_sch
g] On
Behalf Of Christian K?nig
Sent: 2017年9月28日 23:01
To: Nicolai Hähnle <nhaeh...@gmail.com>;
amd-gfx@lists.freedesktop.org
Cc: Haehnle, Nicolai <nicolai.haeh...@amd.com>
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining
fences in amd_sched_entity_fini
Am 28
Marek
BR Monk
-Original Message-
From: Haehnle, Nicolai
Sent: 2017年10月9日 18:14
To: Koenig, Christian <christian.koe...@amd.com>; Liu, Monk
<monk@amd.com>; Nicolai Hähnle <nhaeh...@gmail.com>;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/5] drm/a
olai
Sent: 2017年10月9日 18:14
To: Koenig, Christian <christian.koe...@amd.com>; Liu, Monk
<monk@amd.com>; Nicolai Hähnle <nhaeh...@gmail.com>;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining
fences in amd_sched_entity_fini
nt: 2017年10月9日 18:14
To: Koenig, Christian <christian.koe...@amd.com>; Liu, Monk <monk@amd.com>;
Nicolai Hähnle <nhaeh...@gmail.com>; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining fences in
amd_sched_entity_fini
On 09.10.2017 10:02,
s no gpu hang hit
>>
>>
>> BR Monk
>>
>>
>>
>>
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
>> Behalf Of Christian K?nig
>> Sent: 2017年9月28日 23:01
>> To: Nicolai Hähnle &l
; amd-gfx@lists.freedesktop.org
Cc: Haehnle, Nicolai <nicolai.haeh...@amd.com>
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining
fences in amd_sched_entity_fini
Am 28.09.2017 um 16:55 schrieb Nicolai Hähnle:
From: Nicolai Hähnle <nicolai.haeh...@amd.com>
Highly concurrent Piglit ru
nle <nhaeh...@gmail.com>; amd-gfx@lists.freedesktop.org
Cc: Haehnle, Nicolai <nicolai.haeh...@amd.com>
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and free remaining fences in
amd_sched_entity_fini
Am 28.09.2017 um 16:55 schrieb Nicolai Hähnle:
From: Nicolai Hähnle <nicolai.haeh..
: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: 2017年9月28日 23:01
To: Nicolai Hähnle <nhaeh...@gmail.com>; amd-gfx@lists.freedesktop.org
Cc: Haehnle, Nicolai <nicolai.haeh...@amd.com>
Subject: Re: [PATCH 5/5] drm/amd/sched: signal and
Hi Nicolai,
Ping? :-)
Tom
On 28/09/17 11:01 AM, Christian König wrote:
Am 28.09.2017 um 16:55 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Highly concurrent Piglit runs can trigger a race condition where a
pending
SDMA job on a buffer object is never executed
On 2017年09月28日 22:55, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Highly concurrent Piglit runs can trigger a race condition where a pending
SDMA job on a buffer object is never executed because the corresponding
process is killed (perhaps due to a crash). Since the
Thanks for this series. I can finally finish piglit on VI.
Marek
On Thu, Sep 28, 2017 at 4:55 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Highly concurrent Piglit runs can trigger a race condition where a pending
> SDMA job on a buffer
Am 28.09.2017 um 16:55 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Highly concurrent Piglit runs can trigger a race condition where a pending
SDMA job on a buffer object is never executed because the corresponding
process is killed (perhaps due to a crash). Since the
From: Nicolai Hähnle
Highly concurrent Piglit runs can trigger a race condition where a pending
SDMA job on a buffer object is never executed because the corresponding
process is killed (perhaps due to a crash). Since the job's fences were
never signaled, the buffer
29 matches
Mail list logo