Re: Changes to let KFD use render node VMs

Hi Felix, patch #3 looks good to me in general, but why do you need to cache the pd_phys_addr? The BO already does that anyway, so you can just use amdgpu_bo_gpu_addr() for this which also makes some additional checks on debug builds. patch #5 well mixing power management into the VM

Re: Changes to let KFD use render node VMs

Am 02.03.2018 um 07:59 schrieb zhoucm1: On 2018年03月02日 14:19, Kuehling, Felix wrote: Hi David, Compute contexts enable the compute power profile, I heard from Rex, he said he prefer power profile depends on ring busy/idle, rather than always enable it. and can use a different VM update

Re: Changes to let KFD use render node VMs

On 2018年03月02日 14:19, Kuehling, Felix wrote: Hi David, Compute contexts enable the compute power profile, I heard from Rex, he said he prefer power profile depends on ring busy/idle, rather than always enable it. and can use a different VM update mode from graphics contexts (SDMA vs.

Re: Changes to let KFD use render node VMs

Hi David, Compute contexts enable the compute power profile, and can use a different VM update mode from graphics contexts (SDMA vs. CPU). These differences are not going away. Not yet, anyway. If we start sharing VM address space between graphics and compute in the future, this will have to

[PATCH] Revert "drm/amdgpu: use polling mem to set SDMA3 wptr for VF"

This reverts commit 2ffe31deb27579e2f2c9444e01f4d8abf385d145. The sdma wptr poll memomy doesn't have the same efficiency as doorbell, and it will make sdma hang when running tests. Change-Id: I6e334430b309b0c21aa18a08764320c7ff51e353 Signed-off-by: Emily Deng ---

Re: Changes to let KFD use render node VMs

Hi Felix, Out of patches, Could I ask what the difference of AMDGPU_VM_CONTEXT_COMPUTE/GFX is? After you merge kfd_vm to amdgpu_vm, does the difference still exist? Thanks, David Zhou On 2018年03月02日 06:58, Felix Kuehling wrote: Hi Christian, I have a working patch series against

RE: [PATCH] drm/amdgpu: use separate status for buffer funcs availability v2

Patch#1 is Reviewed-by: Chunming Zhou Patch#2~#4 are Acked-by: Chunming zhou -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Thursday, March 01, 2018 7:53 PM To:

Changes to let KFD use render node VMs

Hi Christian, I have a working patch series against amd-kfg-staging that lets KFD use VMs from render node FDs, as we discussed. There are two patches in that series that touch amdgpu_vm.[ch] that I'd like your feedback on before I commit the changes to amd-kfd-staging and include them in my

Re: [PATCH v2] drm/amd/display: add per pipe dppclk

On Thu, Mar 1, 2018 at 3:04 PM, Harry Wentland wrote: > From: Dmytro Laktyushkin > > v2: Fix commit title > > Signed-off-by: Dmytro Laktyushkin > Reviewed-by: Tony Cheng > Acked-by: Harry

[PATCH v2] drm/amd/display: add per pipe dppclk

From: Dmytro Laktyushkin v2: Fix commit title Signed-off-by: Dmytro Laktyushkin Reviewed-by: Tony Cheng Acked-by: Harry Wentland --- drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c

[PATCH v2] drm/amd/display: Use 4096 lut entries

From: "Leo (Sunpeng) Li" Points in the DRM LUT are spaced linearly. Points in hardware are spaced exponentially, with greater density towards 0. To maintain low-end accuracy in hardware when sampling the DRM LUT, more points are needed. However, X doesn't seem to play with

Re: [PATCH 04/33] drm/amd/display: Use 4096 lut entries

On 2018-02-27 11:44 AM, Michel Dänzer wrote: > On 2018-02-27 05:16 PM, Harry Wentland wrote: >> On 2018-02-27 11:08 AM, Michel Dänzer wrote: >>> On 2018-02-27 04:54 PM, Leo Li wrote: On 2018-02-27 05:34 AM, Michel Dänzer wrote: > On 2018-02-26 09:15 PM, Harry Wentland wrote: >> From:

Re: [PATCH] drm/amdgpu: try again kiq access if not in IRQ(v2)

On 2018-02-28 02:27 AM, Monk Liu wrote: > sometimes GPU is switched to other VFs and won't swich > back soon, so the kiq reg access will not signal within > a short period, instead of busy waiting a long time(MAX_KEQ_REG_WAIT) > and returning TMO we can istead sleep 5ms and try again > later (non

Re: [PATCH] drm/radeon/mkregtable: Delete unused list functions and macros

On Wed, Feb 28, 2018 at 2:17 PM, Matthias Kaehlcke wrote: > The util mkregtable includes a copy of the kernel API for linked lists, > only a small subset of it is used. Delete the unused functions and macros. > > Signed-off-by: Matthias Kaehlcke

Re: [PATCH xf86-video-amdgpu] fix include order for present.h configure test

On 2018-03-01 03:07 PM, Christoph Haag wrote: > xorg-server.h defines _XSERVER64 which is used in X.h to choose the > correct definition of XID > > this prevents a failure in the present.h configure test that disables > DRI3 on X.Org 1.20 For future patches you want to be applied, please include

Re: [PATCH] drm/amd/amdgpu: Mask rptr as well in ring debugfs

Am 01.03.2018 um 15:43 schrieb Tom St Denis: The read/write pointers on sdma4 devices increment beyond the ring size and should be masked. Tested on my Ryzen 2400G. Signed-off-by: Tom St Denis Reviewed-by: Christian König ---

Re: [PATCH] drm/amd/amdgpu: Mask rptr as well in ring debugfs

On Thu, Mar 1, 2018 at 9:43 AM, Tom St Denis wrote: > The read/write pointers on sdma4 devices increment > beyond the ring size and should be masked. Tested > on my Ryzen 2400G. > > Signed-off-by: Tom St Denis Reviewed-by: Alex Deucher

[PATCH] drm/amd/amdgpu: Mask rptr as well in ring debugfs

The read/write pointers on sdma4 devices increment beyond the ring size and should be masked. Tested on my Ryzen 2400G. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 4/4] drm/amdgpu: use separate status for buffer funcs availability

