Re: [PATCH] drm/amdgpu: one pde of 4 levels at least 512GB

On 03/28/2017 11:46 AM, Chunming Zhou wrote: Change-Id: I9d764e6e6cf214e64bd79435a8bbb4063260dc11 Signed-off-by: Chunming Zhou Reviewed-by: Junwei Zhang For the minimum size, PD is 0 --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8 1 file

Re: Plan: BO move throttling for visible VRAM evictions

On 2017年03月27日 17:55, Christian König wrote: Am 27.03.2017 um 11:36 schrieb zhoucm1: On 2017年03月27日 17:29, Christian König wrote: On APUs I've already enabled using direct access to the stolen parts of system memory. Thanks, could you point me out where is doing this? See here

Re: Plan: BO move throttling for visible VRAM evictions

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 measured around 30% gap a while ago, though

[PATCH] drm/amdgpu: one pde of 4 levels at least 512GB

Change-Id: I9d764e6e6cf214e64bd79435a8bbb4063260dc11 Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c

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

Christian For the 128 NOPs after VM flush, already removed for gfx8 & 7 BR Monk -邮件原件- 发件人: Christian König [mailto:deathsim...@vodafone.de] 发送时间: Tuesday, March 28, 2017 12:17 AM 收件人: Liu, Monk ; amd-gfx@lists.freedesktop.org 主题: Re: [PATCH 12/13] drm/amdgpu:changes

Re: [PATCH 00/15] *** Multiple level VMPT enablement ***

On 03/28/2017 12:05 AM, Deucher, Alexander wrote: -Original Message- From: Koenig, Christian Sent: Monday, March 27, 2017 5:37 AM To: Zhou, David(ChunMing); amd-gfx@lists.freedesktop.org; Deucher, Alexander Subject: Re: [PATCH 00/15] *** Multiple level VMPT enablement *** Hi David,

Re: [PATCH 05/15] drm/amdgpu: handle multi level PD size calculation

On 03/27/2017 01:53 PM, Chunming Zhou wrote: From: Christian König Allows us to get the size for all levels as well. Change-Id: Iaf2f9b2bf19c3623018a2215f8cf01a61bdbe8ea Signed-off-by: Christian König Reviewed-by: Alex Deucher

Re: Plan: BO move throttling for visible VRAM evictions

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 measured around 30% gap a while ago, though right now I'm only measuring ~5%, but the test

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

When VRAM pressue and trigger huge evictions there is performance drop, this patch fix it. Change-Id: Idcd2db65be69d62bcbd7dfaa3bcf9bc964d6d122 Signed-off-by: Roger.He Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4

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

decrease and also reserve priority number for KFD using Change-Id: I9e36d292c920c034ddca53d0ec282c17b7a3cf16 Signed-off-by: Roger.He Reviewed-by: Christian König --- include/drm/ttm/ttm_bo_driver.h | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH libdrm] amdgpu: stop reading CC_RB_BACKEND_DISABLE on Vega10

On 03/27/2017 09:44 PM, Christian König wrote: From: Christian König Follow up to 'drm: don't access deprecated register on Vega10'. The same information is available in enabled_rb_pipes_mask and reading that register can cause GRBM bus problems. Signed-off-by:

Re: [PATCH] Fix a misspelling of 'acceleration' in amdgpu_kms.c

On 25/03/17 10:38 PM, Nicholas Molloy wrote: > --- > src/amdgpu_kms.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c > index 4821e93..c4ac90d 100644 > --- a/src/amdgpu_kms.c > +++ b/src/amdgpu_kms.c > @@ -1796,7 +1796,7 @@ Bool

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

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 split it into 2 patches

Re: [PATCH] drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags

On 27/03/17 06:33 PM, Julien Isorce wrote: > Hi Michel, > > Great ! Would you mind to just add a note to mention that the infinite > loop actually happens in ttm_bo_mem_force_space ? Thx! I'm afraid it might be too late, as I already pushed the fix to the amd-staging-4.9 branch. I guess Alex

Re: Plan: BO move throttling for visible VRAM evictions

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 that has been > >

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

Forgot to add v2: compressed ring_blacklist (nha) On 2017-03-27 06:36 PM, 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

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

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 --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 19 +-- 1 file changed, 13

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

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

[PATCH] Use LRU mapping policy for SDMA engines v2

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

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

