RE: [PATCH 4/4] drm/amdgpu/SRIOV:implement guilty job TDR (V2)

kernel driver side, but it is not easy so currently I only trust timedout event BR Monk From: Christian König [mailto:deathsim...@vodafone.de] Sent: Wednesday, May 10, 2017 7:14 PM To: Liu, Monk ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 4/4] drm/amdgpu/SRIOV:implement guil

FW: [PATCH] drm/amdgpu:fix DMAframe for GFX8

-Original Message- From: Monk Liu [mailto:monk@amd.com] Sent: Wednesday, August 24, 2016 12:00 PM To: amd-gfx@lists.freedesktop.org Cc: Liu, Monk Subject: [PATCH] drm/amdgpu:fix DMAframe for GFX8 1,drop inserting double SWITCH_BUFFERS scheme, which impacts performance, because

RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

1,drop inserting double SWITCH_BUFFERS scheme, which impacts performance, because double SWITCH_BUFFER actaully doesn't switch buffer, so the CE's ping-pong buffer is not used at all. Now only insert one SWITCH_BUFFERS at the bottom of each GFX dmaframe. And only inserting one SWITCH_BUFFER is

cannot send email to amd-gfx

Hi Alex I tried use git send-email to send patch to amd-gfx, but seems it failed, So I use git send-email to send patch to myself, it's okay. And I forward the patch mail to amd-gfx@lists.freedesktop.org with outlook, and it also failed Is that my account

RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

re than 128 DWs ahead of where DE is updating the page table it will work due to the padding and the limitation of the ROQ. /Hans From: Liu, Monk Sent: Monday, August 15, 2016 11:35 PM To: Fernlund, Hans Cc: Deucher, Alexander; Li, Bingley; Liu, Robert; Wang, Daniel(Xiaowei); Jiang, Jerry (SW)

RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

al Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Wednesday, August 24, 2016 4:56 PM To: Liu, Monk ; amd-gfx@lists.freedesktop.org Cc: Wang, Daniel(Xiaowei) ; Jiang, Jerry (SW) Subject: Re: [PATCH] drm/amdgpu:fix DMAframe for GFX8 Am 24.

RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

switch or not, the way is that it should always run “preamble CE IB” to restore the CE ram. BR Monk From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu, Monk Sent: Wednesday, August 24, 2016 5:23 PM To: Christian König ; amd-gfx@lists.freedesktop.org Cc: Wang, Daniel

RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

ly mean for gfx and compute ring, why SDMA engine is involved ? And besides compute UMD doesn't need CE by far, so only GFX ring need preamble CE IB by far. -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Wednesday, August 24, 2016 5:38 PM

RE: [PATCH 0/6] make ctx mgr global

David, No matter what's the initial purpose of this patch is, I think this patch is needed, otherwise context switch judgment will be incorrect , e.g. process1 and process2 can both have a context id 99, and that will Lead to incorrect skipping of PREAMBLE CE IB BR monk -Original Message-

RE: [PATCH 0/6] make ctx mgr global

s fence_context is already globally unique, so never mind, our current code is okay! Thanks BR Monk -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Wednesday, August 24, 2016 8:21 PM To: Liu, Monk ; Zhou,

RE: [PATCH 0/6] make ctx mgr global

Yeah, I was already doing that -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Thursday, August 25, 2016 4:08 PM To: Liu, Monk ; Zhou, David(ChunMing) ; amd-gfx@lists.freedesktop.org Cc: Mao, David Subject: Re: [PATCH 0/6] make ctx mgr global Yeah, I

RE: [PATCH 2/2] drm/amdgpu:256dw is enough for one ib_schedule

But even user space will submit 10 ibs this submission, the calculate of 256*ibs is totally overflow, remember that ring buffer is only 4kb size -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Thursday, August 25, 2016 4:12 PM To: Liu, Monk ; amd-gfx

RE: [PATCH 1/2] drm/amdgpu:fix gfx ib schedule

ahead of DE by a certain number DW ) So I think CE can keep the original logic. BR Monk -Original Message- From: Deucher, Alexander Sent: Thursday, August 25, 2016 9:33 PM To: Liu, Monk ; amd-gfx@lists.freedesktop.org Cc: Liu, Monk Subject: RE: [PATCH 1/2] drm/amdgpu:fix gfx ib sch

RE: [PATCH 1/2] drm/amdgpu:fix gfx ib schedule

