Re: [PATCH 3/3] drm/amdgpu: Fix multi-level page table bugs for large BOs

Am 29.03.2017 um 07:58 schrieb Zhang, Jerry (Junwei): Hi Felix, Thanks for your illustration with patience. I got your meaning then, and thanks to fix that. > I think you're right, there are some extra high bits in saddr and eaddr, but > they get discarded by the modulo-division in the next re

Re: [PATCH 2/3] drm/amdgpu: Fix Vega10 VM initialization

Am 29.03.2017 um 03:48 schrieb Felix Kuehling: On 17-03-28 09:39 PM, Zhang, Jerry (Junwei) wrote: On 03/29/2017 09:00 AM, Felix Kuehling wrote: adev->family is not initialized yet when amdgpu_get_block_size is called. Use adev->asic_type instead. Minimum VM size is 512GB, not 256GB, for a sing

Re: [PATCH 1/3] drm/amdgpu: Make max_pfn 64-bit

Am 29.03.2017 um 03:00 schrieb Felix Kuehling: With 4-level page tables the maximum VM size is 256TB. That's 64G pages, which can't be represented in 32-bit. Signed-off-by: Felix Kuehling Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++-- drivers/gpu/drm

Re: [PATCH v2] drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)

On 29/03/17 01:02 PM, r...@ubuntu.com wrote: > From: Christopher James Halse Rogers > > Any use of the framebuffer will migrate it to VRAM, which is not sensible for > an imported dma-buf. > > v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. > > Signed-off-by: Christopher

Re: [PATCH 0/3] Fixes for multi-level page tables

On 03/29/2017 09:00 AM, Felix Kuehling wrote: I worked on these fixes on amd-kfd-staging with a merge of the recent multi- level page table changes. With these changes KFDTest passes on Vega10, including some tests that tend to stress VM memory management. They applied cleanly to current amd-sta

Re: [PATCH 3/3] drm/amdgpu: Fix multi-level page table bugs for large BOs

Hi Felix, Thanks for your illustration with patience. I got your meaning then, and thanks to fix that. > I think you're right, there are some extra high bits in saddr and eaddr, but > they get discarded by the modulo-division in the next recursion level. For > added clarity the modulo division (

[PATCH v2] drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)

From: Christopher James Halse Rogers Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Signed-off-by: Christopher James Halse Rogers CC: amd-gfx@lists.freedesktop.org ---

[PATCH v2] drm/radeon: Fail fb creation from imported dma-bufs.

From: Christopher James Halse Rogers Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Signed-off-by: Christopher James Halse Rogers CC: amd-gfx@lists.freedesktop.org ---

Re: [PATCH 3/6] drm/amdgpu: Fail fb creation from imported dma-bufs.

On Wed, 29 Mar 2017 at 13:04 Michel Dänzer wrote: > On 29/03/17 09:27 AM, r...@ubuntu.com wrote: > > From: Christopher James Halse Rogers < > christopher.halse.rog...@canonical.com> > > > > Any use of the framebuffer will migrate it to VRAM, which is not > sensible for > > an imported dma-buf. >

Re: [PATCH 3/3] drm/amdgpu: Fix multi-level page table bugs for large BOs

Hi Jerry, Let me clarify my understanding of the problem and the intention of the fix. Address range per page: 4KB Address range per PT (level 3): 2MB Address range per PD (level 2): 1GB Address range per PD (level 1): 512GB Address range per PD (level 0): 256TB Imagine for example a mapping tha

Re: [PATCH 2/3] drm/amdgpu: Fix Vega10 VM initialization

On 03/29/2017 09:48 AM, Felix Kuehling wrote: On 17-03-28 09:39 PM, Zhang, Jerry (Junwei) wrote: On 03/29/2017 09:00 AM, Felix Kuehling wrote: adev->family is not initialized yet when amdgpu_get_block_size is called. Use adev->asic_type instead. Minimum VM size is 512GB, not 256GB, for a singl

Re: [PATCH 3/3] drm/amdgpu: Fix multi-level page table bugs for large BOs

