That seems a bug. I will fix that.
It’s OK to store previous CUSTOM profile settings in driver and switch back to
that with no need to pass in settings again. That makes sense.
But you may need to update the patch(to check whether there is previous custom
profile settings).
Regards,
Evan
From: a
No need to update current profile mode if the new profile mode
does not take effect in fact.
Change-Id: If24474d201840bfaefacc189f6a6ff6856695dff
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 9 +
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 1
Indeed, it allowed me to apply the profile even with no previous profile set
(so it basically just applied all zeros). I’ll rebase my 2 patches on your
patch once that is pushed to drm-next.
Kent
From: Quan, Evan
Sent: Tuesday, March 26, 2019 5:10 AM
To: Russell, Kent ; amd-gfx@lists.freedeskto
I cannot apply your patch ... report error on line 85, what branch are you
based on ? I assume it should be amd-staging-drm-next
/Monk
-Original Message-
From: Christian König
Sent: Monday, March 25, 2019 8:23 PM
To: Liu, Monk ; amd-...@freedesktop.org
Subject: [PATCH 1/2] drm/amdgpu:
On 2019-03-25 10:05 p.m., Kangjie Lu wrote:
> In case alloc_workqueue fails, the fix frees memory and
> returns -ENOMEM to avoid potential NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu
> ---
> v2: use radeon_crtc_destroy to properly clean up resources as
> suggested by Michel Dänzer
>
If DAL requires to force MCLK high, the FCLK will be
forced to high also.
Change-Id: Iaff8956ca1faafaf904f0bec108f566e8bbf6a64
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu
Ping..
> -Original Message-
> From: Evan Quan
> Sent: 2019年3月23日 2:06
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan
> Subject: [PATCH 1/2] drm/amd/powerplay: add ECC feature bit
>
> It's OK to have this feature bit with old SMU firmwares.
> But the feature should be disabled on t
Ping..
> -Original Message-
> From: Evan Quan
> Sent: 2019年3月23日 2:07
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan
> Subject: [PATCH 2/2] drm/amd/powerplay: correct data type to avoid
> overflow
>
> Avoid left shift overflow.
>
> Change-Id: If03f4f4d440b6d742d8eaa23d0bae6ddd21c
Hi Lauri,
There’s a more efficient method using the Power Profiles (and optionally, the
ROCM-SMI tool, found at https://github.com/RadeonOpenCompute/ROC-smi), or the
pp_sclk mask, depending on what exactly you want. I’ll list out the methods
here and the rocm-smi and non-SMI commands to do it.
Acked-by: Alex Deucher
From: amd-gfx on behalf of Evan Quan
Sent: Tuesday, March 26, 2019 6:13 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: fix possible hang with 3+ 4K monitors
If DAL requires to force MCLK high, the
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Quan, Evan
Sent: Tuesday, March 26, 2019 6:15 AM
To: Quan, Evan; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH 2/2] drm/amd/powerplay: correct data type to avoid overflow
Ping..
> -Origina
That makes sense.
Reviewed-by: Kent Russell
> -Original Message-
> From: amd-gfx On Behalf Of Evan
> Quan
> Sent: Tuesday, March 26, 2019 5:34 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Russell, Kent
>
> Subject: [PATCH] drm/amd/powerplay: update current profile mode on
I think in a real usage ( tensorflow ex), it's rarely only the system memory
(no vram) will be mapped for peer access.
Anyway, how about add preferred_domain check for xgmi ? I think even user use
ioctl to change the preferred_domain, bo_add should still be called before the
real mapping.
Re
This should not result in any changes.
v2: Rebase
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-gfx@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_fb.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --
On 2019-03-26 9:15 a.m., Liu, Shaoyun wrote:
> I think in a real usage ( tensorflow ex), it's rarely only the
> system memory (no vram) will be mapped for peer access.
With that argument you could simplify your change and just power up XGMI
as soon as a KFD process starts. Because that's effec
Hi!
Thanx for helping, but I have tried those methods and they didn't work on
Ryzen 2400G.
--
Lauri
On Tue, Mar 26, 2019 at 2:57 PM Russell, Kent wrote:
> Hi Lauri,
>
>
>
> There’s a more efficient method using the Power Profiles (and optionally,
> the ROCM-SMI tool, found at https://github.co
Den 26.03.2019 14.20, skrev Daniel Vetter:
> This should not result in any changes.
>
> v2: Rebase
>
> Signed-off-by: Daniel Vetter
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: amd-gfx@lists.freedesktop.org
> ---
Acked-by: Noralf Trønnes
_
I'm hitting some badness with piglit today, see the attached dmesg
excerpt. I was away for a couple of days, but looks like it might be
related to the VM changes? I'll try bisecting.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast
Can we simply failed the set placement call if we find the bo_va is
existing and bo_va->is_xgmi flag is set ? The original call also
failed when it detect it's shared and the placement is in VRAM.
Regards
shaoyun.liu
On 2019-03-26 10:00 a.m., Kuehling, Felix wrote:
> On 2019-03-26 9:15 a
The context device pointer could be different of the object been acctually
allocated
Change-Id: I7b2338858126d75350b65ff04d9bb419e1eae15c
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/a
The problem is that userspace could add it first and then change the domain.
Pretty unlikely thought,
Christian.
Am 26.03.19 um 14:15 schrieb Liu, Shaoyun:
I think in a real usage ( tensorflow ex), it's rarely only the
system memory (no vram) will be mapped for peer access.
Anyway, how about
On 2019-03-26 4:21 p.m., Michel Dänzer wrote:
>
> I'm hitting some badness with piglit today, see the attached dmesg
> excerpt. I was away for a couple of days, but looks like it might be
> related to the VM changes? I'll try bisecting.
Bisected to:
602b5050d839c40572bbb19e9b17a37a150c1e3c is th
On 3/22/19 4:04 PM, Mario Kleiner wrote:
> In VRR mode, proper vblank/pageflip timestamps can only be computed
> after the display scanout position has left front-porch. Therefore
> delay calls to drm_crtc_handle_vblank(), and thereby calls to
> drm_update_vblank_count() and pageflip event delivery
Am 26.03.19 um 16:43 schrieb Liu, Shaoyun:
Can we simply failed the set placement call if we find the bo_va is
existing and bo_va->is_xgmi flag is set ? The original call also
failed when it detect it's shared and the placement is in VRAM.
Possible, alternative we could just move setting t
Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for
peer device
Change-Id: I1881deff3da19f1f4b58d5765db03a590092a5b2
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
2 files changed, 11
Am 26.03.19 um 16:51 schrieb Liu, Shaoyun:
The context device pointer could be different of the object been acctually
allocated
Actually that is unnecessary, cause the GEM adev is always identical to
the file_priv.
E.g. we don't support the hack using in the KFD for BO sharing here.
Chan
Mhm, that is actually harmless. We somehow end up trying to submit a
zero sized IB.
Going to double check tomorrow how this can happen.
Is the anything bad happening when you just remove the warning?
Christian.
Am 26.03.19 um 18:30 schrieb Michel Dänzer:
On 2019-03-26 4:21 p.m., Michel Dänze
Am 26.03.19 um 19:54 schrieb Liu, Shaoyun:
Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for
peer device
Change-Id: I1881deff3da19f1f4b58d5765db03a590092a5b2
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 9 +
drivers/gpu/drm/amd/am
OK , just ignore it . BTW , if you think it's a hack currently used in
KFD to share the memory among GPUs, what's your plane to use the peer
GPU through XGMI from GEM point of view ?
Regards
shaoyun.liu
On 2019-03-26 2:56 p.m., Christian König wrote:
> Am 26.03.19 um 16:51 schrieb Liu, Shao
Am 26.03.19 um 20:33 schrieb Liu, Shaoyun:
> OK , just ignore it . BTW , if you think it's a hack currently used in
> KFD to share the memory among GPUs, what's your plane to use the peer
> GPU through XGMI from GEM point of view ?
We just need to unpack the root bo while doing the XGMI check,
On 2019-03-26 2:54 p.m., Liu, Shaoyun wrote:
> Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for
> peer device
>
> Change-Id: I1881deff3da19f1f4b58d5765db03a590092a5b2
> Signed-off-by: shaoyunl
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 9 +
> drivers
Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for
peer device
Change-Id: I1881deff3da19f1f4b58d5765db03a590092a5b2
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
2 files changed,
32 matches
Mail list logo