But for VI. My patch will reduce those 5 redundant SB and one SB can always use ping-pong buffer, so the performance looks raised around 5%. BR Monk -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu, Monk Sent: Friday, August 26, 2016 11

amd-gfx@lists.freedesktop.org

No, compute ring also can leverage constant engines, that's depend on OCL umd behavior I just make sure KMD do nothing wrong BR Monk -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Monday, August 29, 2016 4:06 PM To: Liu, Monk ; am

RE: [PATCH 4/4] drm/amdgpu:implement CONTEXT_CONTROL

n K?nig Sent: Monday, August 29, 2016 4:10 PM To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 4/4] drm/amdgpu:implement CONTEXT_CONTROL Am 29.08.2016 um 04:55 schrieb Monk Liu: > use CONTEXT_CONTROL package to dynamically skip preamble IB and other > load_xxx command in

amd-gfx@lists.freedesktop.org

But speaking with practice attitude: at least close source UMD OCL doesn't use CE at all, and I guess MESA either ... BR Monk -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Monday, August 29, 2016 4:25 PM To: Liu, Monk ; amd-gfx@lists.freedeskto

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

If no one object, I'll push the patch tomorrow. Tested with FIJI and BONAIRE locally. BR Monk -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Monk Liu Sent: Wednesday, August 31, 2016 11:49 AM To: amd-gfx@lists.freedesktop.org Cc: Liu,

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

-Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Wednesday, August 31, 2016 7:53 PM To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3) Looks good to me in general

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

so deal DE. BR Monk -Original Message- From: Bas Nieuwenhuizen [mailto:b...@basnieuwenhuizen.nl] Sent: Thursday, September 01, 2016 4:19 PM To: Liu, Monk Cc: Christian König ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3) On T

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

sday, September 01, 2016 10:10 PM To: Liu, Monk ; Bas Nieuwenhuizen Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3) Am 01.09.2016 um 12:55 schrieb Liu, Monk: >> Why does that makes a difference if it is seen for the first time? >> >>

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

rg] On Behalf Of Christian K?nig Sent: Thursday, September 01, 2016 10:10 PM To: Liu, Monk ; Bas Nieuwenhuizen Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3) Am 01.09.2016 um 12:55 schrieb Liu, Monk: >> Why does that makes a difference if it

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

in DE ib is not covered, CONTEXT_CONTROL can fix that BR Monk -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu, Monk Sent: Thursday, September 01, 2016 11:15 PM To: Christian König ; Bas Nieuwenhuizen Cc: amd-gfx@lists.freedesktop.org Subject:

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

'll consider upstream amdgpu KMD refuse to support SR-IOV/virtualization. You need think it twice, you are insisting a wrong design/approach although it runs for years. BR Monk BR Monk -Original Message- From: Bas Nieuwenhuizen [mailto:b...@basnieuwenh

amd-gfx@lists.freedesktop.org

Yeah, CPC cannot use constant engine. BR Monk -Original Message- From: Marek Olšák [mailto:mar...@gmail.com] Sent: Tuesday, September 06, 2016 3:13 AM To: Deucher, Alexander Cc: Christian König ; Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 2/4] drm/amdgpu:new method

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

ONTEXT_CONTROL patch BR Monk -Original Message- From: Koenig, Christian Sent: Monday, September 05, 2016 7:57 PM To: Liu, Monk Cc: brahma_hybrid_dev Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3) Another possible solution which just came to my mind: Completely ignore

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)

--Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Tuesday, September 06, 2016 5:39 PM To: Liu, Monk ; Koenig, Christian ; Bas Nieuwenhuizen Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3) > 1) Is that my patch

RE: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v5)

Oh, yeah. That is missed, thanks! -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of zhoucm1 Sent: Thursday, September 08, 2016 2:01 PM To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v5

RE: [PATCH 4/4] drm/amdgpu:determine if vPost is needed indeed

Sorry, ignore this one, it's not correct and I have sent another one BR Monk -Original Message- From: Monk Liu [mailto:monk@amd.com] Sent: Wednesday, September 14, 2016 7:48 PM To: amd-gfx@lists.freedesktop.org Cc: Liu, Monk Subject: [PATCH 4/4] drm/amdgpu:determine if vPo

RE: [PATCH 3/5] drm/amdgpu:fix RB cost calculator