On 03/29/2017 09:00 AM, Felix Kuehling wrote: Fix the start/end address calculation for address ranges that span multiple page directories in amdgpu_vm_alloc_levels. Add WARN_ONs if page tables aren't found. Otherwise the page table update would just fail silently. Signed-off-by: Felix Kuehling

Re: [PATCH 0/3] Fixes for multi-level page tables

Reviewed-by: Chunming Zhou for the series. Especially nice for sub level saddr/eaddr calculation. Regards, David Zhou On 2017年03月29日 09:00, Felix Kuehling wrote: I worked on these fixes on amd-kfd-staging with a merge of the recent multi- level page table changes. With these changes KFDTest p

Re: [PATCH 3/6] drm/amdgpu: Fail fb creation from imported dma-bufs.

On 29/03/17 09:27 AM, r...@ubuntu.com wrote: > From: Christopher James Halse Rogers > > Any use of the framebuffer will migrate it to VRAM, which is not sensible for > an imported dma-buf. > > Signed-off-by: Christopher James Halse Rogers > > CC: amd-gfx@lists.freedesktop.org > --- > drivers/

Re: [PATCH 4/6] drm/amd/amdgpu: Pin bos from imported dma-bufs to GTT.

On 29/03/17 09:27 AM, r...@ubuntu.com wrote: > From: Christopher James Halse Rogers > > Attempting to migrate the bo will break the sharing of the buffer. > > Signed-off-by: Christopher James Halse Rogers > > CC: amd-gfx@lists.freedesktop.org > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c

Re: [PATCH] drm/amd/amdgpu: fix Tonga S3 resume hang on rhel6.8

On 03/28/2017 05:27 PM, Jim Qu wrote: 1. security firmware loading has moved to sw init, so this code is useless. 2. it seems that driver could not call request_firmware on kernel 2.6, when S3 resume. for request firmware depends on userspace, at this time, userspace is freeze. Just

Re: [PATCH] drm/amdgpu: Fix 32bit x86 compilation warning

On 03/29/2017 02:37 AM, Alex Xie wrote: drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c:187:2: warning: right shift count >= width of type [enabled by default] drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c:173:2: warning: right shift count >= width of type [enabled by default] drivers/gpu/drm/amd/amdgpu/ve

Re: [PATCH 2/3] drm/amdgpu: Fix Vega10 VM initialization

On 17-03-28 09:39 PM, Zhang, Jerry (Junwei) wrote: > On 03/29/2017 09:00 AM, Felix Kuehling wrote: >> adev->family is not initialized yet when amdgpu_get_block_size is >> called. Use adev->asic_type instead. >> >> Minimum VM size is 512GB, not 256GB, for a single page table entry >> in the root pag

Re: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling

On 03/29/2017 09:37 AM, Felix Kuehling wrote: Sorry, I pushed it already, just with Alex's R-B. That's fine. Take it easy :) Jerry Thanks, Felix On 17-03-28 09:28 PM, Zhang, Jerry (Junwei) wrote: On 03/29/2017 02:37 AM, Deucher, Alexander wrote: -Original Message- From: amd-g

Re: [PATCH 2/3] drm/amdgpu: Fix Vega10 VM initialization

On 03/29/2017 09:00 AM, Felix Kuehling wrote: adev->family is not initialized yet when amdgpu_get_block_size is called. Use adev->asic_type instead. Minimum VM size is 512GB, not 256GB, for a single page table entry in the root page table. gmc_v9_0_vm_init is called after adev->vm_manager.max_p

Re: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling

Sorry, I pushed it already, just with Alex's R-B. Thanks, Felix On 17-03-28 09:28 PM, Zhang, Jerry (Junwei) wrote: > On 03/29/2017 02:37 AM, Deucher, Alexander wrote: >>> -Original Message- >>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf >>> Of Felix Kuehling

Re: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling

On 03/29/2017 02:37 AM, Deucher, Alexander wrote: -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Felix Kuehling Sent: Tuesday, March 28, 2017 2:10 PM To: Zhang, Jerry; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: Improve Vega