On 2017-03-23 08:02 AM, Nicolai Hähnle wrote: On 17.03.2017 19:52, 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

Re: [PATCH libdrm] amdgpu_drm: add AMDGPU_HW_IP_UVD_ENC

FYI, I've pushed the patch to libdrm/master. Marek On Thu, Mar 23, 2017 at 3:43 PM, Leo Liu wrote: > Signed-off-by: Leo Liu > Reviewed-by: Alex Deucher > --- > include/drm/amdgpu_drm.h | 3 ++- > 1 file changed, 2 insertions(+), 1

Re: [PATCH 3/3] drm/amdgpu/soc15: return cached values for some registers

On 17-03-25 10:00 AM, Christian König wrote: > Sorry, I wasn't clear about this. GB_ADDR_CONFIG is still needed even > in Vega10. > > But CC_RB_BACKEND_DISABLE and GC_USER_RB_BACKEND_DISABLE aren't used > any more as far as I can see. > > The mask resulting from those two registers is computed

[PATCH 3/3] drm/amdgpu/soc15: drop support for reading some registers

The RB harvest registers are not necessary, the driver already exposes this info via the info ioctl. GB_BACKEND_MAP has been deprecated since SI and is not relevant to the RB mapping. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/soc15.c | 3 --- 1 file

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

Match what we do for other asics. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c index

[PATCH 2/3] drm/amdgpu/soc15: return cached values for some registers (v2)

Required for SR-IOV and saves MMIO transactions. v2: drop cached RB harvest registers Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/soc15.c | 30 ++ 1 file changed, 22 insertions(+), 8 deletions(-) diff --git

Re: [PATCH] drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags

Thanks for the help and the quick turnaround! On Sun, Mar 26, 2017 at 11:36 PM, Christian König wrote: > Am 27.03.2017 um 02:58 schrieb Michel Dänzer: > >> From: Michel Dänzer >> >> We were accidentally only overriding the first VRAM placement.

RE: [PATCH] drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Michel Dänzer > Sent: Sunday, March 26, 2017 8:59 PM > To: amd-gfx@lists.freedesktop.org > Cc: Zachary Michaels; Julien Isorce > Subject: [PATCH] drm/radeon: Override fpfn for all VRAM

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

Am 24.03.2017 um 11:38 schrieb Monk Liu: 1) Adapt to vulkan: Now use double SWITCH BUFFER to replace the 128 nops w/a, because when vulkan introduced, umd can insert 7 ~ 16 IBs per submit which makes 256 DW size cannot hold the whole DMAframe (if we still insert those 128 nops), CP team suggests

RE: [PATCH] drm/amd/powerplay: implemnent force dpm level on Vega10.

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Rex Zhu > Sent: Monday, March 27, 2017 10:18 AM > To: amd-gfx@lists.freedesktop.org > Cc: Zhu, Rex > Subject: [PATCH] drm/amd/powerplay: implemnent force dpm level on > Vega10. > >

[PATCH] drm/amd/powerplay: implemnent force dpm level on Vega10.

Change-Id: I13daa4ab9bdbd5a850e3ecf784fae43b19a126c9 --- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 38 -- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c

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

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Monk Liu > Sent: Friday, March 24, 2017 6:39 AM > To: amd-gfx@lists.freedesktop.org > Cc: Liu, Monk > Subject: [PATCH 12/13] drm/amdgpu:changes in gfx DMAframe scheme > > 1) Adapt to vulkan:

RE: [PATCH 10/13] drm/amdgpu:fix ring_write_multiple

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Monk Liu > Sent: Friday, March 24, 2017 6:38 AM > To: amd-gfx@lists.freedesktop.org > Cc: Liu, Monk > Subject: [PATCH 10/13] drm/amdgpu:fix ring_write_multiple > > ring_write_multiple should

RE: [PATCH 05/13] drm/amdgpu:fix ring init sequence

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Monk Liu > Sent: Friday, March 24, 2017 6:38 AM > To: amd-gfx@lists.freedesktop.org > Cc: Liu, Monk > Subject: [PATCH 05/13] drm/amdgpu:fix ring init sequence > > ring->buf_mask need be set

RE: [PATCH] drm/amdgpu: fix DRM clockgating incorrect reading