Is that applied to all ring ? Cuz seems only GFX ring each lot of dw per submit ... BR Monk -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Thursday, September 15, 2016 3:24 PM To: Andy Furniss ; Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re

RE: [PATCH] drm/amdgpu/si: remove unused interface which caused build issue

You can add my RB -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Huang Rui Sent: Monday, September 19, 2016 4:12 PM To: amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Koenig, Christian Cc: Wang, Ken ; Huang, Ray ; Liu, Monk Subject

RE: [PATCH 5/5] drm/amdgpu/si: add detect_hw_virtualization asic callback

All those 5 patches are : Reviewed-by: Monk Liu -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Alex Deucher Sent: Tuesday, September 20, 2016 2:36 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH 5/5] drm/amdgpu/si

RE: [PATCH] drm/amdgpu:fix exclusive mode game texture blank(v2)

Already pushed to staging because Pro team are kinda hurry for this fix The alloc size isn't need changed, cuz it always count vm_flush() in event no vm_flush needed BR Monk -Original Message- From: Deucher, Alexander Sent: Friday, September 30, 2016 9:23 PM To: Liu, Monk ; am

RE: [PATCH] drm/amdgpu:fix exclusive mode game texture blank(v2)

riday, September 30, 2016 5:07 PM To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:fix exclusive mode game texture blank(v2) NAK, please stop adding workarounds like this into common code. If we need to add the extra NOPs between each command submission than just do this i

RE: [PATCH] drm/amdgpu:set preemption flag bit

Okay, good advice BR Monk -Original Message- From: Alex Deucher [mailto:alexdeuc...@gmail.com] Sent: Friday, October 21, 2016 10:55 PM To: Christian König Cc: Liu, Monk ; amd-gfx list Subject: Re: [PATCH] drm/amdgpu:set preemption flag bit On Fri, Oct 21, 2016 at 5:59 AM, Christian

RE: [PATCH] drm/amdgpu: Add a ring type KIQ definition

, November 01, 2016 3:20 PM To: amd-gfx@lists.freedesktop.org Cc: Liu, Monk ; Yu, Xiangliang ; Huang, Trigger Subject: [PATCH] drm/amdgpu: Add a ring type KIQ definition Add a new ring type definition for KIQ. KIQ is used for interaction between driver and CP. Signed-off-by: Xiangliang Yu Signed

RE: [PATCH] drm/amdgpu:bypass avfs event manager for sriov

gger ; amd-gfx@lists.freedesktop.org Cc: Min, Frank ; Yu, Xiangliang ; Liu, Monk ; Huang, Trigger Subject: RE: [PATCH] drm/amdgpu:bypass avfs event manager for sriov > -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Trigger Hu

答复: [PATCH] drm/amdgpu:fix vpost_needed routine

Alex, the patch is already rebased against staging-4.7 , it just fixed non-FIJI pass-through bug, which should use regular rules but without this patch it will always do post. BR Monk -邮件原件- 发件人: Deucher, Alexander 发送时间: Friday, November 11, 2016 11:05 PM 收件人: Liu, Monk; amd

答复: [PATCH] drm/amdgpu:impl vgt_flush for VI

: Liu, Monk 主题: [PATCH] drm/amdgpu:impl vgt_flush for VI when hardware shadowing enabled, tesselation will trigger vm fault, the root cause is because VGT_FLUSH not introduced in kmd. this could fix tesselation crash issue. Change-Id: I77d87d93ce6580e559e734fb41d97ee8c59d245b Signed-off-by: Monk Liu

答复: 答复: [PATCH] drm/amdgpu:impl vgt_flush for VI

seems not grace ... BR Monk -邮件原件- 发件人: Christian König [mailto:deathsim...@vodafone.de] 发送时间: Monday, November 14, 2016 5:46 PM 收件人: Liu, Monk; amd-...@freedesktop.org 主题: Re: 答复: [PATCH] drm/amdgpu:impl vgt_flush for VI Am 14.11.2016 um 04:17 schrieb Liu, Monk: > Anyone review th

答复: [PATCH] drm/amdgpu:impl vgt_flush for VI(v2)

If no one review it I'm going to push it later -邮件原件- 发件人: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] 代表 Monk Liu 发送时间: Monday, November 14, 2016 11:38 AM 收件人: amd-...@freedesktop.org 抄送: Liu, Monk 主题: [PATCH] drm/amdgpu:impl vgt_flush for VI(v2) when shadowing en