[PATCH 2/3] drm/amdgpu: Fix Vega10 VM initialization

adev->family is not initialized yet when amdgpu_get_block_size is called. Use adev->asic_type instead. Minimum VM size is 512GB, not 256GB, for a single page table entry in the root page table. gmc_v9_0_vm_init is called after adev->vm_manager.max_pfn is initialized. Move the minimum VM-size enfo

[PATCH 0/3] Fixes for multi-level page tables

I worked on these fixes on amd-kfd-staging with a merge of the recent multi- level page table changes. With these changes KFDTest passes on Vega10, including some tests that tend to stress VM memory management. They applied cleanly to current amd-staging-4.9 but are only compile-tested on that bra

[PATCH 3/3] drm/amdgpu: Fix multi-level page table bugs for large BOs

Fix the start/end address calculation for address ranges that span multiple page directories in amdgpu_vm_alloc_levels. Add WARN_ONs if page tables aren't found. Otherwise the page table update would just fail silently. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |

[PATCH 1/3] drm/amdgpu: Make max_pfn 64-bit

With 4-level page tables the maximum VM size is 256TB. That's 64G pages, which can't be represented in 32-bit. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 5 +++--

答复: [PATCH] drm/amdgpu: refine the logic in amdgpu_need_post()

Reviewed-by: Jim Qu Thanks JimQu 发件人: amd-gfx 代表 Alex Deucher 发送时间: 2017年3月29日 0:21 收件人: amd-gfx@lists.freedesktop.org 抄送: Deucher, Alexander 主题: [PATCH] drm/amdgpu: refine the logic in amdgpu_need_post() We check the mem config register to make sure

[PATCH 4/6] drm/amd/amdgpu: Pin bos from imported dma-bufs to GTT.

From: Christopher James Halse Rogers Attempting to migrate the bo will break the sharing of the buffer. Signed-off-by: Christopher James Halse Rogers CC: amd-gfx@lists.freedesktop.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 11 +++ 1 file changed, 11 insertions(+) diff --git

[PATCH 6/6] drm/radeon: Pin bos from imported dma-bufs to GTT.

From: Christopher James Halse Rogers Attempting to migrate the bo will break the sharing of the buffer. Signed-off-by: Christopher James Halse Rogers CC: amd-gfx@lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_prime.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/dri

[PATCH 3/6] drm/amdgpu: Fail fb creation from imported dma-bufs.

From: Christopher James Halse Rogers Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. Signed-off-by: Christopher James Halse Rogers CC: amd-gfx@lists.freedesktop.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++ 1 file changed, 6

[PATCH 5/6] drm/radeon: Fail fb creation from imported dma-bufs.

From: Christopher James Halse Rogers Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. Signed-off-by: Christopher James Halse Rogers CC: amd-gfx@lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_display.c | 6 ++ 1 file changed, 6 ins

[PATCH 12/12] drm/amd/display: obtain usHBR3En bit from BP 1

From: Ding Wang ASICs using bios parser 1 don't check HBR3 capability as there is no such a bit usHBR3En in ATOM_ENCODER_CAP_RECORDER. Therefore, will use ATOM_ENCODER_CAP_RECORDER_V2 and thus obtain the usHBR3En bit. Change-Id: I05e3fa6bfcbe9e55cb3ea2ff736dfc3c0b1b8a9f Signed-off-by: Ding Wang

[PATCH 11/12] drm/amd/display: stereo support

From: Vitaly Prosyak Frame sequential, top-bottom and side-by-side support. Change-Id: Iea9193028af358d66d5011f9a9971ce405603de7 Signed-off-by: Vitaly Prosyak Acked-by: Harry Wentland Reviewed-by: Tony Cheng --- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 34 +--

[PATCH 02/12] drm/amd/display: Add audio/video ContainerId implementation