> -Original Message- > From: Huang Rui [mailto:ray.hu...@amd.com] > Sent: Monday, March 27, 2017 2:50 AM > To: amd-gfx@lists.freedesktop.org; Deucher, Alexander > Cc: Quan, Evan; Huang, Ray > Subject: [PATCH] drm/amdgpu: fix DRM clockgating incorrect reading > > Reported-by: Evan Quan

Re: [PATCH] drm/amd/amdgpu: decrease ttm bo priority to fix performance drop when VRAM pressure

Am 27.03.2017 um 14:05 schrieb Roger.He: 1. When VRAM pressue and trigger huge evictions there is performance drop, this patch fix it. 2. Also reserve priority for KFD using Change-Id: Idcd2db65be69d62bcbd7dfaa3bcf9bc964d6d122 Signed-off-by: Roger.He Reviewed-by:

[PATCH] drm/amd/amdgpu: decrease ttm bo priority to fix performance drop when VRAM pressure

1. When VRAM pressue and trigger huge evictions there is performance drop, this patch fix it. 2. Also reserve priority for KFD using Change-Id: Idcd2db65be69d62bcbd7dfaa3bcf9bc964d6d122 Signed-off-by: Roger.He --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +---

RE: [PATCH] Fix a misspelling of 'acceleration' in amdgpu_kms.c

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Nicholas Molloy > Sent: Saturday, March 25, 2017 9:39 AM > To: amd-gfx@lists.freedesktop.org > Subject: [PATCH] Fix a misspelling of 'acceleration' in amdgpu_kms.c > Reviewed-by: Alex

Re: [PATCH umr] read all sensors in a thread

On 27/03/17 09:41 AM, Tom St Denis wrote: Eventually the GPU_POWER sensor will be rated at around 50Hz but that's still too slow to read from the main loop of umr's --top so we move all sensor operations to a thread. Signed-off-by: Tom St Denis --- src/app/top.c | 110

Re: [PATCH libdrm] amdgpu: stop reading CC_RB_BACKEND_DISABLE on Vega10

Reviewed-by: Marek Olšák Marek On Mon, Mar 27, 2017 at 3:44 PM, Christian König wrote: > From: Christian König > > Follow up to 'drm: don't access deprecated register on Vega10'. > > The same information is available in

[PATCH umr] read all sensors in a thread

Eventually the GPU_POWER sensor will be rated at around 50Hz but that's still too slow to read from the main loop of umr's --top so we move all sensor operations to a thread. Signed-off-by: Tom St Denis --- src/app/top.c | 110

RE: [PATCH] iommu/amd: flush IOTLB for specific domains only

>-Original Message- >From: Daniel Drake [mailto:dr...@endlessm.com] >Sent: Monday, March 27, 2017 5:56 PM >To: Nath, Arindam >Cc: j...@8bytes.org; Deucher, Alexander; Bridgman, John; amd- >g...@lists.freedesktop.org; io...@lists.linux-foundation.org; Suthikulpanit, >Suravee; Linux

Re: [PATCH] iommu/amd: flush IOTLB for specific domains only

Hi Arindam, You CC'd me on this - does this mean that it is a fix for the issue described in the thread "amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out" ? Thanks Daniel On Mon, Mar 27, 2017 at 12:17 AM, wrote: > From: Arindam Nath

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

Hi Joerg, Thanks for looking into this. We confirm that this workaround avoids the iommu log spam and that amdgpu appears to be working fine with it. Daniel On Wed, Mar 22, 2017 at 5:22 AM, j...@8bytes.org wrote: > On Tue, Mar 21, 2017 at 04:30:55PM +, Deucher, Alexander

[PATCH 2/2] drm/amd/display: update plane functionalities

This patch introduces amdgpu_drm_plane_state structure, which subclasses drm_plane_state and holds data suitable for configuring hardware. It switches reset(), atomic_duplicate_state() & atomic_destroy_state() functions to new internal implementation, earlier they were pointing to drm core

Re: Plan: BO move throttling for visible VRAM evictions

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 that has been > decreasing our performance a lot recently, for example: >

Re: Plan: BO move throttling for visible VRAM evictions

Am 27.03.2017 um 11:36 schrieb zhoucm1: On 2017年03月27日 17:29, Christian König wrote: On APUs I've already enabled using direct access to the stolen parts of system memory. Thanks, could you point me out where is doing this? See here gmc_v7_0_mc_init(): /* Could aper size report 0

Re: Plan: BO move throttling for visible VRAM evictions

