[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

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(+)

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.

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 .

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,

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

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,

[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

[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:

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

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

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

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

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

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

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

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

[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 ---

答复: 答复: [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

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,

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: > >

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

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,

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

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

[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

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

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 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

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 > >

[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 ---

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 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 ---

[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:

[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 ---

[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:

[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

[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 ---

[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 +-

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

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

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

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.

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 >

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

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]

[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

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:

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

答复: [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

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

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

[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 ---

[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

[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

[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

[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 ---

[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

[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 ---

[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

[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|

[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 +-

[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

[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

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

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

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

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 > >

[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

[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

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

[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

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

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: Plan: BO move throttling for visible VRAM evictions

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 performance gap between VRAM and GTT. We