From: xhdu Leave hardcoded if no ContainerId provided by DM. Change-Id: Ifb1639992a771f08c3b57ee09d11cc3ac8f8dfd2 Signed-off-by: Duke Du Acked-by: Harry Wentland Reviewed-by: Charlene Liu --- drivers/gpu/drm/amd/display/dc/core/dc_sink.c | 39 - drivers/gpu/drm/amd/

[PATCH 08/12] drm/amd/display: increase timeout for dmif dealloc

From: Roman Li In some use-cases, e.g. multiple 4K displays, exisitng wait time for reg update of 30msec timed out during mode setiing that sometimes resulted in system bad state as we continue without waiting for registry update complete. Increasing timeout to 35msec fixes that problem. Change-

[PATCH 10/12] drm/amd/display: use CP2520-3 for PHY compliance automation

From: Tony Cheng Change-Id: Ida1e78b4785adc6b1362d57c436797d5e37185ee Signed-off-by: Tony Cheng Acked-by: Harry Wentland Reviewed-by: Hersen Wu --- drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c| 3 +++ drivers/gpu/drm/amd/display/include/link_service_types.h | 2 +- 2 files change

[PATCH 04/12] drm/amd/display: Rename bandwidth_calcs.h to dce_calcs.h

Change-Id: I58faa0924c573d23a75a9ef33e7f58e10afdac31 Signed-off-by: Harry Wentland Acked-by: Harry Wentland Reviewed-by: Tony Cheng --- drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 2 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +- drivers/gpu

[PATCH 03/12] drm/amd/display: Power on front end during set mode.

From: Yongqiang Sun Change-Id: If307b84716d2bb8e5035a410398f4c40982418da Signed-off-by: Yongqiang Sun Acked-by: Harry Wentland Reviewed-by: Tony Cheng --- drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 3 +++ drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h | 5 +

[PATCH 01/12] drm/amd/display: using calculated values for VReady/Startup

From: Charlene Liu Change-Id: I23ebcf87fab296f94930bcfdd9e2851398e9d161 Signed-off-by: Charlene Liu Acked-by: Harry Wentland Reviewed-by: Dmytro Laktyushkin --- drivers/gpu/drm/amd/display/dc/dc_hw_types.h | 9 + drivers/gpu/drm/amd/display/dc/dm_services_types.h | 2

[PATCH 00/12] DC Patches Mar 28, 2017

* Switching to CRTC_VERTICAL_INTERRUPT for vblank notifications. This should resolve some problems with frame time that were observed by haagch and Evillina * Fix for dmif timeout that was getting hit constantly and caused issues on some systems * Bunch of other fixes and rework Andrey Grodz

[PATCH 07/12] drm/amd/display: voltage request related change

From: Charlene Liu Change-Id: I8700420838f9038a00d3db7be5810c04f32f3b94 Signed-off-by: Charlene Liu Acked-by: Harry Wentland Reviewed-by: Krunoslav Kovac --- .../gpu/drm/amd/display/dc/dce/dce_clock_source.c | 1 + drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c| 27 +++-

[PATCH 09/12] drm/amd/display: Fix MPO exit and cursor issue.

From: Yongqiang Sun Change-Id: Idaa862166c069adba8ce034143851fab3b01a781 Signed-off-by: Yongqiang Sun Acked-by: Harry Wentland Reviewed-by: Tony Cheng --- drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 5 - drivers/gpu/drm/amd/display/dc/dc.h | 2 +- 2 files changed, 5 inse

[PATCH 06/12] drm/amd/display: use CRTC_VERTICAL_INTERRUPT0 as a trigger for VBLANK.

From: Andrey Grodzovsky Register ISR hnadler on the new interrupt. Change-Id: Ib934f2197b8b58a9534b53b102d8f0be5e97a43c Signed-off-by: Andrey Grodzovsky Acked-by: Harry Wentland Reviewed-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- 1 file changed, 1 in

[PATCH 05/12] drm/amd/display: use CRTC_VERTICAL_INTERRUPT0 as VBLANK trigger.