On 2017年03月27日 17:29, Christian König wrote: On APUs I've already enabled using direct access to the stolen parts of system memory. Thanks, could you point me out where is doing this? Regards, David Zhou So there won't be any eviction any more because of page faults on APUs. Regards,

Re: [PATCH 00/15] *** Multiple level VMPT enablement ***

Hi David, changes to patches #8 and #10 look good to me, but Alex (or somebody else? Jerry?) should acknowledge these at least as well. Patch #11 is Reviewed-by: Christian König . Patch #12 we need to clean this up a bit more, otherwise we will run into issue with

Re: [PATCH] drm/amdgpu: fix DRM clockgating incorrect reading

Am 27.03.2017 um 08:50 schrieb Huang Rui: Reported-by: Evan Quan Reported-by: Xiangliang Yu Signed-off-by: Huang Rui You should note in the commit message that this is for Vega10. Apart from that the patch is Acked-by: Christian

Re: [PATCH] drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags

Hi Michel, Great ! Would you mind to just add a note to mention that the infinite loop actually happens in ttm_bo_mem_force_space ? Thx! Cheers Julien On 27 March 2017 at 07:36, Christian König wrote: > Am 27.03.2017 um 02:58 schrieb Michel Dänzer: > >> From: Michel

RE: Plan: BO move throttling for visible VRAM evictions

For APU special case, can we prevent eviction happening between VRAM <> GTT? Regards, David Zhou -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Michel D?nzer Sent: Monday, March 27, 2017 3:36 PM To: Marek Olšák Cc:

Re: Plan: BO move throttling for visible VRAM evictions

On 25/03/17 01:33 AM, Marek Olšák wrote: > Hi, > > I'm sharing this idea here, because it's something that has been > decreasing our performance a lot recently, for example: > http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa > > I think the

RE: [PATCH] drm/amdgpu: fix DRM clockgating incorrect reading

Tested-by: Evan Quan >-Original Message- >From: Huang Rui [mailto:ray.hu...@amd.com] >Sent: Monday, March 27, 2017 2:50 PM >To: amd-gfx@lists.freedesktop.org; Deucher, Alexander > >Cc: Quan, Evan ; Huang, Ray

[PATCH] drm/amdgpu: fix DRM clockgating incorrect reading

Reported-by: Evan Quan Reported-by: Xiangliang Yu Signed-off-by: Huang Rui --- drivers/gpu/drm/amd/amdgpu/soc15.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c

Re: [PATCH 09/13] drm/amdgpu:fix gmc_v9 vm fault process for SRIOV

On 03/27/2017 02:39 PM, Christian König wrote: Am 27.03.2017 um 03:51 schrieb Zhang, Jerry (Junwei): On 03/24/2017 06:38 PM, Monk Liu wrote: for SRIOV we cannot use access register when in IRQ routine with regular KIQ method Change-Id: Ifae3164cf12311b851ae131f58175f6ec3174f82 Signed-off-by:

Re: [PATCH 09/13] drm/amdgpu:fix gmc_v9 vm fault process for SRIOV

Am 27.03.2017 um 03:51 schrieb Zhang, Jerry (Junwei): On 03/24/2017 06:38 PM, Monk Liu wrote: for SRIOV we cannot use access register when in IRQ routine with regular KIQ method Change-Id: Ifae3164cf12311b851ae131f58175f6ec3174f82 Signed-off-by: Monk Liu ---

Re: [PATCH] drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags

Am 27.03.2017 um 02:58 schrieb Michel Dänzer: From: Michel Dänzer We were accidentally only overriding the first VRAM placement. For BOs with the RADEON_GEM_NO_CPU_ACCESS flag set, radeon_ttm_placement_from_domain creates a second VRAM placment with fpfn == 0. If VRAM

[PATCH] iommu/amd: flush IOTLB for specific domains only

From: Arindam Nath The idea behind flush queues is to defer the IOTLB flushing for domains for which the mappings are no longer valid. We add such domains in queue_add(), and when the queue size reaches FLUSH_QUEUE_SIZE, we perform __queue_flush(). Since we have already

[PATCH 14/15] drm/amdgpu: set page table depth by num_level

Change-Id: I6180bedb8948398429fb32b36faa35960b3b85e6 Signed-off-by: Chunming Zhou Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 3 ++- drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 2 +- 2 files changed, 3 insertions(+),

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

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