答复: 答复: 答复: [PATCH] drm/amdgpu:impl vgt_flush for VI

I have no strong opinion, I checked windows kmd and they separate vgt-flush and cntx-ctrl as well, Fine with your suggestion BR Monk -邮件原件- 发件人: Christian König [mailto:deathsim...@vodafone.de] 发送时间: Monday, November 14, 2016 7:33 PM 收件人: Liu, Monk; amd-...@freedesktop.org 主题: Re: 答复

答复: [PATCH 1/2] amdgpu: fix firmware loading failure

Please use "drm/amdgpu" as th prefix for the title -邮件原件- 发件人: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] 代表 Xiangliang Yu 发送时间: Monday, November 21, 2016 2:13 PM 收件人: amd-...@freedesktop.org 抄送: Yu, Xiangliang 主题: [PATCH 1/2] amdgpu: fix firmware loading failure For virtualiz

RE: [V2 5/6] drm/amdgpu: Don't touch GFX hw during HW fini

Reviewed-by: monk liu -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Xiangliang Yu Sent: Friday, December 02, 2016 2:04 PM To: amd-gfx@lists.freedesktop.org Cc: Yu, Xiangliang ; Liu, Shaoyun Subject: [V2 5/6] drm/amdgpu: Don't touch GFX hw du

答复: [PATCH 09/23] drm/amdgpu: enable virtualization feature for FIJI/TONGA

- r = vi_set_ip_blocks(adev); detect_sriov(adev); if (amdgpu_sriov_vf(adev)) + adev->flags |= AMD_IS_VF; if (adev->flags & AMD_IS_VF) + r = amd_xgpu_set_ip_blocks(adev); + el

转发: [PATCH 07/23] drm/amdgpu: create new directory for GPU virtualization

Forward to amd-gfx. 发件人: Yu, Xiangliang 发送时间: Monday, December 19, 2016 1:49 PM 收件人: Liu, Monk; dl.SRDC_SW_GPUVirtualization 主题: RE: [PATCH 07/23] drm/amdgpu: create new directory for GPU virtualization Make sense. Thanks! Xiangliang Yu From: Liu, Monk Sent: Monday, December 19, 2016 1:28 PM

转发: [PATCH 02/23] drm/amdgpu: add kiq into compiling

Sorry, NAK for the KIQ implement patches. KIQ is just another compute queue, and each generation of compute queue initialization is different, so there is no need of a amdgpu_kiq.c file to cover the function of kiq, Kiq is good enough to be in each gfx_x_x.c file .e.g : KIQ for VI is in gfx_v

答复: [PATCH 00/23] Add support AMD GPU virtualization soultion

Hi xiangliang seems only the cover page was sent to amd-gfx loops, the rest of your serials were not BR Monk 发件人: amd-gfx 代表 Xiangliang Yu 发送时间: 2016年12月18日 0:16:22 收件人: amd-gfx@lists.freedesktop.org; dl.SRDC_SW_GPUVirtualization 抄送: Yu, Xiangliang 主题: [PAT

答复: 转发: [PATCH 02/23] drm/amdgpu: add kiq into compiling

yeah, I'll take a deep look, we are not in hurry to submit those SRIOV patches, for the VA update part (if you mean CSA mappings) I'll pay attention on it, thanks BR Monk 发件人: Alex Deucher 发送时间: 2016年12月20日 7:38:10 收件人: Christian König 抄送: Liu, Mon

答复: [PATCH 09/23] drm/amdgpu: enable virtualization feature for FIJI/TONGA

agree with Alex on that, the patch looks overhead on the ip blocks cherry-picking logic, we could keep it as simple as original style, as long as we know current device is a VF device, we shall know how many ip blocks need be cherry-picked and assembled together BR Monk _

答复: [PATCH 11/23] drm/amdgpu: implement context save area(CSA) feature

current IB's context (that's why need do mapping for each virtual memory on CSA) BR Monk 发件人: Alex Deucher 发送时间: 2016年12月20日 7:20:09 收件人: Yu, Xiangliang 抄送: amd-gfx list; dl.SRDC_SW_GPUVirtualization; Liu, Monk 主题: Re: [PATCH 11/23] drm/amdgpu: implement co

答复: [PATCH 21/23] drm/amdgpu: change golden register program sequence of virtualization