From: Andrey Grodzovsky VBLANK interrupt is driven bu line buffer vcounter which is ahead of CRTC vcounter. Use an interrupt that fires at the actual CRTC vblank start boundry. Change-Id: I2d397447e105137451c966ddfc73f533f0d8bc4b Signed-off-by: Andrey Grodzovsky Acked-by: Harry Wentland Review

[PATCH 2/2] drm/amdgpu: use LRU mapping policy for SDMA engines

Spreading the load across multiple SDMA engines can increase memory transfer performance. Signed-off-by: Andres Rodriguez --- drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c b/drivers

[PATCH 1/2] drm/amdgpu: guarantee bijective mapping of ring ids for LRU v3

Depending on usage patterns, the current LRU policy may create a non-injective mapping between userspace ring ids and kernel rings. This behaviour is undesired as apps that attempt to fill all HW blocks would be unable to reach some of them. This change forces the LRU policy to create bijective m

Use LRU mapping policy for SDMA engines v3

Previously we discussed some issues with applying the LRU mapping policy to the SDMA engines. Mainly, if both ring ids end up aliased to the same HW block, the total transfer bandwith an application can achieve will be severely impacted. E.g. an app uses one SDMA ring for upload and one for downloa

Re: Multilevel page tables broken for high addresses

On 17-03-28 04:25 PM, Deucher, Alexander wrote: > Simple KFD tests that don't use the non-coherent (high) address range > > seem to be working fine. That tells me that the multi-level page table > > code has a problem with high addresses. > > > > I'll keep digging ... > > Do you have multiple GPUs

RE: Multilevel page tables broken for high addresses

> -Original Message- > From: Kuehling, Felix > Sent: Tuesday, March 28, 2017 4:15 PM > To: amd-gfx@lists.freedesktop.org; Koenig, Christian; Zhou, > David(ChunMing); Deucher, Alexander > Cc: Russell, Kent > Subject: Multilevel page tables broken for high addresses > > It looks like the mul

RE: [PATCH] drm/amdgpu: Fix 32bit x86 compilation warning

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Alex Xie > Sent: Tuesday, March 28, 2017 2:37 PM > To: amd-gfx@lists.freedesktop.org > Cc: Xie, AlexBin > Subject: [PATCH] drm/amdgpu: Fix 32bit x86 compilation warning > > drivers/gpu/drm/am

[PATCH] drm/amdgpu: Fix 32bit x86 compilation warning

drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c:187:2: warning: right shift count >= width of type [enabled by default] drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c:173:2: warning: right shift count >= width of type [enabled by default] drivers/gpu/drm/amd/amdgpu/vega10_ih.c:106:3: warning: right shift count

Multilevel page tables broken for high addresses

It looks like the multi-level page table changes have been submitted. They're causing problems when we're trying to integrate them into our KFD branch. We resolved the obvious changes and it's working on older ASICs without problems. But we're getting hangs on Vega10. With my patch to enable UTCL2

RE: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Felix Kuehling > Sent: Tuesday, March 28, 2017 2:10 PM > To: Zhang, Jerry; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling > > > On 17-03-27

Re: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling

On 17-03-27 09:23 PM, Zhang, Jerry (Junwei) wrote: > > > On 03/28/2017 06:25 AM, Felix Kuehling wrote: >> Register AMDGPU_IH_CLIENTID_UTCL2 as a source of VM faults. Clean >> up the VM fault message format and use rate-limiting similar to >> other ASICs. >> >> Signed-off-by: Felix Kuehling > > Ma

Re: [PATCH] drm/amdgpu: refine the logic in amdgpu_need_post()

Am 28.03.2017 um 18:21 schrieb Alex Deucher: We check the mem config register to make sure it's been programmed by the vbios to determine if we need to post so we check for a non-0 value. However, when the asic comes out of reset, we may see all ones here, so check for that too. Signed-off-by:

[PATCH] drm/amdgpu: refine the logic in amdgpu_need_post()

We check the mem config register to make sure it's been programmed by the vbios to determine if we need to post so we check for a non-0 value. However, when the asic comes out of reset, we may see all ones here, so check for that too. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/a

