t: Tuesday, January 4, 2022 6:19 PM
To: Chen, JingWen ; Christian König
; Grodzovsky, Andrey
; Deng, Emily ; Liu, Monk
; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org; Chen, Horace ; Chen,
JingWen
Cc: dan...@ffwll.ch
Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset p
.org; amd-...@lists.freedesktop.org
Cc: dan...@ffwll.ch; Liu, Monk ; Chen, Horace
Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection
for SRIOV
Am 22.12.21 um 23:14 schrieb Andrey Grodzovsky:
> Since now flr work is serialized against GPU resets there is no need
> for this.
&g
-Original Message-
From: Daniel Vetter
Sent: Friday, September 3, 2021 12:11 AM
To: Koenig, Christian
Cc: Liu, Monk ; Dave Airlie ; Alex Deucher
; Grodzovsky, Andrey ; Chen,
JingWen ; DRI Development
; amd-...@lists.freedesktop.org
Subject: Re: [diagnostic TDR mode patches] unify our solution
opi
essage-
From: Dave Airlie
Sent: Thursday, September 2, 2021 2:51 AM
To: Alex Deucher
Cc: Liu, Monk ; Daniel Vetter ; Koenig,
Christian ; Grodzovsky, Andrey
; Chen, JingWen ; DRI
Development ; amd-...@lists.freedesktop.org
Subject: Re: [diagnostic TDR mode patches] unify our solution
opini
ange inside AMD
driver please always let us know and review.
Thanks
--
Monk Liu | Cloud-GPU Core team
----------
-Original Message-
From: amd-gfx On Behalf Of Daniel Vetter
Sent: Wednesday, September 1, 2021 4:18 PM
To: Liu, Monk
Cc: Koenig, Christ
From: amd-gfx On Behalf Of Daniel Vetter
Sent: Wednesday, September 1, 2021 4:18 PM
To: Liu, Monk
Cc: Koenig, Christian ; Grodzovsky, Andrey
; Chen, JingWen ; DRI
Development ; amd-...@lists.freedesktop.org
Subject: Re: [diagnostic TDR mode patches] unify our solution
opinions/suggestions in o
anup_job won't return it so sched_main won't free it in parallel ...
What do you think ?
Thanks
--
Monk Liu | Cloud-GPU Core team
----------
From: Liu, Monk
Sent: Wednesday, September 1, 2021 9:23 AM
To: Koenig,
.: X server)
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Daniel Vetter
Sent: Tuesday, August 31, 2021 9:09 PM
To: Koenig, Christian
Cc: Grodzovsky, Andrey ; Christian König
[AMD Official Use Only]
Okay, I will reprepare this patch
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Daniel Vetter
Sent: Tuesday, August 31, 2021 9:02 PM
To: Liu, Monk
Cc: amd
[AMD Official Use Only]
Hi Daniel/Christian/Andrey
It looks the voice from you three are spread over those email floods to me, the
feature we are working on (diagnostic TDR scheme) is pending there for more
than 6 month (we started it from feb 2021).
Honestly speaking the email ways that we ar
o the
warning issue I hit.
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Daniel Vetter
Sent: Tuesday, August 31, 2021 9:02 PM
To: Liu, Monk
Cc: amd-...@lists.freedesktop
ing there, they should exclusively access those common members like
sched_job. (due to spin_lock is off before running into vendor's calback)
Hope I explained ourselves well enough.
Thanks
--
Monk Liu | Cloud-GPU Core team
---------
Sent: Tuesday, August 31, 2021 6:36 PM
To: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Liu, Monk
Subject: [PATCH 1/2] drm/sched: fix the bug of time out calculation(v3)
issue:
in cleanup_job the cancle_delayed_work will cancel a TO timer even the its
corresponding job is still
_DELAYED_WORK(&sched->work_tdr, drm_sched_job_timedout);
atomic_set(&sched->_score, 0);
atomic64_set(&sched->job_id_count, 0);
Thanks
--
Monk Liu | Cloud-GPU Core team
------
-Original Message-
riginal Message-
From: Christian König
Sent: Friday, August 27, 2021 2:12 PM
To: Grodzovsky, Andrey ; Liu, Monk
; amd-...@lists.freedesktop.org; Koenig, Christian
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v3)
I don't thi
Cloud-GPU Core team
--
-Original Message-
From: Grodzovsky, Andrey
Sent: Friday, August 27, 2021 4:14 AM
To: Liu, Monk ; amd-...@lists.freedesktop.org; Koenig,
Christian
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/sched: fix the bug of tim
--
-Original Message-
From: Christian König
Sent: Thursday, August 26, 2021 6:09 PM
To: Liu, Monk ; amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v3)
Am 26.08.21 um 06:5
---
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Grodzovsky, Andrey
Sent: Thursday, August 26, 2021 11:05 AM
To: Liu, Monk ; Christian König
; amd-...@lists.freedesktop.org; dri-devel
Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v
unning there, the whole counting is repeated from zero and inaccurate at all
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Grodzovsky, Andrey
Sent: Thursday, August 26, 2021 2:
Liu | Cloud-GPU Core team
--
-Original Message-
From: Christian König
Sent: Wednesday, August 25, 2021 8:11 PM
To: Liu, Monk ; amd-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v2)
No, th
---
Monk Liu | Cloud-GPU Core team
----------
-Original Message-
From: Grodzovsky, Andrey
Sent: Friday, August 20, 2021 10:07 PM
To: Liu, Monk ; Daniel Vetter ; Koenig,
Christian
Cc: Alex Deucher ; Chen, JingWen
; Maling list - DRI d
x27;t
impact performance since in that scenario
There was already something wrong/stuck on that ring/scheduler
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Liu, Monk
Sent: Thursday, Augu
t from later to earlier one and either deactive
* their HW callbacks or remove them from pending list if they already
* signaled.
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Daniel Vetter
Sent: Thur
s
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Daniel Vetter
Sent: Wednesday, August 18, 2021 10:43 PM
To: Grodzovsky, Andrey
Cc: Daniel Vetter ; Alex Deucher ;
Chen, JingWen ; Maling list -
m: Koenig, Christian
Sent: Friday, March 26, 2021 10:51 PM
To: Liu, Monk ; Zhang, Jack (Jian) ;
Grodzovsky, Andrey ; Christian König
; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org; Deng, Emily ; Rob Herring
; Tomeu Vizoso ; Steven Price
Cc: Zhang, Andy ; Jiang, Jerry (S
and your point here.
Thanks very much, and please understand our painful here
/Monk
-邮件原件-
发件人: Koenig, Christian
发送时间: 2021年3月26日 17:06
收件人: Zhang, Jack (Jian) ; Grodzovsky, Andrey
; Christian König
; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org; Liu, Monk ; Deng,
Grodzovsky, Andrey ;
Tuikov, Luben ; Thomas Zimmermann ;
Liu, Monk ; Yintian Tao ; Li, Dennis
; Liu, Shaoyun ; Zhang, Bokun
; Yang, Stanley ; Sheng, Wenhui
; Gong, Curry ; Daniel Vetter
Subject: [PATCH 3/5] drm/amdgpu: Paper over the drm_driver mangling for virt
Prep work to make drm_device->
Reviewed-by: monk@amd.com
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
Sent: Friday, August 9, 2019 11:31 PM
To: Grodzovsky, Andrey ;
dri-devel@lists.freedesktop.org; Liu, Monk ; Deng, Emily
Subject: [PATCH
Oh, yeah ... I find one aspect, we need to consider "range_start" and
"range_end"
Yeah, you guys are right, cool
/Monk
-Original Message-
From: Liu, Monk
Sent: Tuesday, November 27, 2018 10:10 PM
To: Koenig, Christian ; Chris Wilson
; dri-de...@freedesktop.org
age-
From: Christian König
Sent: Tuesday, November 27, 2018 9:48 PM
To: Liu, Monk ; Koenig, Christian ;
Chris Wilson ; dri-de...@freedesktop.org
Subject: Re: [PATCH] drm: should return upon the best size(v3)
Am 27.11.18 um 14:40 schrieb Liu, Monk:
>> A node with the searched size is not
nig
Sent: Tuesday, November 27, 2018 8:54 PM
To: Chris Wilson ; Liu, Monk ;
dri-de...@freedesktop.org
Subject: Re: [PATCH] drm: should return upon the best size(v3)
Am 27.11.18 um 11:00 schrieb Christian König:
> Am 27.11.18 um 10:20 schrieb Chris Wilson:
>> Quoting Monk Liu (2018-11
Hi Chris
Please check the sanity test of the patch from Rex
/Monk
From: Zhu, Rex
Sent: Friday, November 23, 2018 5:45 PM
To: Liu, Monk ; amd-...@lists.freedesktop.org
Subject: Re: [PATCH] drm: should break if already get the best size
Tested-by: Rex Zhu mailto:rex@amd.com>>
Withou
There is no checks at all in this best_hole() ... can you review the patch
again ?
/Monk
-Original Message-
From: Chris Wilson
Sent: Friday, November 23, 2018 5:34 PM
To: Liu, Monk ; dri-devel@lists.freedesktop.org
Subject: RE: FW: [PATCH] drm: should break if already get the best size
nt: Friday, November 23, 2018 5:03 PM
To: Liu, Monk ; dri-devel@lists.freedesktop.org
Subject: Re: FW: [PATCH] drm: should break if already get the best size
Quoting Liu, Monk (2018-11-23 08:02:11)
>
>
> -Original Message-
> From: amd-gfx On Behalf Of
> Monk Liu
> Sent: T
-Original Message-
From: amd-gfx On Behalf Of Monk Liu
Sent: Thursday, November 22, 2018 8:33 PM
To: amd-...@lists.freedesktop.org
Cc: Liu, Monk
Subject: [PATCH] drm: should break if already get the best size
Signed-off-by: Monk Liu
---
drivers/gpu/drm/drm_mm.c | 2 ++
1 file
-Original Message-
From: amd-gfx On Behalf Of Monk Liu
Sent: Thursday, November 22, 2018 8:33 PM
To: amd-...@lists.freedesktop.org
Cc: Liu, Monk
Subject: [PATCH] drm: should break if already get the best size
Signed-off-by: Monk Liu
---
drivers/gpu/drm/drm_mm.c | 2 ++
1 file
Yeah, I got the point, using dependency/scheduler to make sure the resulting
fence always not signal before the ones hooked in dependencies
thanks
/Monk
From: Christian K?nig
Sent: Tuesday, March 6, 2018 8:46:57 PM
To: Liu, Monk; Koenig, Christian
Cc: dri
From: Koenig, Christian
Sent: Tuesday, March 6, 2018 7:11:50 PM
To: Liu, Monk
Cc: dri-devel@lists.freedesktop.org; Chris Wilson
Subject: Re: reservation questions
Hi Monk,
your check isn't correct because you still haven't understood the semantics
eb
[ 105.704982] RIP: reservation_object_add_excl_fence+0x9c/0xf0 RSP:
b1204159f9f0
the assumption that all shared fences should be signaled before adding excl
fence looks not 100% guaranteed in LKG,
Going to take a deep look ...
/Monk
________
From: Liu, Monk
Sent: Tuesd
ok, that's good point ...
From: Koenig, Christian
Sent: Tuesday, March 6, 2018 6:42:44 PM
To: Liu, Monk; Chris Wilson; dri-devel@lists.freedesktop.org
Subject: Re: reservation questions
Hi Monk,
that is to remove the problem that allocating memory could
okay
From: Chris Wilson
Sent: Tuesday, March 6, 2018 4:24:21 PM
To: Liu, Monk; dri-de...@freedesktop.org
Cc: Liu, Monk
Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)
Quoting Monk Liu (2018-03-06 03:53:10)
> v2:
> still
count >= old->shared_max);
reservation_object_add_shared_inplace(obj, old, fence);
} else
reservation_object_add_shared_replace(obj, old, fobj, fence);
}
EXPORT_SYMBOL(reservation_object_add_shared_fence);
From: Chris Wilson
Sent: Tuesday, March 6,
_
From: Koenig, Christian
Sent: Tuesday, March 6, 2018 6:05:27 PM
To: Liu, Monk; dri-devel@lists.freedesktop.org; Chris Wilson
Subject: Re: reservation questions
Am 06.03.2018 um 10:56 schrieb Liu, Monk:
sorry, I have some mistake in previous thread, correct it as followings.
1) considering below s
en we add an excl fence to resv, how to deal with shared ? current logic
is just put the all
do we need to wait on their signaling before putting them ?
thanks
/Monk
From: Liu, Monk
Sent: 2018年3月6日 17:57
To: dri-devel@lists.freedesktop.org; Chris Wilson ;
Koenig, Christian
Subject: Re: reservati
e in
obj->fence is already put.
/Monk
From: Liu, Monk
Sent: Tuesday, March 6, 2018 5:45:19 PM
To: dri-devel@lists.freedesktop.org; Chris Wilson; Koenig, Christian
Subject: reservation questions
Hi Christian & Chris
two question regarding resv:
1)
Hi Christian & Chris
two question regarding resv:
1) considering below sequence:
call reservation_object_add_shared_fence,
now assume old->shared_count is now 3
call reservation_object_add_shared_fence,
now assume old->shared_count is now 4,
call reservation_object_reserve_shared,
now obj->stag
why? is there a design doc mentioned for this on reservation ?
From: Christian K?nig
Sent: Tuesday, March 6, 2018 4:03:39 PM
To: Liu, Monk; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] dma-buf/reservation: should keep the new fence in
add_shared_inplace
Make sense, will give v3
-Original Message-
From: Zhou, David(ChunMing)
Sent: 2018年3月6日 14:08
To: Liu, Monk ; Zhou, David(ChunMing) ;
dri-de...@freedesktop.org
Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)
On 2018年03月06日 13:59, Liu, Monk wrote
is check into fobj->shared[++j], so in the end
Obj->fence will point to fobj, and original old would be rcu_kfree()
No additional action actually needed...
/Monk
-Original Message-
From: Zhou, David(ChunMing)
Sent: 2018年3月6日 12:25
To: Liu, Monk ; dri-de...@freedesktop.org
Subject:
Yeah, right
-Original Message-
From: Zhou, David(ChunMing)
Sent: 2018年3月6日 11:38
To: Liu, Monk ; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] dma-buf/reservation: should keep the new fence in
add_shared_inplace
On 2018年03月06日 11:09, Monk Liu wrote:
> Change
Can you give more details ? thanks
/Monk
-Original Message-
From: Koenig, Christian
Sent: 2018年3月5日 19:39
To: Liu, Monk ; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot
available
Am 05.03
NULL, so why we
kfree on it
2) in fact, amdgpu can hit the case that obj->staged is not NULL in
reserved_shared(), don't know how it lead here
Any thought ?
/Monk
-Original Message-
From: Koenig, Christian
Sent: 2018年3月5日 19:29
To: Liu, Monk ; dri-devel@lists.freedesktop
s a little weired to me ...
especially this staged part ...
Thanks
/Monk
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: 2018年3月5日 19:22
To: Liu, Monk ; Koenig, Christian ;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subje
mer...@gmail.com]
Sent: 2018年2月28日 16:27
To: Liu, Monk ; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot
available
Am 28.02.2018 um 07:44 schrieb Monk Liu:
> under below scenario the obj->fence wo
I'm wondering if GPU reset still work after this home move ...
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Friday, December 1, 2017 11:55 PM
To: Lucas Stach ; Deucher, Alexander
Cc: Grodzovsky, Andrey ; David Airli
+ Horace
-Original Message-
From: Colin King [mailto:colin.k...@canonical.com]
Sent: 2017年11月11日 19:51
To: Deucher, Alexander ; Koenig, Christian
; David Airlie ; Liu, Monk
; Yu, Xiangliang ;
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: kernel-janit
verified work,
Reviewed-by: Monk Liu
From: amd-gfx on behalf of Christian
König
Sent: Wednesday, September 13, 2017 4:47:34 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: fix memory leak while individualizing B
Reviewed-by: Monk Liu
From: amd-gfx on behalf of
Xiangliang.Yu
Sent: Wednesday, August 16, 2017 3:20:46 PM
To: a...@linux-foundation.org; labb...@redhat.com;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Yu, Xiangliang
Subject: [PATCH 1/1]
Ack-by: Monk.Liu
From: amd-gfx on behalf of Christian
König
Sent: Tuesday, August 8, 2017 4:14:46 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Dave
Airlie; Gerd Hoffmann
Subject: Re: [PATCH 2/7] drm/qxl: fix incorrect use of the lru_l
thanks for this catch!
Reviewed-by: Monk Liu
发件人: Colin King
发送时间: 2017年2月4日 4:23:42
收件人: Deucher, Alexander; Koenig, Christian; David Airlie; Liu, Monk; Yu,
Xiangliang; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
抄送: kernel-janit
June 07, 2016 3:34 PM
To: Alex Deucher
Cc: dri-devel at lists.freedesktop.org; Liu, Monk
Subject: Re: [PATCH 1/4] drm/amdgpu: clear RB at ring init
On 02.06.2016 07:27, Alex Deucher wrote:
> From: Monk Liu
>
> This help fix reloading driver hang issue of SDMA ring.
>
> Signed-
61 matches
Mail list logo