Am 01.03.2018 um 11:55 schrieb Liu, Monk: Looks aborting in such case is the safe way, otherwise the fence_wait() outside will still fail Good point, just send a v2 of that patch which does exactly that. Please review, Christian. -Original Message- From: Christian König

[PATCH] drm/amdgpu: use separate status for buffer funcs availability v2

The ring status can change during GPU reset, but we still need to be able to schedule TTM buffer moves in the meantime. Otherwise we can ran into problems because of aborted move/fill operations during GPU resets. v2: still check if ring is available during direct submit. Signed-off-by:

RE: [PATCH 4/4] drm/amdgpu: use separate status for buffer funcs availability

Looks aborting in such case is the safe way, otherwise the fence_wait() outside will still fail -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年3月1日 18:50 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH

Re: [PATCH 4/4] drm/amdgpu: use separate status for buffer funcs availability

Am 01.03.2018 um 11:33 schrieb Liu, Monk: int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma) @@ -1684,6 +1680,7 @@ int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t src_offset, amdgpu_ring_pad_ib(ring, >ibs[0]); WARN_ON(job->ibs[0].length_dw > num_dw);

RE: [PATCH 4/4] drm/amdgpu: use separate status for buffer funcs availability

> int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma) @@ -1684,6 > +1680,7 @@ int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t > src_offset, amdgpu_ring_pad_ib(ring, >ibs[0]); WARN_ON(job->ibs[0].length_dw > num_dw); if (direct_submit) { +

[PATCH 2/4] drm/amdgpu: change amdgpu_ttm_set_active_vram_size

Instead of setting the active VRAM size directly provide a the info if we can use the buffer functions or not. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 23 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 ++-

Re: [PATCH libdrm] tests/amdgpu: Fix misspellings of "suite"

Am 01.03.2018 um 11:17 schrieb Michel Dänzer: From: Michel Dänzer Signed-off-by: Michel Dänzer Acked-by: Christian König --- tests/amdgpu/amdgpu_test.c | 12 ++-- tests/amdgpu/amdgpu_test.h | 12

[PATCH 4/4] drm/amdgpu: use separate status for buffer funcs availability

The ring status can change during GPU reset, but we still need to be able to schedule TTM buffer moves in the meantime. Otherwise we can ran into problems because of aborted move/fill operations during GPU resets. Signed-off-by: Christian König ---

[PATCH 1/4] drm/amdgpu: move some functions into amdgpu_ttm.h

Those belong to the TTM handling. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h

[PATCH libdrm] tests/amdgpu: Fix misspellings of "suite"

From: Michel Dänzer Signed-off-by: Michel Dänzer --- tests/amdgpu/amdgpu_test.c | 12 ++-- tests/amdgpu/amdgpu_test.h | 12 ++-- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/tests/amdgpu/amdgpu_test.c

Re: [PATCH libdrm] test/amdgpu: disable bo eviction test by default

Am 01.03.2018 um 11:10 schrieb Chunming Zhou: if some system hase no swap space and memory is less, than the test could fail. And bo eviction test takes much more time in some system, which effects automation test result and efficiency. So disable it by default now, only be used by developer

[PATCH libdrm] test/amdgpu: disable bo eviction test by default

if some system hase no swap space and memory is less, than the test could fail. And bo eviction test takes much more time in some system, which effects automation test result and efficiency. So disable it by default now, only be used by developer manually. Signed-off-by: Chunming Zhou

Re: [PATCH libdrm] Revert "tests/amdgpu: add bo eviction test"

On 2018-03-01 10:55 AM, zhoucm1 wrote: > Yes, Michel also pointed that, will do that. Though based on Christian's earlier feedback, maybe you should rather just explicitly disable it in the automation where it's causing trouble. -- Earthling Michel Dänzer |

Re: [PATCH] drm/amdgpu: try again kiq access if not in IRQ(v3)

Am 01.03.2018 um 10:24 schrieb Monk Liu: sometimes GPU is switched to other VFs and won't swich back soon, so the kiq reg access will not signal within a short period, instead of busy waiting a long time(MAX_KEQ_REG_WAIT) and returning TMO we can istead sleep 5ms and try again later (non irq

Re: [PATCH libdrm] Revert "tests/amdgpu: add bo eviction test"

Andrey worked on this, he should know that of hand. Christian. Am 01.03.2018 um 10:43 schrieb zhoucm1: On 2018年03月01日 17:40, Christian König wrote: Am 01.03.2018 um 10:37 schrieb Chunming Zhou: if some system hase no swap space and memory is less, than the test could fail. And bo eviction

Re: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

Look for amdgpu_ttm_set_active_vram_size(), setting ring->ready to false is directly beneath it. Christian. Am 01.03.2018 um 10:41 schrieb Liu, Monk: Oops, looks only si will call this dma_stop() during hw_fini, I checked for sdma4.0/3.0/2.4, no such logic -Original Message- From:

Re: [PATCH libdrm] Revert "tests/amdgpu: add bo eviction test"

On 2018-03-01 10:37 AM, Chunming Zhou wrote: > if some system hase no swap space and memory is less, than the test > could fail. > And bo eviction test takes much more time in some system, which effects > automation test result and efficiency. > So revert it now, only can be used by developer

Re: [PATCH libdrm] Revert "tests/amdgpu: add bo eviction test"

On 2018年03月01日 17:40, Christian König wrote: Am 01.03.2018 um 10:37 schrieb Chunming Zhou: if some system hase no swap space and memory is less, than the test could fail. And bo eviction test takes much more time in some system, which effects automation test result and efficiency. So revert

RE: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

Oops, looks only si will call this dma_stop() during hw_fini, I checked for sdma4.0/3.0/2.4, no such logic -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年3月1日 17:39 To: Liu, Monk ; Koenig, Christian

Re: [PATCH libdrm] Revert "tests/amdgpu: add bo eviction test"

Am 01.03.2018 um 10:37 schrieb Chunming Zhou: if some system hase no swap space and memory is less, than the test could fail. And bo eviction test takes much more time in some system, which effects automation test result and efficiency. So revert it now, only can be used by developer manually.

Re: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

Hi Monk, look at si_dma_stop() and/or other SDMA generation code. Regards, Christian. Am 01.03.2018 um 10:37 schrieb Liu, Monk: Hi Christian During suspend/resume, which stage will set sdma's ring->ready to false ?? I can only find it in amdgpu_ring_fini() But I saw that it is only invoked

[PATCH] drm/amdgpu: try again kiq access if not in IRQ(v3)

sometimes GPU is switched to other VFs and won't swich back soon, so the kiq reg access will not signal within a short period, instead of busy waiting a long time(MAX_KEQ_REG_WAIT) and returning TMO we can istead sleep 5ms and try again later (non irq context) And since the waiting in kiq_r/weg

[PATCH libdrm] Revert "tests/amdgpu: add bo eviction test"

if some system hase no swap space and memory is less, than the test could fail. And bo eviction test takes much more time in some system, which effects automation test result and efficiency. So revert it now, only can be used by developer manually. This reverts commit

RE: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

Hi Christian During suspend/resume, which stage will set sdma's ring->ready to false ?? I can only find it in amdgpu_ring_fini() But I saw that it is only invoked in unload_kms(), looks device_suspnd() will not set ring->ready to false /Monk -Original Message- From: amd-gfx

Re: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

Even for bare-metal changing the VRAM size in the memory manager because we disable/enable the SDMA during GPU reset is quite a bug. Going to work on this, a correct fix should actually be really trivial. Regards, Christian. Am 01.03.2018 um 10:25 schrieb Liu, Monk: Okay I missed the part of

RE: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

Okay I missed the part of suspend/resume/s3 For SRIOV we don't run into that logic, looks I need to keep it in private branch till A better solution raised /Monk -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu, Monk Sent: 2018年3月1日

RE: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

> amdgpu_evict_flags() and amdgpu_bo_move() needs to know if the SDMA ring is > available during suspend/resume. As long as we are in gpu reset, we don't return error when ring not ready, cuz eventually it either success or failed and rescheduled by scheduler since it is kernel job What's your

Re: [PATCH] drm/amdgpu: try again kiq access if not in IRQ(v2)

Sounds reasonable. I would add a define for the 5ms timeout, with that done the patch is Reviewed-by: Christian König as well. Regards, Christian. Am 01.03.2018 um 09:40 schrieb Ding, Pixel: Reviewed-by: Pixel Ding — Sincerely Yours, Pixel

Re: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

If we are in gpu rest stage, we can let SDMA job live with the case of ring not ready, can you point out where is the problem ? amdgpu_evict_flags() and amdgpu_bo_move() needs to know if the SDMA ring is available during suspend/resume. E.g. suspend works as this: 1. Evict all normal BOs

Re: [PATCH] drm/amdgpu: try again kiq access if not in IRQ(v2)

Reviewed-by: Pixel Ding — Sincerely Yours, Pixel On 01/03/2018, 4:21 PM, "amd-gfx on behalf of Liu, Monk" wrote: Hi Christian KIQ is used by kernel, and we submit commands on it without

RE: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

Accel_working is only for GFX ring, I don't think test it is appropriate for SDMA jobs If we are in gpu rest stage, we can let SDMA job live with the case of ring not ready, can you point out where is the problem ? In fact we did stress TDR test with this patch and it can really fix

RE: [PATCH] drm/amdgpu: try again kiq access if not in IRQ(v2)

Hi Christian KIQ is used by kernel, and we submit commands on it without gpu scheduler, In sriov env, register access must go through KIQ in non-exclusive mode because we don’t want one VF access MMIO during the period that this VF is not occupying GPU resource, But since now we use busy

Re: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for fill_buffer

Ah, crap yeah that won't work since we don't free the ring. Key point is we need to distinct between the ring doesn't work temporary because we are in a GPU reset and it doesn't work at all because we are missing firmware or stuff like that. And no, checking the gpu_reset flag is totally

Re: [PATCH] drm/amdgpu: try again kiq access if not in IRQ(v2)

From a coding style perspective a define for the 5ms timeout would be nice to have and it might be better to use a do { } while instead of the goto, but those are really minor issues. But from the technical perspective I can't fully judge if that is a good idea or not cause I'm not so deeply

Re: [PATCH] drm/amdgpu: used cached pcie gen info for SI (v2)

Am 01.03.2018 um 03:04 schrieb Alex Deucher: Rather than querying it every time we need it. Also fixes a crash in VM pass through if there is no root bridge because the cached value fetch already checks this properly. v2: fix includes Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105244