RE: [PATCH] drm/amdgpu: Couple small warning fixes

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Harry Wentland > Sent: Tuesday, March 28, 2017 11:32 AM > To: amd-gfx@lists.freedesktop.org > Cc: Wentland, Harry > Subject: [PATCH] drm/amdgpu: Couple small warning fixes > > Signed-off-by:

Re: [PATCH] drm/amdgpu: Couple small warning fixes

Am 28.03.2017 um 17:31 schrieb Harry Wentland: Signed-off-by: Harry Wentland Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd

[PATCH] drm/amdgpu: Couple small warning fixes

Signed-off-by: Harry Wentland --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 355e17ac6d27..dde1

Re: [PATCH 2/2] drm/amdgpu: use LRU mapping policy for SDMA engines

On 28.03.2017 00:36, Andres Rodriguez wrote: Spreading the load across multiple SDMA engines can increase memory transfer performance. Signed-off-by: Andres Rodriguez Reviewed-by: Nicolai Hähnle --- drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 d

Re: [PATCH 1/2] drm/amdgpu: guarantee bijective mapping of ring ids for LRU

On 28.03.2017 00:36, Andres Rodriguez wrote: Depending on usage patterns, the current LRU policy may create a non-injective mapping between userspace ring ids and kernel rings. This behaviour is undesired as apps that attempt to fill all HW blocks would be unable to reach some of them. This cha

RE: [PATCH] drm/amdgpu: fix vm pte pde flags to 64-bit for sdma v4

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Junwei Zhang > Sent: Tuesday, March 28, 2017 4:56 AM > To: amd-gfx@lists.freedesktop.org > Cc: Zhang, Jerry > Subject: [PATCH] drm/amdgpu: fix vm pte pde flags to 64-bit for sdma v4 > > Signe

RE: [PATCH 2/2] drm/amd/amdgpu: decrease ttm bo priority number

> -Original Message- > From: Roger.He [mailto:hongbo...@amd.com] > Sent: Monday, March 27, 2017 9:52 PM > To: amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander; He, Hongbo > Subject: [PATCH 2/2] drm/amd/amdgpu: decrease ttm bo priority number Patch title should be: drm/ttm: decrease t

RE: [PATCH 1/2] drm/amd/amdgpu: fix performance drop when VRAM pressure

> -Original Message- > From: Roger.He [mailto:hongbo...@amd.com] > Sent: Monday, March 27, 2017 9:52 PM > To: amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander; He, Hongbo > Subject: [PATCH 1/2] drm/amd/amdgpu: fix performance drop when VRAM > pressure > > When VRAM pressue and trigge

Re: Plan: BO move throttling for visible VRAM evictions

Am 28.03.2017 um 15:58 schrieb Alex Deucher: On Tue, Mar 28, 2017 at 4:29 AM, Christian König wrote: Am 28.03.2017 um 08:00 schrieb Michel Dänzer: On 28/03/17 12:50 PM, zhoucm1 wrote: On 2017年03月28日 10:40, Michel Dänzer wrote: On 27/03/17 04:53 PM, Zhou, David(ChunMing) wrote: For APU speci

Re: Plan: BO move throttling for visible VRAM evictions

On Tue, Mar 28, 2017 at 4:29 AM, Christian König wrote: > Am 28.03.2017 um 08:00 schrieb Michel Dänzer: >> >> On 28/03/17 12:50 PM, zhoucm1 wrote: >>> >>> On 2017年03月28日 10:40, Michel Dänzer wrote: On 27/03/17 04:53 PM, Zhou, David(ChunMing) wrote: > > For APU special case, can w

Re: [PATCH 03/15] drm/amdgpu: add num_level to the VM manager

On 03/27/2017 12:53 AM, Chunming Zhou wrote: > From: Christian König > > Needs to be filled with handling. > > Change-Id: I04881a2b304a020c259ce85e94b12900a77f1c02 > Signed-off-by: Christian König > Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 + > drivers/gp