sters in one routine) BR Monk 发件人: Alex Deucher 发送时间: 2016年12月20日 7:37:06 收件人: Yu, Xiangliang 抄送: amd-gfx list; dl.SRDC_SW_GPUVirtualization; Min, Frank; Liu, Monk 主题: Re: [PATCH 21/23] drm/amdgpu: change golden register program sequence of virtualization On Sat

答复: 转发: [PATCH 02/23] drm/amdgpu: add kiq into compiling

something BR Monk 发件人: amd-gfx 代表 Christian König 发送时间: 2016年12月19日 19:17:38 收件人: Liu, Monk; amd-gfx@lists.freedesktop.org 主题: Re: 转发: [PATCH 02/23] drm/amdgpu: add kiq into compiling Yeah, agree totally with Monk here. If you find that you need some KIQ

RE: [PATCH] drm/amdgpu:resolv deadlock between reset and cs_ioctl

: Christian König [mailto:deathsim...@vodafone.de] Sent: 2017年9月11日 17:13 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:resolv deadlock between reset and cs_ioctl Am 11.09.2017 um 11:02 schrieb Monk Liu: > need to unreserve ttm bo before "cs_add_fence" and "enti

Re: [PATCH 4/5] drm/amdgpu: cleanup amdgpu_bo_pin_restricted

5:21:13 PM To: Liu, Monk; Deucher, Alexander; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 4/5] drm/amdgpu: cleanup amdgpu_bo_pin_restricted amdgpu_bo_create() doesn't necessarily allocate anything, it just creates the BO structure. The backing memory for GTT and CPU domain is only allo

Re: [PATCH 4/5] drm/amdgpu: cleanup amdgpu_bo_pin_restricted

SRIOV need to reserve a memory at an offset that set by GIM/hypervisor side, but I'm not sure how to do it perfectly, currently we call bo_create to allocate a VRAM BO, and call pin_restrict with "offset" as parameter for "min" and "offset + size" as "max", I feel strange of above approach fr

Re: [PATCH] drm/ttm: fix memory leak while individualizing BOs

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-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: [PATCH] drm/ttm: fix memory leak while individualizing B

Re: [PATCH 4/5] drm/amdgpu: cleanup amdgpu_bo_pin_restricted

yeah, that's right ! Thanks BR Monk From: Christian König Sent: Wednesday, September 13, 2017 5:30 PM To: Liu, Monk; Deucher, Alexander; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 4/5] drm/amdgpu: cleanup amdgpu_bo_pin_restricted but we use

RE: [PATCH 13/18] drm/amdgpu:fix driver unloading bug

aming under SRIOV both in init and fini, but that will come later BR Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年9月18日 17:28 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Cc: Chen, Horace Subject: Re: [PATCH 13/18] drm/amdgpu:fix

RE: [PATCH 06/18] drm/amdgpu/sriov:fix memory leak after gpu reset

rnel won't address the issue ... BR Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年9月18日 17:13 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 06/18] drm/amdgpu/sriov:fix memory leak after gpu reset Am 18.0

RE: [PATCH 12/18] drm/amdgpu:use formal register to trigger hdp invalidate

Only vega10 has this register -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年9月18日 17:20 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 12/18] drm/amdgpu:use formal register to trigger hdp invalidate Am 18.09.2017 um 08

RE: [PATCH 12/18] drm/amdgpu:use formal register to trigger hdp invalidate

Yeah, vnc1_0 and uvd_v7_0 Thanks -Original Message- From: Koenig, Christian Sent: 2017年9月18日 19:39 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 12/18] drm/amdgpu:use formal register to trigger hdp invalidate Yeah, but Vega10 has UVD7 and in uvd_v7_0.c we have

RE: [PATCH 13/18] drm/amdgpu:fix driver unloading bug

mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年9月18日 19:54 To: Liu, Monk ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Cc: Chen, Horace Subject: Re: [PATCH 13/18] drm/amdgpu:fix driver unloading bug Am 18.09.2017 um 12:12 schrieb Liu, Monk: > Christian, > > Let's discuss t

RE: [PATCH 12/18] drm/amdgpu:use formal register to trigger hdp invalidate

What question ? please reply here -Original Message- From: Zhou, David(ChunMing) Sent: 2017年9月19日 12:25 To: Liu, Monk ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Subject: RE: [PATCH 12/18] drm/amdgpu:use formal register to trigger hdp invalidate Please answer my question as I

RE: [PATCH 12/18] drm/amdgpu:use formal register to trigger hdp invalidate

still, is that okay ? BR Monk -Original Message- From: Zhou, David(ChunMing) Sent: 2017年9月19日 14:51 To: Liu, Monk ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 12/18] drm/amdgpu:use formal register to trigger hdp invalidate Seems the change is more proper, but wh

RE: [PATCH 13/18] drm/amdgpu:fix driver unloading bug

> Well the question is why does the CPC still needs the MQD commands and how > can we prevent that? You are right, I'll see what can do -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年9月19日 16:27 To: Liu, Monk ; Koenig, Chris

RE: [PATCH 04/18] drm/amdgpu/sriov:don't load psp fw during gpu reset

This condition is wrong, you are right, and I followed up a patch to correct it Should be : If (!amdgpu_sriov_vf()) || !adev->in_reset) BR Monk -Original Message- From: Quan, Evan Sent: 2017年9月20日 9:32 To: Koenig, Christian ; Liu, Monk ; amd-gfx@lists.freedesktop.org Subject:

RE: [PATCH 06/18] drm/amdgpu/sriov:fix memory leak after gpu reset

n BR Monk -Original Message- From: Koenig, Christian Sent: 2017年9月18日 19:35 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 06/18] drm/amdgpu/sriov:fix memory leak after gpu reset Am 18.09.2017 um 12:47 schrieb Liu, Monk: > I didn't get your point... how could bo_crea

RE: [PATCH 2/3] drm/amdgpu/sriov:fix memory leak after gpu reset

...@gmail.com] Sent: 2017年9月19日 19:44 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 2/3] drm/amdgpu/sriov:fix memory leak after gpu reset Am 19.09.2017 um 08:41 schrieb Monk Liu: > GPU reset will require all hw doing hw_init thus ucode_init_bo will be > invoked again, which l

RE: [PATCH] drm/amdgpu/sriov:fix driver unloading bug

! -Original Message- From: Deucher, Alexander Sent: 2017年9月21日 14:58 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Cc: Chen, Horace ; Liu, Monk Subject: RE: [PATCH] drm/amdgpu/sriov:fix driver unloading bug > -Original Message- > From: amd-gfx [mailto:amd-gf

RE: [PATCH 2/4] drm/amdgpu/sriov:alloc KIQ MQD in VRAM

it's hard to recall what's going on I prefer keep things different that's good to maintain the stability BR Monk -Original Message- From: Deucher, Alexander Sent: 2017年9月21日 23:00 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Cc: Liu, Monk Subject: RE: [PATCH 2/4] d

RE: [PATCH 2/4] drm/amdgpu/sriov:alloc KIQ MQD in VRAM

alright -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年9月22日 15:15 To: Liu, Monk ; Deucher, Alexander ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 2/4] drm/amdgpu/sriov:alloc KIQ MQD in VRAM Hi Monk, I agree with Alex here. We

RE: [PATCH] drm/amdgpu: right shift 2 bits for SDMA_GFX_RB_WPTR_POLL_ADDR_LO

riginal Message- From: Pixel Ding [mailto:pixel.d...@amd.com] Sent: Monday, September 25, 2017 2:16 PM To: amd-gfx@lists.freedesktop.org; Ding, Pixel ; Min, Frank ; Liu, Monk ; Deucher, Alexander Subject: [PATCH] drm/amdgpu: right shift 2 bits for SDMA_GFX_RB_WPTR_POLL_ADDR_LO Both Tonga an

RE: [PATCH] drm/amdgpu: right shift 2 bits for SDMA_GFX_RB_WPTR_POLL_ADDR_LO

the same with or without you patch BR Monk -Original Message----- From: Ding, Pixel Sent: Monday, September 25, 2017 2:42 PM To: Liu, Monk ; amd-gfx@lists.freedesktop.org; Min, Frank ; Deucher, Alexander ; Yu, Xiangliang Subject: Re: [PATCH] drm/amdgpu: right shift 2 bits for SDMA_GFX_RB_

RE: [PATCH 12/12] drm/amdgpu/sriov:no shadow buffer recovery

Why ? the page tables are resided in VRAM, no need to recovery if no VRAM lost Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Christian König<mailto:ckoenig.leichtzumer...@gmail.com> Sent: 2017年10月1日 17:36 To: Liu, Monk<mailto:monk@amd

RE: [PATCH 12/12] drm/amdgpu/sriov:no shadow buffer recovery

Any updates for the rest patches ? From: Koenig, Christian Sent: 2017年10月4日 18:56 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 12/12] drm/amdgpu/sriov:no shadow buffer recovery Ah! Sorry, my fault. I've missed the "no" and thought you wanted to abandon

RE: [PATCH 2/2] dmr/amdgpu: Move old fence waiting before reservation lock is aquired.

Hi Andrey Where is your first patch (1/2)? I only saw the 2/2 BR Monk -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Andrey Grodzovsky Sent: 2017年10月7日 2:20 To: amd-gfx@lists.freedesktop.org Cc: Grodzovsky, Andrey ; Koenig, Christian Subj

RE: [PATCH 5/5] drm/amd/sched: signal and free remaining fences in amd_sched_entity_fini

Christian > It would be really nice to have an error code set on s_fence->finished before > it is signaled, use dma_fence_set_error() for this. For gpu reset patches (already submitted to pub) I would make kernel return -ENODEV if the waiting fence (in cs_wait or wait_fences IOCTL) founded as

RE: [PATCH 07/12] drm/amdgpu/sriov:implement strict gpu reset

- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年10月9日 16:20 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 07/12] drm/amdgpu/sriov:implement strict gpu reset Am 30.09.2017 um 08:03 schrieb Monk Liu: > changes: > 1)implement strict mode s

RE: [PATCH 08/12] drm/amdgpu:explicitly call fence_process

Why do that ? In outside there is already a for loop to iterate over all rings so force_completion_ring() is the right one to use BR Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年10月9日 16:24 To: Liu, Monk ; amd-gfx

RE: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted

Sent: 2017年10月9日 16:26 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted Am 30.09.2017 um 08:03 schrieb Monk Liu: > for SRIOV strict mode gpu reset: > > In kms open we mark the latest adev->gpu_reset_counter in f

RE: [PATCH 10/12] drm/amdgpu/sriov:implement guilty ctx for loose reset

:ckoenig.leichtzumer...@gmail.com] Sent: 2017年10月9日 16:28 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 10/12] drm/amdgpu/sriov:implement guilty ctx for loose reset Am 30.09.2017 um 08:03 schrieb Monk Liu: > Change-Id: I7904f362aa0f578a5cbf5d40c7a242c2c6680a92 > Signed-of

RE: [PATCH 08/12] drm/amdgpu:explicitly call fence_process

That's clean way -Original Message- From: Koenig, Christian Sent: 2017年10月9日 16:41 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 08/12] drm/amdgpu:explicitly call fence_process We should avoid functionality duplication here. Either change the call

RE: [PATCH 08/12] drm/amdgpu:explicitly call fence_process

Amends: If you are picky on the duplication here, the good approach is removing the old force_completion(), and use force_completion_ring() in all gpu reset routines -Original Message- From: Liu, Monk Sent: 2017年10月9日 16:52 To: Koenig, Christian ; amd-gfx@lists.freedesktop.org Subject

RE: [PATCH 10/12] drm/amdgpu/sriov:implement guilty ctx for loose reset

compositor eve didn't aware of a gpu reset at all, they just keep running BR Monk -Original Message- From: Koenig, Christian Sent: 2017年10月9日 17:04 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 10/12] drm/amdgpu/sriov:implement guilty ctx for loose reset Well I&

RE: [PATCH 5/5] drm/amd/sched: signal and free remaining fences in amd_sched_entity_fini

e + Marek BR Monk -Original Message- From: Haehnle, Nicolai Sent: 2017年10月9日 18:14 To: Koenig, Christian ; Liu, Monk ; Nicolai Hähnle ; 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

RE: [PATCH 5/5] drm/amd/sched: signal and free remaining fences in amd_sched_entity_fini

Monk -Original Message- From: Koenig, Christian Sent: 2017年10月9日 20:34 To: Haehnle, Nicolai ; Liu, Monk ; Nicolai Hähnle ; 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 Am 09.10

RE: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted

From: Nicolai Hähnle [mailto:nhaeh...@gmail.com] Sent: 2017年10月9日 19:01 To: Liu, Monk ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted On 09.10.2017 10:35, Liu, Monk wrote: > Please be aware that this policy is what th

RE: [PATCH 4/4] drm/amdgpu: set -ECANCELED when dropping jobs

You should use "dma_fence_wait_timeout()" instead of fence->error, that's more make sense -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: 2017年10月9日 23:35 To: amd-gfx@lists.freedesktop.org Subject: [PATCH 4/4] drm/amdg

RE: [PATCH 4/4] drm/amdgpu: set -ECANCELED when dropping jobs

Sorry, should be "dma_fence_get_error" -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu, Monk Sent: 2017年10月10日 12:37 To: Christian König ; amd-gfx@lists.freedesktop.org Subject: RE: [PATCH 4/4] drm/amdgpu: set -ECANCELED whe

RE: [PATCH 4/4] drm/amdgpu: set -ECANCELED when dropping jobs

Should be "dma_fence_get_status()" -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu, Monk Sent: 2017年10月10日 12:37 To: Christian König ; amd-gfx@lists.freedesktop.org Subject: RE: [PATCH 4/4] drm/amdgpu: set -ECANCELED when dro

RE: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted

Then the question is how we treat recovery if VRAM lost ? -Original Message- From: Koenig, Christian Sent: 2017年10月10日 14:59 To: Liu, Monk ; Nicolai Hähnle ; amd-gfx@lists.freedesktop.org; Daenzer, Michel Subject: Re: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted As

RE: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted

To: Liu, Monk ; Nicolai Hähnle ; amd-gfx@lists.freedesktop.org; Daenzer, Michel Subject: Re: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted As Nicolai explained that approach simply won't work. The fd is used by more than just the closed source Vulkan driver and I think ev

RE: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted

From: Koenig, Christian Sent: 2017年10月10日 15:26 To: Liu, Monk ; Nicolai Hähnle ; amd-gfx@lists.freedesktop.org; Daenzer, Michel Subject: Re: [PATCH 09/12] drm/amdgpu/sriov:return -ENODEV if gpu reseted As Nicolai described before: The kernel will reject all command submission from context

RE: [PATCH v2 2/2] drm/amdgpu: Move old fence waiting before reservation lock is aquired.

Sent: Wednesday, October 11, 2017 4:50 AM To: Koenig, Christian ; Liu, Monk ; amd-gfx@lists.freedesktop.org Cc: Grodzovsky, Andrey Subject: [PATCH v2 2/2] drm/amdgpu: Move old fence waiting before reservation lock is aquired. Helps avoiding deadlock during GPU reset. Added mutex to amdgpu_ctx to pres

TDR and VRAM lost handling in KMD:

Hi Christian & Nicolai, We need to achieve some agreements on what should MESA/UMD do and what should KMD do, please give your comments with “okay” or “No” and your idea on below items, l When a job timed out (set from lockup_timeout kernel parameter), What KMD should do in TDR routine : 1

RE: TDR and VRAM lost handling in KMD:

+ david From: Liu, Monk Sent: Wednesday, October 11, 2017 1:34 PM To: Koenig, Christian ; Haehnle, Nicolai ; Olsak, Marek ; Deucher, Alexander Cc: amd-gfx@lists.freedesktop.org; Ding, Pixel ; Jiang, Jerry (SW) ; Li, Bingley (bingley...@amd.com) ; Ramirez, Alejandro ; Filipas, Mario

RE: [PATCH v2 2/2] drm/amdgpu: Move old fence waiting before reservation lock is aquired.

No pthread_mutex cannot retired, because its protection range is not only the IOCTL, there are other struct field need pthread_mutex's protection -Original Message- From: Zhou, David(ChunMing) Sent: Wednesday, October 11, 2017 3:42 PM To: Koenig, Christian ; Liu, Monk ; Grodz

RE: TDR and VRAM lost handling in KMD:

the right thing for this? [ML] yeah, that’s too confusing, the name sound really the one I want to use, we should change it… But look into the implement, I don’t see why we cannot use it ? it also finally return the fence->error From: Koenig, Christian Sent: Wednesday, October 11, 2017 3:21 PM

RE: TDR and VRAM lost handling in KMD:

can implement it own “guilty” gl-context if you want. If KMD doesn’t mark all ctx as guilty after VRAM lost, can you illustrate what rule KMD should obey to check in KMS IOCTL like cs_sumbit ?? let’s see which way better From: Haehnle, Nicolai Sent: Wednesday, October 11, 2017 4:41 PM To: L

<    1   2   3   4   5   6   7   8   >