RE: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Felix Kuehling > Sent: Monday, March 27, 2017 6:25 PM > To: amd-gfx@lists.freedesktop.org > Cc: Kuehling, Felix > Subject: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling > > Register AM

[PATCH] drm/amdgpu: just disallow reading untouched registers

From: Christian König Not sure what the original intention was here, but returning a random piece of kernel memory to userspace because we didn't set the value at all is clearly not a good idea. This patch disallows reading the register and returns a proper error code instead. Signed-off-by: Ch

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

On 28 March 2017 at 10:36, Michel Dänzer wrote: > On 28/03/17 05:24 PM, Julien Isorce wrote: > > Hi Michel, > > > > About the hard lockup, I noticed that I cannot have it with the > > following conditions: > > > > 1. soft lockup fix (the 0->i change which avoids infinite loop) > > 2. Your suggest

Re: Plan: BO move throttling for visible VRAM evictions

On Mar 28, 2017 3:07 AM, "Michel Dänzer" wrote: On 27/03/17 07:29 PM, Marek Olšák wrote: > On Mar 27, 2017 9:35 AM, "Michel Dänzer" > wrote: > > On 25/03/17 01:33 AM, Marek Olšák wrote: > > Hi, > > > > I'm sharing this idea here, because it's something

Re: Plan: BO move throttling for visible VRAM evictions

On Mar 28, 2017 10:41 AM, "Christian König" wrote: Am 28.03.2017 um 10:35 schrieb Michel Dänzer: > On 28/03/17 05:29 PM, Christian König wrote: > >> Am 28.03.2017 um 08:00 schrieb Michel Dänzer: >> >>> On 28/03/17 12:50 PM, zhoucm1 wrote: >>> On 2017年03月28日 10:40, Michel Dänzer wrote:

Re: [PATCH] drm/amdgpu: fix memory leak in psp

On Tue, Mar 28, 2017 at 05:16:09PM +0800, Ken Wang wrote: > Change-Id: I6bea247f41ea405d11c1d75ca97b789f6970b191 > Signed-off-by: Ken Wang Reviewed-by: Huang Rui > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --gi

Re: [PATCH] drm/amd/amdgpu: fix Tonga S3 resume hang on rhel6.8

On Tue, Mar 28, 2017 at 05:27:54PM +0800, Jim Qu wrote: > 1. security firmware loading has moved to sw init, so this code >is useless. > 2. it seems that driver could not call request_firmware on >kernel 2.6, when S3 resume. for request firmware depends on >userspace, at this time, user

Re: [PATCH] drm/amdgpu: fix memory leak in psp

Am 28.03.2017 um 11:16 schrieb Ken Wang: Change-Id: I6bea247f41ea405d11c1d75ca97b789f6970b191 Signed-off-by: Ken Wang I don't know the PSP code to well, but that looks correct to me on first glance. Patch is Acked-by: Christian König . Regards, Christian. --- drivers/gpu/drm/amd/amdgpu

Re: [PATCH] drm/amdgpu: fix vm pte pde flags to 64-bit for sdma v4

Am 28.03.2017 um 10:55 schrieb Junwei Zhang: Signed-off-by: Junwei Zhang Good catch, patch is Reviewed-by: Christian König . It doesn't matter for older versions because they don't have flags in the high bits, but just for completeness could you fix this for them as well? Thanks, Christ

[PATCH] drm/amd/amdgpu: fix Tonga S3 resume hang on rhel6.8

1. security firmware loading has moved to sw init, so this code is useless. 2. it seems that driver could not call request_firmware on kernel 2.6, when S3 resume. for request firmware depends on userspace, at this time, userspace is freeze. Change-Id: I13977c60314ffe976924b1fdad1ab10df5d9

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

On 28/03/17 05:24 PM, Julien Isorce wrote: > Hi Michel, > > About the hard lockup, I noticed that I cannot have it with the > following conditions: > > 1. soft lockup fix (the 0->i change which avoids infinite loop) > 2. Your suggestion: (!(rbo->flags & RADEON_GEM_CPU_ACCESS) > 3. radeon.gartsize

[PATCH] drm/amdgpu: fix memory leak in psp

Change-Id: I6bea247f41ea405d11c1d75ca97b789f6970b191 Signed-off-by: Ken Wang --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c index 89d1d

[PATCH] drm/amdgpu: fix vm pte pde flags to 64-bit for sdma v4

Signed-off-by: Junwei Zhang --- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c index dcbef50..6cfb100 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.

答复: 答复: [PATCH 12/13] drm/amdgpu:changes in gfx DMAframe scheme

No sure what version of the code your are working with, but at least on amd-staging-4.9 the 128 NOPs are still present for GFX8. [ml] the following patch will remove the 128 NOPs after vm flush for gfx8 GFX7 uses the double switch buffer package and that can be removed if you add this in the vm_f

Re: Plan: BO move throttling for visible VRAM evictions

Am 28.03.2017 um 10:35 schrieb Michel Dänzer: On 28/03/17 05:29 PM, Christian König wrote: Am 28.03.2017 um 08:00 schrieb Michel Dänzer: On 28/03/17 12:50 PM, zhoucm1 wrote: On 2017年03月28日 10:40, Michel Dänzer wrote: On 27/03/17 04:53 PM, Zhou, David(ChunMing) wrote: For APU special case, ca

Re: [PATCH 13/15] drm/amdgpu: adapt vm size for multi vmpt

Am 28.03.2017 um 05:19 schrieb Zhang, Jerry (Junwei): On 03/27/2017 01:53 PM, Chunming Zhou wrote: Change-Id: I17b40aec68404e46961a9fda22dfadd1ae9d6f2c Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu

Re: Plan: BO move throttling for visible VRAM evictions

On 28/03/17 05:29 PM, Christian König wrote: > Am 28.03.2017 um 08:00 schrieb Michel Dänzer: >> On 28/03/17 12:50 PM, zhoucm1 wrote: >>> On 2017年03月28日 10:40, Michel Dänzer wrote: On 27/03/17 04:53 PM, Zhou, David(ChunMing) wrote: > For APU special case, can we prevent eviction happening b

Re: 答复: [PATCH 12/13] drm/amdgpu:changes in gfx DMAframe scheme

No sure what version of the code your are working with, but at least on amd-staging-4.9 the 128 NOPs are still present for GFX8. GFX7 uses the double switch buffer package and that can be removed if you add this in the vm_flush code. Additional to that you haven't answered why we need the con

Re: Plan: BO move throttling for visible VRAM evictions

Am 28.03.2017 um 08:00 schrieb Michel Dänzer: On 28/03/17 12:50 PM, zhoucm1 wrote: On 2017年03月28日 10:40, Michel Dänzer wrote: On 27/03/17 04:53 PM, Zhou, David(ChunMing) wrote: For APU special case, can we prevent eviction happening between VRAM <> GTT? We can, if we can close the perform

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, About the hard lockup, I noticed that I cannot have it with the following conditions: 1. soft lockup fix (the 0->i change which avoids infinite loop) 2. Your suggestion: (!(rbo->flags & RADEON_GEM_CPU_ACCESS) 3. radeon.gartsize=512 radeon.vramlimit=1024 (any other values above do not h

Re: [PATCH] drm/amdgpu: Improve Vega10 VM fault handling

Am 28.03.2017 um 03:23 schrieb Zhang, Jerry (Junwei): On 03/28/2017 06:25 AM, Felix Kuehling wrote: Register AMDGPU_IH_CLIENTID_UTCL2 as a source of VM faults. Clean up the VM fault message format and use rate-limiting similar to other ASICs. Signed-off-by: Felix Kuehling May be better to

Re: [PATCH 1/3] drm/amdgpu/gfx9: use hweight for calculating num_rbs

Am 27.03.2017 um 20:46 schrieb Alex Deucher: Match what we do for other asics. Signed-off-by: Alex Deucher Reviewed-by: Christian König for the whole set. --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm