Re: [PATCH] dma-fence: add might_sleep annotation to _wait()

[Christian König]

Am 19.05.20 um 15:27 schrieb Daniel Vetter:

Do it uncontionally, there's a separate peek function with
dma_fence_is_signalled() which can be called from atomic context.

v2: Consensus calls for an unconditional might_sleep (Chris,
Christian)

Full audit:
- dma-fence.h: Uses MAX_SCHEDULE_TIMOUT, good chance this sleeps
- dma-resv.c: Timeout always at least 1
- st-dma-fence.c: Save to sleep in testcases
- amdgpu_cs.c: Both callers are for variants of the wait ioctl
- amdgpu_device.c: Two callers in vram recover code, both right next
   to mutex_lock.
- amdgpu_vm.c: Use in the vm_wait ioctl, next to _reserve/unreserve
- remaining functions in amdgpu: All for test_ib implementations for
   various engines, caller for that looks all safe (debugfs, driver
   load, reset)
- etnaviv: another wait ioctl
- habanalabs: another wait ioctl
- nouveau_fence.c: hardcoded 15*HZ ... glorious
- nouveau_gem.c: hardcoded 2*HZ ... so not even super consistent, but
   this one does have a WARN_ON :-/ At least this one is only a
   fallback path for when kmalloc fails. Maybe this should be put onto
   some worker list instead, instead of a work per unamp ...
- i915/selftests: Hardecoded HZ / 4 or HZ / 8
- i915/gt/selftests: Going up the callchain looks safe looking at
   nearby callers
- i915/gt/intel_gt_requests.c. Wrapped in a mutex_lock
- i915/gem_i915_gem_wait.c: The i915-version which is called instead
   for i915 fences already has a might_sleep() annotation, so all good

Cc: Alex Deucher 
Cc: Lucas Stach 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Ben Skeggs 
Cc: "VMware Graphics" 
Cc: Oded Gabbay 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-fence.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 90edf2b281b0..656e9ac2d028 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -208,6 +208,8 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, 
signed long timeout)
if (WARN_ON(timeout < 0))
return -EINVAL;
  
+	might_sleep();

+
trace_dma_fence_wait_start(fence);
if (fence->ops->wait)
ret = fence->ops->wait(fence, intr, timeout);


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/2] drm/amd/powerplay: remove the support of vega20 from swsmu

[Kevin Wang]

by default, vega20 will use legacy powerplay driver.
in order to maintain the code conveniently in the future,
remove the support of vega20 from swsmu.

Signed-off-by: Kevin Wang 
---
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c|9 +-
 drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h |1 -
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c |9 -
 drivers/gpu/drm/amd/powerplay/vega20_ppt.c| 3288 -
 drivers/gpu/drm/amd/powerplay/vega20_ppt.h|  179 -
 5 files changed, 1 insertion(+), 3485 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/powerplay/vega20_ppt.c
 delete mode 100644 drivers/gpu/drm/amd/powerplay/vega20_ppt.h

diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c 
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 9ad6f0f3aada..7894dd09c9f5 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -29,7 +29,6 @@
 #include "smu_v11_0.h"
 #include "smu_v12_0.h"
 #include "atom.h"
-#include "vega20_ppt.h"
 #include "arcturus_ppt.h"
 #include "navi10_ppt.h"
 #include "renoir_ppt.h"
@@ -567,9 +566,7 @@ int smu_update_table(struct smu_context *smu, enum 
smu_table_id table_index, int
 
 bool is_support_sw_smu(struct amdgpu_device *adev)
 {
-   if (adev->asic_type == CHIP_VEGA20)
-   return (amdgpu_dpm == 2) ? true : false;
-   else if (adev->asic_type >= CHIP_ARCTURUS)
+   if (adev->asic_type >= CHIP_ARCTURUS)
return true;
 
return false;
@@ -759,10 +756,6 @@ static int smu_set_funcs(struct amdgpu_device *adev)
smu->od_enabled = true;
 
switch (adev->asic_type) {
-   case CHIP_VEGA20:
-   adev->pm.pp_feature &= ~PP_GFXOFF_MASK;
-   vega20_set_ppt_funcs(smu);
-   break;
case CHIP_NAVI10:
case CHIP_NAVI14:
case CHIP_NAVI12:
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h 
b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
index 6b3b451a8018..5c6bfe76d596 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h
@@ -26,7 +26,6 @@
 #include "amdgpu_smu.h"
 
 #define SMU11_DRIVER_IF_VERSION_INV 0x
-#define SMU11_DRIVER_IF_VERSION_VG20 0x13
 #define SMU11_DRIVER_IF_VERSION_ARCT 0x14
 #define SMU11_DRIVER_IF_VERSION_NV10 0x36
 #define SMU11_DRIVER_IF_VERSION_NV12 0x33
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c 
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index b6a7467260a6..960360918e7a 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -46,7 +46,6 @@
 #include "asic_reg/smuio/smuio_11_0_0_offset.h"
 #include "asic_reg/smuio/smuio_11_0_0_sh_mask.h"
 
-MODULE_FIRMWARE("amdgpu/vega20_smc.bin");
 MODULE_FIRMWARE("amdgpu/arcturus_smc.bin");
 MODULE_FIRMWARE("amdgpu/navi10_smc.bin");
 MODULE_FIRMWARE("amdgpu/navi14_smc.bin");
@@ -148,9 +147,6 @@ int smu_v11_0_init_microcode(struct smu_context *smu)
struct amdgpu_firmware_info *ucode = NULL;
 
switch (adev->asic_type) {
-   case CHIP_VEGA20:
-   chip_name = "vega20";
-   break;
case CHIP_ARCTURUS:
chip_name = "arcturus";
break;
@@ -270,9 +266,6 @@ int smu_v11_0_check_fw_version(struct smu_context *smu)
smu_debug = (smu_version >> 0) & 0xff;
 
switch (smu->adev->asic_type) {
-   case CHIP_VEGA20:
-   smu->smc_driver_if_version = SMU11_DRIVER_IF_VERSION_VG20;
-   break;
case CHIP_ARCTURUS:
smu->smc_driver_if_version = SMU11_DRIVER_IF_VERSION_ARCT;
break;
@@ -1364,8 +1357,6 @@ int smu_v11_0_gfx_off_control(struct smu_context *smu, 
bool enable)
struct amdgpu_device *adev = smu->adev;
 
switch (adev->asic_type) {
-   case CHIP_VEGA20:
-   break;
case CHIP_NAVI10:
case CHIP_NAVI14:
case CHIP_NAVI12:
diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c 
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
deleted file mode 100644
index 61923530b2e4..
--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+++ /dev/null
@@ -1,3288 +0,0 @@
-/*
- * Copyright 2019 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO TH

[PATCH 1/2] drm/amd/powerplay: remove the support of xgmi pstate on vega20 from swsmu

[Kevin Wang]

the vega20 asic uses legacy powerplay driver by default.

1. cleanup is_support_sw_smu_xgmi() function.
(ony use for vega20 xgmi pstate check)
2. by default, the vega20 set xgmi pstate by legacy powerplay routine.

Signed-off-by: Kevin Wang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c|  4 ++--
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 11 ---
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |  1 -
 3 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
index f36b58a7f485..65472b3dd815 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
@@ -1162,7 +1162,7 @@ int amdgpu_dpm_set_xgmi_pstate(struct amdgpu_device *adev,
 {
int ret = 0;
 
-   if (is_support_sw_smu_xgmi(adev))
+   if (is_support_sw_smu(adev))
ret = smu_set_xgmi_pstate(&adev->smu, pstate);
else if (adev->powerplay.pp_funcs &&
 adev->powerplay.pp_funcs->set_xgmi_pstate)
@@ -1197,4 +1197,4 @@ int amdgpu_dpm_allow_xgmi_power_down(struct amdgpu_device 
*adev, bool en)
return smu_allow_xgmi_power_down(smu, en);
 
return 0;
-}
\ No newline at end of file
+}
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c 
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 1abc4be6b72e..9ad6f0f3aada 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -575,17 +575,6 @@ bool is_support_sw_smu(struct amdgpu_device *adev)
return false;
 }
 
-bool is_support_sw_smu_xgmi(struct amdgpu_device *adev)
-{
-   if (!is_support_sw_smu(adev))
-   return false;
-
-   if (adev->asic_type == CHIP_VEGA20)
-   return true;
-
-   return false;
-}
-
 int smu_sys_get_pp_table(struct smu_context *smu, void **table)
 {
struct smu_table_context *smu_table = &smu->smu_table;
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index 4d1c2a44a8b6..bac7e13dc801 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
@@ -675,7 +675,6 @@ int smu_update_table(struct smu_context *smu, enum 
smu_table_id table_index, int
 void *table_data, bool drv2smu);
 
 bool is_support_sw_smu(struct amdgpu_device *adev);
-bool is_support_sw_smu_xgmi(struct amdgpu_device *adev);
 int smu_reset(struct smu_context *smu);
 int smu_common_read_sensor(struct smu_context *smu, enum amd_pp_sensors sensor,
   void *data, uint32_t *size);
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: add condition to set MP1 state on gpu reset

[Quan, Evan]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Evan Quan 

-Original Message-
From: Gao, Likun 
Sent: Monday, May 18, 2020 6:35 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Quan, Evan ; 
Clements, John ; Gao, Likun 
Subject: [PATCH] drm/amdgpu: add condition to set MP1 state on gpu reset

From: Likun Gao 

Only ras supportted need to set MP1 state to prepare for unload before 
reloading SMU FW.

Signed-off-by: Likun Gao 
Change-Id: I9e49b3f13aa613393381fe15b6b060665026078a
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 5de5b27bf4c4..a349cf15f90a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1399,12 +1399,13 @@ static int psp_load_smu_fw(struct psp_context *psp)
 struct amdgpu_device* adev = psp->adev;
 struct amdgpu_firmware_info *ucode =
 &adev->firmware.ucode[AMDGPU_UCODE_ID_SMC];
+struct amdgpu_ras *ras = psp->ras.ras;

 if (!ucode->fw || amdgpu_sriov_vf(psp->adev))
 return 0;


-if (adev->in_gpu_reset) {
+if (adev->in_gpu_reset && ras && ras->supported) {
 ret = amdgpu_dpm_set_mp1_state(adev, PP_MP1_STATE_UNLOAD);
 if (ret) {
 DRM_WARN("Failed to set MP1 state prepare for reload\n");
--
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: slow rx 5600 xt fps

[Alex Deucher]

On Tue, May 19, 2020 at 9:16 PM Javad Karabi  wrote:
>
> thanks for the answers alex.
>
> so, i went ahead and got a displayport cable to see if that changes
> anything. and now, when i run monitor only, and the monitor connected
> to the card, it has no issues like before! so i am thinking that
> somethings up with either the hdmi cable, or some hdmi related setting
> in my system? who knows, but im just gonna roll with only using
> displayport cables now.
> the previous hdmi cable was actually pretty long, because i was
> extending it with an hdmi extension cable, so maybe the signal was
> really bad or something :/
>
> but yea, i guess the only real issue now is maybe something simple
> related to some sysfs entry about enabling some powermode, voltage,
> clock frequency, or something, so that glxgears will give me more than
> 300 fps. but atleast now i can use a single monitor configuration with
> the monitor displayported up to the card.
>

The GPU dynamically adjusts the clocks and voltages based on load.  No
manual configuration is required.

At this point, we probably need to see you xorg log and dmesg output
to try and figure out exactly what is going on.  I still suspect there
is some interaction going on with both GPUs and the integrated GPU
being the primary, so as I mentioned before, you should try and run X
on just the amdgpu rather than trying to use both of them.

Alex


> also, one other thing i think you might be interested in, that was
> happening before.
>
> so, previously, with laptop -tb3-> egpu-hdmi> monitor, there was a
> funny thing happening which i never could figure out.
> when i would look at the X logs, i would see that "modesetting" (for
> the intel integrated graphics) was reporting that MonitorA was used
> with "eDP-1",  which is correct and what i expected.
> when i scrolled further down, i then saw that "HDMI-A-1-2" was being
> used for another MonitorB, which also is what i expected (albeit i
> have no idea why its saying A-1-2)
> but amdgpu was _also_ saying that DisplayPort-1-2 (a port on the
> radeon card) was being used for MonitorA, which is the same Monitor
> that the modesetting driver had claimed to be using with eDP-1!
>
> so the point is that amdgpu was "using" Monitor0 with DisplayPort-1-2,
> although that is what modesetting was using for eDP-1.
>
> anyway, thats a little aside, i doubt it was related to the terrible
> hdmi experience i was getting, since its about display port and stuff,
> but i thought id let you know about that.
>
> if you think that is a possible issue, im more than happy to plug the
> hdmi setup back in and create an issue on gitlab with the logs and
> everything
>
> On Tue, May 19, 2020 at 4:42 PM Alex Deucher  wrote:
> >
> > On Tue, May 19, 2020 at 5:22 PM Javad Karabi  wrote:
> > >
> > > lol youre quick!
> > >
> > > "Windows has supported peer to peer DMA for years so it already has a
> > > numbers of optimizations that are only now becoming possible on Linux"
> > >
> > > whoa, i figured linux would be ahead of windows when it comes to
> > > things like that. but peer-to-peer dma is something that is only
> > > recently possible on linux, but has been possible on windows? what
> > > changed recently that allows for peer to peer dma in linux?
> > >
> >
> > A few things that made this more complicated on Linux:
> > 1. Linux uses IOMMUs more extensively than windows so you can't just
> > pass around physical bus addresses.
> > 2. Linux supports lots of strange architectures that have a lot of
> > limitations with respect to peer to peer transactions
> >
> > It just took years to get all the necessary bits in place in Linux and
> > make everyone happy.
> >
> > > also, in the context of a game running opengl on some gpu, is the
> > > "peer-to-peer" dma transfer something like: the game draw's to some
> > > memory it has allocated, then a DMA transfer gets that and moves it
> > > into the graphics card output?
> >
> > Peer to peer DMA just lets devices access another devices local memory
> > directly.  So if you have a buffer in vram on one device, you can
> > share that directly with another device rather than having to copy it
> > to system memory first.  For example, if you have two GPUs, you can
> > have one of them copy it's content directly to a buffer in the other
> > GPU's vram rather than having to go through system memory first.
> >
> > >
> > > also, i know it can be super annoying trying to debug an issue like
> > > this, with someone like me who has all types of differences from a
> > > normal setup (e.g. using it via egpu, using a kernel with custom
> > > configs and stuff) so as a token of my appreciation i donated 50$ to
> > > the red cross' corona virus outbreak charity thing, on behalf of
> > > amd-gfx.
> >
> > Thanks,
> >
> > Alex
> >
> > >
> > > On Tue, May 19, 2020 at 4:13 PM Alex Deucher  
> > > wrote:
> > > >
> > > > On Tue, May 19, 2020 at 3:44 PM Javad Karabi  
> > > > wrote:
> > > > >
> > > > > just a couple more qu

RE: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition

[Zhang, Hawking]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Hawking Zhang 

Regards,
Hawking
From: Clements, John 
Sent: Wednesday, May 20, 2020 10:26
To: Zhang, Hawking ; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition


[AMD Official Use Only - Internal Distribution Only]

Thank you Hawking,

I have updated/tested the patch based of your recommendation.

From: Zhang, Hawking mailto:hawking.zh...@amd.com>>
Sent: Tuesday, May 19, 2020 6:27 PM
To: Clements, John mailto:john.cleme...@amd.com>>; 
amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition


[AMD Official Use Only - Internal Distribution Only]

Please only apply the check to arcturus - we don't need to check ras fatal 
error event on all the NV series.

Regards,
Hawking
From: Clements, John mailto:john.cleme...@amd.com>>
Sent: Tuesday, May 19, 2020 17:15
To: amd-gfx@lists.freedesktop.org; Zhang, 
Hawking mailto:hawking.zh...@amd.com>>
Subject: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition


[AMD Official Use Only - Internal Distribution Only]

Submitting patch to block SMU access' via SMI during RAS recovery
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition

[Clements, John]

[AMD Official Use Only - Internal Distribution Only]

Thank you Hawking,

I have updated/tested the patch based of your recommendation.

From: Zhang, Hawking 
Sent: Tuesday, May 19, 2020 6:27 PM
To: Clements, John ; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition


[AMD Official Use Only - Internal Distribution Only]

Please only apply the check to arcturus - we don't need to check ras fatal 
error event on all the NV series.

Regards,
Hawking
From: Clements, John mailto:john.cleme...@amd.com>>
Sent: Tuesday, May 19, 2020 17:15
To: amd-gfx@lists.freedesktop.org; Zhang, 
Hawking mailto:hawking.zh...@amd.com>>
Subject: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition


[AMD Official Use Only - Internal Distribution Only]

Submitting patch to block SMU access' via SMI during RAS recovery


0001-drm-amdgpu-resolve-ras-recovery-vs-smi-race-conditio.patch
Description: 0001-drm-amdgpu-resolve-ras-recovery-vs-smi-race-conditio.patch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: slow rx 5600 xt fps

[Javad Karabi]

John,

yea, totally agree with you.
one other thing i havent mentioned is that, each time, ive also been
testing everything by running dota 2 with graphics settings all the
way up. and the behavior in dota2 has been consistent

its funny: when i run dota 2, it consistently hovers at 40fps, but the
weird thing is that with graphics settings all the way low, or
graphics settings all the way up, it sticks to 40fps. regardless of
vsync on / off.
i didnt mention my testing of dota 2 because i figured that glxgears
would summarize the issue best, but i do understand what you mean by
trying a more demanding test.
ive also been testing with glmark2, and it would only give 300-400fps too

heres an example:

$ vblank_mode=0 DRI_PRIME=1 glmark2
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: option value of option vblank_mode ignored.
===
glmark2 2014.03+git20150611.fa71af2d
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   AMD Radeon RX 5600 XT (NAVI10, DRM 3.36.0,
5.6.13-karabijavad, LLVM 9.0.1)
GL_VERSION:4.6 (Compatibility Profile) Mesa 20.0.4
===
[build] use-vbo=false: FPS: 128 FrameTime: 7.812 ms
[build] use-vbo=true: FPS: 129 FrameTime: 7.752 ms



On Tue, May 19, 2020 at 8:20 PM Bridgman, John  wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> Suggest you use something more demanding that glxgears as a test - part of 
> the problem is that glxgears runs so fast normally (30x faster than your 
> display) that even a small amount of overhead copying a frame from one place 
> to another makes a huge difference in FPS.
>
> If you use a test program that normally runs at 90 FPS you'll probably find 
> that the "slow" speed is something like 85 FPS, rather than the 6:1 
> difference you see with glxgears.
>
> 
> From: amd-gfx  on behalf of Javad 
> Karabi 
> Sent: May 19, 2020 9:16 PM
> To: Alex Deucher 
> Cc: amd-gfx list 
> Subject: Re: slow rx 5600 xt fps
>
> thanks for the answers alex.
>
> so, i went ahead and got a displayport cable to see if that changes
> anything. and now, when i run monitor only, and the monitor connected
> to the card, it has no issues like before! so i am thinking that
> somethings up with either the hdmi cable, or some hdmi related setting
> in my system? who knows, but im just gonna roll with only using
> displayport cables now.
> the previous hdmi cable was actually pretty long, because i was
> extending it with an hdmi extension cable, so maybe the signal was
> really bad or something :/
>
> but yea, i guess the only real issue now is maybe something simple
> related to some sysfs entry about enabling some powermode, voltage,
> clock frequency, or something, so that glxgears will give me more than
> 300 fps. but atleast now i can use a single monitor configuration with
> the monitor displayported up to the card.
>
> also, one other thing i think you might be interested in, that was
> happening before.
>
> so, previously, with laptop -tb3-> egpu-hdmi> monitor, there was a
> funny thing happening which i never could figure out.
> when i would look at the X logs, i would see that "modesetting" (for
> the intel integrated graphics) was reporting that MonitorA was used
> with "eDP-1",  which is correct and what i expected.
> when i scrolled further down, i then saw that "HDMI-A-1-2" was being
> used for another MonitorB, which also is what i expected (albeit i
> have no idea why its saying A-1-2)
> but amdgpu was _also_ saying that DisplayPort-1-2 (a port on the
> radeon card) was being used for MonitorA, which is the same Monitor
> that the modesetting driver had claimed to be using with eDP-1!
>
> so the point is that amdgpu was "using" Monitor0 with DisplayPort-1-2,
> although that is what modesetting was using for eDP-1.
>
> anyway, thats a little aside, i doubt it was related to the terrible
> hdmi experience i was getting, since its about display port and stuff,
> but i thought id let you know about that.
>
> if you think that is a possible issue, im more than happy to plug the
> hdmi setup back in and create an issue on gitlab with the logs and
> everything
>
> On Tue, May 19, 2020 at 4:42 PM Alex Deucher  wrote:
> >
> > On Tue, May 19, 2020 at 5:22 PM Javad Karabi  wrote:
> > >
> > > lol youre quick!
> > >
> > > "Windows has supported peer to peer DMA for years so it already has a
> > > numbers of optimizations that are only now becoming possible on Linux"
> > >
> > > whoa, i figured linux would be ahead of windows when it comes to
> > > things like that. but peer-to-peer dma is something that is only
> > > recently possible on linux, but has been possible on windows? what
> > > changed recently that allows for peer to peer dma in linux?
> > >
> >
> > A few things that made this more complicated on Linux:
>

Re: slow rx 5600 xt fps

[Bridgman, John]

[AMD Official Use Only - Internal Distribution Only]

Suggest you use something more demanding that glxgears as a test - part of the 
problem is that glxgears runs so fast normally (30x faster than your display) 
that even a small amount of overhead copying a frame from one place to another 
makes a huge difference in FPS.

If you use a test program that normally runs at 90 FPS you'll probably find 
that the "slow" speed is something like 85 FPS, rather than the 6:1 difference 
you see with glxgears.


From: amd-gfx  on behalf of Javad Karabi 

Sent: May 19, 2020 9:16 PM
To: Alex Deucher 
Cc: amd-gfx list 
Subject: Re: slow rx 5600 xt fps

thanks for the answers alex.

so, i went ahead and got a displayport cable to see if that changes
anything. and now, when i run monitor only, and the monitor connected
to the card, it has no issues like before! so i am thinking that
somethings up with either the hdmi cable, or some hdmi related setting
in my system? who knows, but im just gonna roll with only using
displayport cables now.
the previous hdmi cable was actually pretty long, because i was
extending it with an hdmi extension cable, so maybe the signal was
really bad or something :/

but yea, i guess the only real issue now is maybe something simple
related to some sysfs entry about enabling some powermode, voltage,
clock frequency, or something, so that glxgears will give me more than
300 fps. but atleast now i can use a single monitor configuration with
the monitor displayported up to the card.

also, one other thing i think you might be interested in, that was
happening before.

so, previously, with laptop -tb3-> egpu-hdmi> monitor, there was a
funny thing happening which i never could figure out.
when i would look at the X logs, i would see that "modesetting" (for
the intel integrated graphics) was reporting that MonitorA was used
with "eDP-1",  which is correct and what i expected.
when i scrolled further down, i then saw that "HDMI-A-1-2" was being
used for another MonitorB, which also is what i expected (albeit i
have no idea why its saying A-1-2)
but amdgpu was _also_ saying that DisplayPort-1-2 (a port on the
radeon card) was being used for MonitorA, which is the same Monitor
that the modesetting driver had claimed to be using with eDP-1!

so the point is that amdgpu was "using" Monitor0 with DisplayPort-1-2,
although that is what modesetting was using for eDP-1.

anyway, thats a little aside, i doubt it was related to the terrible
hdmi experience i was getting, since its about display port and stuff,
but i thought id let you know about that.

if you think that is a possible issue, im more than happy to plug the
hdmi setup back in and create an issue on gitlab with the logs and
everything

On Tue, May 19, 2020 at 4:42 PM Alex Deucher  wrote:
>
> On Tue, May 19, 2020 at 5:22 PM Javad Karabi  wrote:
> >
> > lol youre quick!
> >
> > "Windows has supported peer to peer DMA for years so it already has a
> > numbers of optimizations that are only now becoming possible on Linux"
> >
> > whoa, i figured linux would be ahead of windows when it comes to
> > things like that. but peer-to-peer dma is something that is only
> > recently possible on linux, but has been possible on windows? what
> > changed recently that allows for peer to peer dma in linux?
> >
>
> A few things that made this more complicated on Linux:
> 1. Linux uses IOMMUs more extensively than windows so you can't just
> pass around physical bus addresses.
> 2. Linux supports lots of strange architectures that have a lot of
> limitations with respect to peer to peer transactions
>
> It just took years to get all the necessary bits in place in Linux and
> make everyone happy.
>
> > also, in the context of a game running opengl on some gpu, is the
> > "peer-to-peer" dma transfer something like: the game draw's to some
> > memory it has allocated, then a DMA transfer gets that and moves it
> > into the graphics card output?
>
> Peer to peer DMA just lets devices access another devices local memory
> directly.  So if you have a buffer in vram on one device, you can
> share that directly with another device rather than having to copy it
> to system memory first.  For example, if you have two GPUs, you can
> have one of them copy it's content directly to a buffer in the other
> GPU's vram rather than having to go through system memory first.
>
> >
> > also, i know it can be super annoying trying to debug an issue like
> > this, with someone like me who has all types of differences from a
> > normal setup (e.g. using it via egpu, using a kernel with custom
> > configs and stuff) so as a token of my appreciation i donated 50$ to
> > the red cross' corona virus outbreak charity thing, on behalf of
> > amd-gfx.
>
> Thanks,
>
> Alex
>
> >
> > On Tue, May 19, 2020 at 4:13 PM Alex Deucher  wrote:
> > >
> > > On Tue, May 19, 2020 at 3:44 PM Javad Karabi  
> > > wrote:
> > > >
> > > > just a couple more questions:
> > > >
> > > 

Re: slow rx 5600 xt fps

[Javad Karabi]

s/Monitor0/MonitorA

(the Monitor0 and Monitor1 are actually Monitor4 (for the laptop) and
Montor0 (for the hdmi output), atleast i think that was the numbers.)
they were autogenerated Monitor identifiers by xorg, so i dont
remember the exact numbers, but either way, for some reason the
radeon's DisplayPort-1-2 was "using" the same monitor as modesetting's
eDP1

On Tue, May 19, 2020 at 8:16 PM Javad Karabi  wrote:
>
> thanks for the answers alex.
>
> so, i went ahead and got a displayport cable to see if that changes
> anything. and now, when i run monitor only, and the monitor connected
> to the card, it has no issues like before! so i am thinking that
> somethings up with either the hdmi cable, or some hdmi related setting
> in my system? who knows, but im just gonna roll with only using
> displayport cables now.
> the previous hdmi cable was actually pretty long, because i was
> extending it with an hdmi extension cable, so maybe the signal was
> really bad or something :/
>
> but yea, i guess the only real issue now is maybe something simple
> related to some sysfs entry about enabling some powermode, voltage,
> clock frequency, or something, so that glxgears will give me more than
> 300 fps. but atleast now i can use a single monitor configuration with
> the monitor displayported up to the card.
>
> also, one other thing i think you might be interested in, that was
> happening before.
>
> so, previously, with laptop -tb3-> egpu-hdmi> monitor, there was a
> funny thing happening which i never could figure out.
> when i would look at the X logs, i would see that "modesetting" (for
> the intel integrated graphics) was reporting that MonitorA was used
> with "eDP-1",  which is correct and what i expected.
> when i scrolled further down, i then saw that "HDMI-A-1-2" was being
> used for another MonitorB, which also is what i expected (albeit i
> have no idea why its saying A-1-2)
> but amdgpu was _also_ saying that DisplayPort-1-2 (a port on the
> radeon card) was being used for MonitorA, which is the same Monitor
> that the modesetting driver had claimed to be using with eDP-1!
>
> so the point is that amdgpu was "using" Monitor0 with DisplayPort-1-2,
> although that is what modesetting was using for eDP-1.
>
> anyway, thats a little aside, i doubt it was related to the terrible
> hdmi experience i was getting, since its about display port and stuff,
> but i thought id let you know about that.
>
> if you think that is a possible issue, im more than happy to plug the
> hdmi setup back in and create an issue on gitlab with the logs and
> everything
>
> On Tue, May 19, 2020 at 4:42 PM Alex Deucher  wrote:
> >
> > On Tue, May 19, 2020 at 5:22 PM Javad Karabi  wrote:
> > >
> > > lol youre quick!
> > >
> > > "Windows has supported peer to peer DMA for years so it already has a
> > > numbers of optimizations that are only now becoming possible on Linux"
> > >
> > > whoa, i figured linux would be ahead of windows when it comes to
> > > things like that. but peer-to-peer dma is something that is only
> > > recently possible on linux, but has been possible on windows? what
> > > changed recently that allows for peer to peer dma in linux?
> > >
> >
> > A few things that made this more complicated on Linux:
> > 1. Linux uses IOMMUs more extensively than windows so you can't just
> > pass around physical bus addresses.
> > 2. Linux supports lots of strange architectures that have a lot of
> > limitations with respect to peer to peer transactions
> >
> > It just took years to get all the necessary bits in place in Linux and
> > make everyone happy.
> >
> > > also, in the context of a game running opengl on some gpu, is the
> > > "peer-to-peer" dma transfer something like: the game draw's to some
> > > memory it has allocated, then a DMA transfer gets that and moves it
> > > into the graphics card output?
> >
> > Peer to peer DMA just lets devices access another devices local memory
> > directly.  So if you have a buffer in vram on one device, you can
> > share that directly with another device rather than having to copy it
> > to system memory first.  For example, if you have two GPUs, you can
> > have one of them copy it's content directly to a buffer in the other
> > GPU's vram rather than having to go through system memory first.
> >
> > >
> > > also, i know it can be super annoying trying to debug an issue like
> > > this, with someone like me who has all types of differences from a
> > > normal setup (e.g. using it via egpu, using a kernel with custom
> > > configs and stuff) so as a token of my appreciation i donated 50$ to
> > > the red cross' corona virus outbreak charity thing, on behalf of
> > > amd-gfx.
> >
> > Thanks,
> >
> > Alex
> >
> > >
> > > On Tue, May 19, 2020 at 4:13 PM Alex Deucher  
> > > wrote:
> > > >
> > > > On Tue, May 19, 2020 at 3:44 PM Javad Karabi  
> > > > wrote:
> > > > >
> > > > > just a couple more questions:
> > > > >
> > > > > - based on what you are aware of, the technical details s

Re: slow rx 5600 xt fps

[Javad Karabi]

thanks for the answers alex.

so, i went ahead and got a displayport cable to see if that changes
anything. and now, when i run monitor only, and the monitor connected
to the card, it has no issues like before! so i am thinking that
somethings up with either the hdmi cable, or some hdmi related setting
in my system? who knows, but im just gonna roll with only using
displayport cables now.
the previous hdmi cable was actually pretty long, because i was
extending it with an hdmi extension cable, so maybe the signal was
really bad or something :/

but yea, i guess the only real issue now is maybe something simple
related to some sysfs entry about enabling some powermode, voltage,
clock frequency, or something, so that glxgears will give me more than
300 fps. but atleast now i can use a single monitor configuration with
the monitor displayported up to the card.

also, one other thing i think you might be interested in, that was
happening before.

so, previously, with laptop -tb3-> egpu-hdmi> monitor, there was a
funny thing happening which i never could figure out.
when i would look at the X logs, i would see that "modesetting" (for
the intel integrated graphics) was reporting that MonitorA was used
with "eDP-1",  which is correct and what i expected.
when i scrolled further down, i then saw that "HDMI-A-1-2" was being
used for another MonitorB, which also is what i expected (albeit i
have no idea why its saying A-1-2)
but amdgpu was _also_ saying that DisplayPort-1-2 (a port on the
radeon card) was being used for MonitorA, which is the same Monitor
that the modesetting driver had claimed to be using with eDP-1!

so the point is that amdgpu was "using" Monitor0 with DisplayPort-1-2,
although that is what modesetting was using for eDP-1.

anyway, thats a little aside, i doubt it was related to the terrible
hdmi experience i was getting, since its about display port and stuff,
but i thought id let you know about that.

if you think that is a possible issue, im more than happy to plug the
hdmi setup back in and create an issue on gitlab with the logs and
everything

On Tue, May 19, 2020 at 4:42 PM Alex Deucher  wrote:
>
> On Tue, May 19, 2020 at 5:22 PM Javad Karabi  wrote:
> >
> > lol youre quick!
> >
> > "Windows has supported peer to peer DMA for years so it already has a
> > numbers of optimizations that are only now becoming possible on Linux"
> >
> > whoa, i figured linux would be ahead of windows when it comes to
> > things like that. but peer-to-peer dma is something that is only
> > recently possible on linux, but has been possible on windows? what
> > changed recently that allows for peer to peer dma in linux?
> >
>
> A few things that made this more complicated on Linux:
> 1. Linux uses IOMMUs more extensively than windows so you can't just
> pass around physical bus addresses.
> 2. Linux supports lots of strange architectures that have a lot of
> limitations with respect to peer to peer transactions
>
> It just took years to get all the necessary bits in place in Linux and
> make everyone happy.
>
> > also, in the context of a game running opengl on some gpu, is the
> > "peer-to-peer" dma transfer something like: the game draw's to some
> > memory it has allocated, then a DMA transfer gets that and moves it
> > into the graphics card output?
>
> Peer to peer DMA just lets devices access another devices local memory
> directly.  So if you have a buffer in vram on one device, you can
> share that directly with another device rather than having to copy it
> to system memory first.  For example, if you have two GPUs, you can
> have one of them copy it's content directly to a buffer in the other
> GPU's vram rather than having to go through system memory first.
>
> >
> > also, i know it can be super annoying trying to debug an issue like
> > this, with someone like me who has all types of differences from a
> > normal setup (e.g. using it via egpu, using a kernel with custom
> > configs and stuff) so as a token of my appreciation i donated 50$ to
> > the red cross' corona virus outbreak charity thing, on behalf of
> > amd-gfx.
>
> Thanks,
>
> Alex
>
> >
> > On Tue, May 19, 2020 at 4:13 PM Alex Deucher  wrote:
> > >
> > > On Tue, May 19, 2020 at 3:44 PM Javad Karabi  
> > > wrote:
> > > >
> > > > just a couple more questions:
> > > >
> > > > - based on what you are aware of, the technical details such as
> > > > "shared buffers go through system memory", and all that, do you see
> > > > any issues that might exist that i might be missing in my setup? i
> > > > cant imagine this being the case because the card works great in
> > > > windows, unless the windows driver does something different?
> > > >
> > >
> > > Windows has supported peer to peer DMA for years so it already has a
> > > numbers of optimizations that are only now becoming possible on Linux.
> > >
> > > > - as far as kernel config, is there anything in particular which
> > > > _should_ or _should not_ be enabled/disabled?
> > >
> > > You'll nee

[PATCH v1 13/25] dma-buf: Use sequence counter with associated wound/wait mutex

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the sequence counter write side critical
section.

The dma-buf reservation subsystem uses plain sequence counters to manage
updates to reservations. Writer serialization is accomplished through a
wound/wait mutex.

Acquiring a wound/wait mutex does not disable preemption, so this needs
to be done manually before and after the write side critical section.

Use the newly-added seqcount_ww_mutex_t instead:

  - It associates the ww_mutex with the sequence count, which enables
lockdep to validate that the write side critical section is properly
serialized.

  - It removes the need to explicitly add preempt_disable/enable()
around the write side critical section because the write_begin/end()
functions for this new data type automatically do this.

If lockdep is disabled this ww_mutex lock association is compiled out
and has neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 drivers/dma-buf/dma-resv.c   | 8 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 --
 include/linux/dma-resv.h | 2 +-
 3 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 590ce7ad60a0..3aba2b2bfc48 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -128,7 +128,7 @@ subsys_initcall(dma_resv_lockdep);
 void dma_resv_init(struct dma_resv *obj)
 {
ww_mutex_init(&obj->lock, &reservation_ww_class);
-   seqcount_init(&obj->seq);
+   seqcount_ww_mutex_init(&obj->seq, &obj->lock);
 
RCU_INIT_POINTER(obj->fence, NULL);
RCU_INIT_POINTER(obj->fence_excl, NULL);
@@ -259,7 +259,6 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct 
dma_fence *fence)
fobj = dma_resv_get_list(obj);
count = fobj->shared_count;
 
-   preempt_disable();
write_seqcount_begin(&obj->seq);
 
for (i = 0; i < count; ++i) {
@@ -281,7 +280,6 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct 
dma_fence *fence)
smp_store_mb(fobj->shared_count, count);
 
write_seqcount_end(&obj->seq);
-   preempt_enable();
dma_fence_put(old);
 }
 EXPORT_SYMBOL(dma_resv_add_shared_fence);
@@ -308,14 +306,12 @@ void dma_resv_add_excl_fence(struct dma_resv *obj, struct 
dma_fence *fence)
if (fence)
dma_fence_get(fence);
 
-   preempt_disable();
write_seqcount_begin(&obj->seq);
/* write_seqcount_begin provides the necessary memory barrier */
RCU_INIT_POINTER(obj->fence_excl, fence);
if (old)
old->shared_count = 0;
write_seqcount_end(&obj->seq);
-   preempt_enable();
 
/* inplace update, no shared fences */
while (i--)
@@ -393,13 +389,11 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
dma_resv *src)
src_list = dma_resv_get_list(dst);
old = dma_resv_get_excl(dst);
 
-   preempt_disable();
write_seqcount_begin(&dst->seq);
/* write_seqcount_begin provides the necessary memory barrier */
RCU_INIT_POINTER(dst->fence_excl, new);
RCU_INIT_POINTER(dst->fence, dst_list);
write_seqcount_end(&dst->seq);
-   preempt_enable();
 
dma_resv_list_free(src_list);
dma_fence_put(old);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..87fd32aae8f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -258,11 +258,9 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct 
amdgpu_bo *bo,
new->shared_count = k;
 
/* Install the new fence list, seqcount provides the barriers */
-   preempt_disable();
write_seqcount_begin(&resv->seq);
RCU_INIT_POINTER(resv->fence, new);
write_seqcount_end(&resv->seq);
-   preempt_enable();
 
/* Drop the references to the removed fences or move them to ef_list */
for (i = j, k = 0; i < old->shared_count; ++i) {
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index a6538ae7d93f..d44a77e8a7e3 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -69,7 +69,7 @@ struct dma_resv_list {
  */
 struct dma_resv {
struct ww_mutex lock;
-   seqcount_t seq;
+   seqcount_ww_mutex_t seq;
 
struct dma_fence __rcu *fence_excl;
struct dma_resv_list __rcu *fence;
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu fix incorrect sysfs remove behavior for xgmi

[Zhang, Jack (Jian)]

[AMD Official Use Only - Internal Distribution Only]

ping

 Outlook for Android

From: Jack Zhang 
Sent: Monday, May 18, 2020 5:00:53 PM
To: amd-gfx@lists.freedesktop.org 
Cc: Zhang, Jack (Jian) 
Subject: [PATCH] drm/amdgpu fix incorrect sysfs remove behavior for xgmi

Under xgmi setup,some sysfs fail to create for the second time of kmd
driver loading. It's due to sysfs nodes are not removed appropriately
in the last unlod time.

Changes of this patch:
1. remove sysfs for dev_attr_xgmi_error
2. remove sysfs_link adev->dev->kobj with target name.
   And it only needs to be removed once for a xgmi setup
3. remove sysfs_link hive->kobj with target name

In amdgpu_xgmi_remove_device:
1. amdgpu_xgmi_sysfs_rem_dev_info needs to be run per device
2. amdgpu_xgmi_sysfs_destroy needs to be run on the last node of
device.

v2: initialize array with memset

Signed-off-by: Jack Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index e9e59bc..3b46ea8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -325,9 +325,19 @@ static int amdgpu_xgmi_sysfs_add_dev_info(struct 
amdgpu_device *adev,
 static void amdgpu_xgmi_sysfs_rem_dev_info(struct amdgpu_device *adev,
   struct amdgpu_hive_info *hive)
 {
+   char node[10];
+   memset(node, 0, sizeof(node));
+
 device_remove_file(adev->dev, &dev_attr_xgmi_device_id);
-   sysfs_remove_link(&adev->dev->kobj, adev->ddev->unique);
-   sysfs_remove_link(hive->kobj, adev->ddev->unique);
+   device_remove_file(adev->dev, &dev_attr_xgmi_error);
+
+   if (adev != hive->adev) {
+   sysfs_remove_link(&adev->dev->kobj,"xgmi_hive_info");
+   }
+
+   sprintf(node, "node%d", hive->number_devices);
+   sysfs_remove_link(hive->kobj, node);
+
 }


@@ -583,14 +593,14 @@ int amdgpu_xgmi_remove_device(struct amdgpu_device *adev)
 if (!hive)
 return -EINVAL;

-   if (!(hive->number_devices--)) {
+   task_barrier_rem_task(&hive->tb);
+   amdgpu_xgmi_sysfs_rem_dev_info(adev, hive);
+   mutex_unlock(&hive->hive_lock);
+
+   if(!(--hive->number_devices)){
 amdgpu_xgmi_sysfs_destroy(adev, hive);
 mutex_destroy(&hive->hive_lock);
 mutex_destroy(&hive->reset_lock);
-   } else {
-   task_barrier_rem_task(&hive->tb);
-   amdgpu_xgmi_sysfs_rem_dev_info(adev, hive);
-   mutex_unlock(&hive->hive_lock);
 }

 return psp_xgmi_terminate(&adev->psp);
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 2/2] drm/amdgpu/vcn2.5: Remove old DPG workaround

[Liu, Leo]

The 2 patches are:

Reviewed-by: Leo Liu 

-Original Message-
From: amd-gfx  On Behalf Of James Zhu
Sent: May 19, 2020 10:42 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, James 
Subject: [PATCH 2/2] drm/amdgpu/vcn2.5: Remove old DPG workaround

SCRATCH2 is used to keep decode wptr as a workaround which fix a hardware DPG 
decode wptr update bug for
vcn2.5 beforehand.

Signed-off-by: James Zhu 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
index 34ed906..3c6eafb 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
@@ -1453,11 +1453,6 @@ static int vcn_v2_5_pause_dpg_mode(struct amdgpu_device 
*adev,
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_WPTR2, 
lower_32_bits(ring->wptr));

fw_shared->multi_queue.encode_lowlatency_queue_mode &= ~FW_QUEUE_RING_RESET;
 
-   fw_shared->multi_queue.decode_queue_mode |= 
FW_QUEUE_RING_RESET;
-   WREG32_SOC15(VCN, inst_idx, mmUVD_RBC_RB_WPTR,
-  RREG32_SOC15(VCN, inst_idx, 
mmUVD_SCRATCH2) & 0x7FFF);
-   fw_shared->multi_queue.decode_queue_mode &= 
~FW_QUEUE_RING_RESET;
-
/* Unstall DPG */
WREG32_P(SOC15_REG_OFFSET(VCN, inst_idx, 
mmUVD_POWER_STATUS),
   0, 
~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK);
@@ -1519,10 +1514,6 @@ static void vcn_v2_5_dec_ring_set_wptr(struct 
amdgpu_ring *ring)  {
struct amdgpu_device *adev = ring->adev;
 
-   if (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG)
-   WREG32_SOC15(VCN, ring->me, mmUVD_SCRATCH2,
-   lower_32_bits(ring->wptr) | 0x8000);
-
if (ring->use_doorbell) {
adev->wb.wb[ring->wptr_offs] = lower_32_bits(ring->wptr);
WDOORBELL32(ring->doorbell_index, lower_32_bits(ring->wptr));
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cleo.liu%40amd.com%7C285abea632d14d797dc808d7fc02c54d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254961773506391&sdata=isg1c3TJ392Qeos%2ByhO4zopT3Y%2BWA4G9VGKBd1pLT8M%3D&reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu/smu10: Replace one-element array and use struct_size() helper

[Gustavo A. R. Silva]

The current codebase makes use of one-element arrays in the following
form:

struct something {
int length;
u8 data[1];
};

struct something *instance;

instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);

but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:

struct foo {
int stuff;
struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.

Also, make use of the new struct_size() helper to properly calculate the
size of struct smu10_voltage_dependency_table.

This issue was found with the help of Coccinelle and, audited and fixed
_manually_.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 6 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 246bb9ac557d8..c9cfe90a29471 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -410,12 +410,10 @@ static int 
smu10_get_clock_voltage_dependency_table(struct pp_hwmgr *hwmgr,
struct smu10_voltage_dependency_table **pptable,
uint32_t num_entry, const DpmClock_t 
*pclk_dependency_table)
 {
-   uint32_t table_size, i;
+   uint32_t i;
struct smu10_voltage_dependency_table *ptable;
 
-   table_size = sizeof(uint32_t) + sizeof(struct 
smu10_voltage_dependency_table) * num_entry;
-   ptable = kzalloc(table_size, GFP_KERNEL);
-
+   ptable = kzalloc(struct_size(ptable, entries, num_entry), GFP_KERNEL);
if (NULL == ptable)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h
index 1fb296a996f3a..0f969de10fabc 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h
@@ -192,7 +192,7 @@ struct smu10_clock_voltage_dependency_record {
 
 struct smu10_voltage_dependency_table {
uint32_t count;
-   struct smu10_clock_voltage_dependency_record entries[1];
+   struct smu10_clock_voltage_dependency_record entries[];
 };
 
 struct smu10_clock_voltage_information {
-- 
2.26.2

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] dma-fence: add might_sleep annotation to _wait()

[Chris Wilson]

Quoting Daniel Vetter (2020-05-19 14:27:56)
> Do it uncontionally, there's a separate peek function with
> dma_fence_is_signalled() which can be called from atomic context.
> 
> v2: Consensus calls for an unconditional might_sleep (Chris,
> Christian)
> 
> Full audit:
> - dma-fence.h: Uses MAX_SCHEDULE_TIMOUT, good chance this sleeps
> - dma-resv.c: Timeout always at least 1
> - st-dma-fence.c: Save to sleep in testcases
> - amdgpu_cs.c: Both callers are for variants of the wait ioctl
> - amdgpu_device.c: Two callers in vram recover code, both right next
>   to mutex_lock.
> - amdgpu_vm.c: Use in the vm_wait ioctl, next to _reserve/unreserve
> - remaining functions in amdgpu: All for test_ib implementations for
>   various engines, caller for that looks all safe (debugfs, driver
>   load, reset)
> - etnaviv: another wait ioctl
> - habanalabs: another wait ioctl
> - nouveau_fence.c: hardcoded 15*HZ ... glorious
> - nouveau_gem.c: hardcoded 2*HZ ... so not even super consistent, but
>   this one does have a WARN_ON :-/ At least this one is only a
>   fallback path for when kmalloc fails. Maybe this should be put onto
>   some worker list instead, instead of a work per unamp ...
> - i915/selftests: Hardecoded HZ / 4 or HZ / 8
> - i915/gt/selftests: Going up the callchain looks safe looking at
>   nearby callers
> - i915/gt/intel_gt_requests.c. Wrapped in a mutex_lock
> - i915/gem_i915_gem_wait.c: The i915-version which is called instead
>   for i915 fences already has a might_sleep() annotation, so all good
> 
> Cc: Alex Deucher 
> Cc: Lucas Stach 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Ben Skeggs 
> Cc: "VMware Graphics" 
> Cc: Oded Gabbay 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-gfx@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/dma-buf/dma-fence.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 90edf2b281b0..656e9ac2d028 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -208,6 +208,8 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool 
> intr, signed long timeout)
> if (WARN_ON(timeout < 0))
> return -EINVAL;
>  
> +   might_sleep();

git grep matches your synopsis.

Reviewed-by: Chris Wilson 
-Chris
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: slow rx 5600 xt fps

[Alex Deucher]

On Tue, May 19, 2020 at 5:22 PM Javad Karabi  wrote:
>
> lol youre quick!
>
> "Windows has supported peer to peer DMA for years so it already has a
> numbers of optimizations that are only now becoming possible on Linux"
>
> whoa, i figured linux would be ahead of windows when it comes to
> things like that. but peer-to-peer dma is something that is only
> recently possible on linux, but has been possible on windows? what
> changed recently that allows for peer to peer dma in linux?
>

A few things that made this more complicated on Linux:
1. Linux uses IOMMUs more extensively than windows so you can't just
pass around physical bus addresses.
2. Linux supports lots of strange architectures that have a lot of
limitations with respect to peer to peer transactions

It just took years to get all the necessary bits in place in Linux and
make everyone happy.

> also, in the context of a game running opengl on some gpu, is the
> "peer-to-peer" dma transfer something like: the game draw's to some
> memory it has allocated, then a DMA transfer gets that and moves it
> into the graphics card output?

Peer to peer DMA just lets devices access another devices local memory
directly.  So if you have a buffer in vram on one device, you can
share that directly with another device rather than having to copy it
to system memory first.  For example, if you have two GPUs, you can
have one of them copy it's content directly to a buffer in the other
GPU's vram rather than having to go through system memory first.

>
> also, i know it can be super annoying trying to debug an issue like
> this, with someone like me who has all types of differences from a
> normal setup (e.g. using it via egpu, using a kernel with custom
> configs and stuff) so as a token of my appreciation i donated 50$ to
> the red cross' corona virus outbreak charity thing, on behalf of
> amd-gfx.

Thanks,

Alex

>
> On Tue, May 19, 2020 at 4:13 PM Alex Deucher  wrote:
> >
> > On Tue, May 19, 2020 at 3:44 PM Javad Karabi  wrote:
> > >
> > > just a couple more questions:
> > >
> > > - based on what you are aware of, the technical details such as
> > > "shared buffers go through system memory", and all that, do you see
> > > any issues that might exist that i might be missing in my setup? i
> > > cant imagine this being the case because the card works great in
> > > windows, unless the windows driver does something different?
> > >
> >
> > Windows has supported peer to peer DMA for years so it already has a
> > numbers of optimizations that are only now becoming possible on Linux.
> >
> > > - as far as kernel config, is there anything in particular which
> > > _should_ or _should not_ be enabled/disabled?
> >
> > You'll need the GPU drivers for your devices and dma-buf support.
> >
> > >
> > > - does the vendor matter? for instance, this is an xfx card. when it
> > > comes to different vendors, are there interface changes that might
> > > make one vendor work better for linux than another? i dont really
> > > understand the differences in vendors, but i imagine that the vbios
> > > differs between vendors, and as such, the linux compatibility would
> > > maybe change?
> >
> > board vendor shouldn't matter.
> >
> > >
> > > - is the pcie bandwidth possible an issue? the pcie_bw file changes
> > > between values like this:
> > > 18446683600662707640 18446744071581623085 128
> > > and sometimes i see this:
> > > 4096 0 128
> > > as you can see, the second value seems significantly lower. is that
> > > possibly an issue? possibly due to aspm?
> >
> > pcie_bw is not implemented for navi yet so you are just seeing
> > uninitialized data.  This patch set should clear that up.
> > https://patchwork.freedesktop.org/patch/366262/
> >
> > Alex
> >
> > >
> > > On Tue, May 19, 2020 at 2:20 PM Javad Karabi  
> > > wrote:
> > > >
> > > > im using Driver "amdgpu" in my xorg conf
> > > >
> > > > how does one verify which gpu is the primary? im assuming my intel
> > > > card is the primary, since i have not done anything to change that.
> > > >
> > > > also, if all shared buffers have to go through system memory, then
> > > > that means an eGPU amdgpu wont work very well in general right?
> > > > because going through system memory for the egpu means going over the
> > > > thunderbolt connection
> > > >
> > > > and what are the shared buffers youre referring to? for example, if an
> > > > application is drawing to a buffer, is that an example of a shared
> > > > buffer that has to go through system memory? if so, thats fine, right?
> > > > because the application's memory is in system memory, so that copy
> > > > wouldnt be an issue.
> > > >
> > > > in general, do you think the "copy buffer across system memory might
> > > > be a hindrance for thunderbolt? im trying to figure out which
> > > > directions to go to debug and im totally lost, so maybe i can do some
> > > > testing that direction?
> > > >
> > > > and for what its worth, when i turn the display "off" via the gnome
> > >

Re: slow rx 5600 xt fps

[Alex Deucher]

On Tue, May 19, 2020 at 4:01 PM Javad Karabi  wrote:
>
> another tidbit:
> when in linux, the gpu's fans _never_ come on.
>
> even when i run 4 instances of glmark2, the fans do not come on :/
> i see the temp hitting just below 50 deg c, and i saw some value that
> says that 50c was the max?
> isnt 50c low for a max gpu temp?
>

Maybe you are not using the dGPU for most things.  Use something like
glxinfo to figure out which GPU you are using for different
situations.  E.g.,
glxinfo | grep renderer
vs
DRI_PRIME=1 glxinfo | grep renderer

Alex

>
> On Tue, May 19, 2020 at 2:44 PM Javad Karabi  wrote:
> >
> > just a couple more questions:
> >
> > - based on what you are aware of, the technical details such as
> > "shared buffers go through system memory", and all that, do you see
> > any issues that might exist that i might be missing in my setup? i
> > cant imagine this being the case because the card works great in
> > windows, unless the windows driver does something different?
> >
> > - as far as kernel config, is there anything in particular which
> > _should_ or _should not_ be enabled/disabled?
> >
> > - does the vendor matter? for instance, this is an xfx card. when it
> > comes to different vendors, are there interface changes that might
> > make one vendor work better for linux than another? i dont really
> > understand the differences in vendors, but i imagine that the vbios
> > differs between vendors, and as such, the linux compatibility would
> > maybe change?
> >
> > - is the pcie bandwidth possible an issue? the pcie_bw file changes
> > between values like this:
> > 18446683600662707640 18446744071581623085 128
> > and sometimes i see this:
> > 4096 0 128
> > as you can see, the second value seems significantly lower. is that
> > possibly an issue? possibly due to aspm?
> >
> > On Tue, May 19, 2020 at 2:20 PM Javad Karabi  wrote:
> > >
> > > im using Driver "amdgpu" in my xorg conf
> > >
> > > how does one verify which gpu is the primary? im assuming my intel
> > > card is the primary, since i have not done anything to change that.
> > >
> > > also, if all shared buffers have to go through system memory, then
> > > that means an eGPU amdgpu wont work very well in general right?
> > > because going through system memory for the egpu means going over the
> > > thunderbolt connection
> > >
> > > and what are the shared buffers youre referring to? for example, if an
> > > application is drawing to a buffer, is that an example of a shared
> > > buffer that has to go through system memory? if so, thats fine, right?
> > > because the application's memory is in system memory, so that copy
> > > wouldnt be an issue.
> > >
> > > in general, do you think the "copy buffer across system memory might
> > > be a hindrance for thunderbolt? im trying to figure out which
> > > directions to go to debug and im totally lost, so maybe i can do some
> > > testing that direction?
> > >
> > > and for what its worth, when i turn the display "off" via the gnome
> > > display settings, its the same issue as when the laptop lid is closed,
> > > so unless the motherboard reads the "closed lid" the same as "display
> > > off", then im not sure if its thermal issues.
> > >
> > > On Tue, May 19, 2020 at 2:14 PM Alex Deucher  
> > > wrote:
> > > >
> > > > On Tue, May 19, 2020 at 2:59 PM Javad Karabi  
> > > > wrote:
> > > > >
> > > > > given this setup:
> > > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> 
> > > > > monitor
> > > > > DRI_PRIME=1 glxgears gears gives me ~300fps
> > > > >
> > > > > given this setup:
> > > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
> > > > > laptop -hdmi-> monitor
> > > > >
> > > > > glx gears gives me ~1800fps
> > > > >
> > > > > this doesnt make sense to me because i thought that having the monitor
> > > > > plugged directly into the card should give best performance.
> > > > >
> > > >
> > > > Do you have displays connected to both GPUs?  If you are using X which
> > > > ddx are you using?  xf86-video-modesetting or xf86-video-amdgpu?
> > > > IIRC, xf86-video-amdgpu has some optimizations for prime which are not
> > > > yet in xf86-video-modesetting.  Which GPU is set up as the primary?
> > > > Note that the GPU which does the rendering is not necessarily the one
> > > > that the displays are attached to.  The render GPU renders to it's
> > > > render buffer and then that data may end up being copied other GPUs
> > > > for display.  Also, at this point, all shared buffers have to go
> > > > through system memory (this will be changing eventually now that we
> > > > support device memory via dma-buf), so there is often an extra copy
> > > > involved.
> > > >
> > > > > theres another really weird issue...
> > > > >
> > > > > given setup 1, where the monitor is plugged in to the card:
> > > > > when i close the laptop lid, my monitor is "active" and whatnot, and i
> > > > > can "use it" in a sense
> > > > >
> > > > > however, heres the weirdness:
> > 

Re: slow rx 5600 xt fps

[Alex Deucher]

On Tue, May 19, 2020 at 3:20 PM Javad Karabi  wrote:
>
> im using Driver "amdgpu" in my xorg conf
>
> how does one verify which gpu is the primary? im assuming my intel
> card is the primary, since i have not done anything to change that.
>

Check your xorg log.

> also, if all shared buffers have to go through system memory, then
> that means an eGPU amdgpu wont work very well in general right?
> because going through system memory for the egpu means going over the
> thunderbolt connection

If you want to render on the dGPU and display on the integrated GPU,
then the content will have to traverse the bus.

>
> and what are the shared buffers youre referring to? for example, if an
> application is drawing to a buffer, is that an example of a shared
> buffer that has to go through system memory? if so, thats fine, right?
> because the application's memory is in system memory, so that copy
> wouldnt be an issue.

For optimal performance, dGPUs will want to render to local vram.  So
when a dGPU is rendering it will render to a buffer in vram.  However,
if the display is connected to the integrated GPU, it can't directly
access the buffer in the dGPU's vram.  In order to transfer the buffer
from the dGPU to the integrated GPU for display, it has to be copied
from vram to buffer in system memory.  This buffer is then shared with
the integrated GPU.  Depending on the integrated GPU's capabilities,
it may be able to use the buffer as is, or it may have to copy the
buffer again to a buffer that it can display from.

>
> in general, do you think the "copy buffer across system memory might
> be a hindrance for thunderbolt? im trying to figure out which
> directions to go to debug and im totally lost, so maybe i can do some
> testing that direction?

If you are mainly concerned with checking the performance of the the
dGPU itself (where the dGPU handles display and rendering), I would
make sure your desktop environment is configured to be running on the
dGPU only.  Take the integrated GPU out of the picture.

>
> and for what its worth, when i turn the display "off" via the gnome
> display settings, its the same issue as when the laptop lid is closed,
> so unless the motherboard reads the "closed lid" the same as "display
> off", then im not sure if its thermal issues.

If the integrated GPU is the primary display, turning the displays off
or closing the lid may signal to the integarted GPU driver that it's
not in use so it can power down.  So it may go to a lower power state
which has a relatively high exit latency.  Every time a copy is
required the integrated GPU has to wake up and do the copy.  The copy
is probably not necessary, but I'm not sure how well optimized most
display servers are in this regard.  Really if all the displays on one
GPU are off and the display server should fallback to same GPU render
and display, but I'm not sure how well this is handled.  The current
multi-GPU support in X is mostly focused on the following two use
cases:
1. Hybrid graphics, where you have a integrated GPU which handles
displays and you have a dGPU which is mainly for render offload.  The
render GPU renders content and it it shared with the display GPU.
2. Multi-GPU displays, where you have a large desktop spread across
multiple GPUs.  The render GPU renders content and it is shared with
the display GPUs.

Alex


>
> On Tue, May 19, 2020 at 2:14 PM Alex Deucher  wrote:
> >
> > On Tue, May 19, 2020 at 2:59 PM Javad Karabi  wrote:
> > >
> > > given this setup:
> > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> monitor
> > > DRI_PRIME=1 glxgears gears gives me ~300fps
> > >
> > > given this setup:
> > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
> > > laptop -hdmi-> monitor
> > >
> > > glx gears gives me ~1800fps
> > >
> > > this doesnt make sense to me because i thought that having the monitor
> > > plugged directly into the card should give best performance.
> > >
> >
> > Do you have displays connected to both GPUs?  If you are using X which
> > ddx are you using?  xf86-video-modesetting or xf86-video-amdgpu?
> > IIRC, xf86-video-amdgpu has some optimizations for prime which are not
> > yet in xf86-video-modesetting.  Which GPU is set up as the primary?
> > Note that the GPU which does the rendering is not necessarily the one
> > that the displays are attached to.  The render GPU renders to it's
> > render buffer and then that data may end up being copied other GPUs
> > for display.  Also, at this point, all shared buffers have to go
> > through system memory (this will be changing eventually now that we
> > support device memory via dma-buf), so there is often an extra copy
> > involved.
> >
> > > theres another really weird issue...
> > >
> > > given setup 1, where the monitor is plugged in to the card:
> > > when i close the laptop lid, my monitor is "active" and whatnot, and i
> > > can "use it" in a sense
> > >
> > > however, heres the weirdness:
> > > the mouse cursor will move 

Re: slow rx 5600 xt fps

[Javad Karabi]

lol youre quick!

"Windows has supported peer to peer DMA for years so it already has a
numbers of optimizations that are only now becoming possible on Linux"

whoa, i figured linux would be ahead of windows when it comes to
things like that. but peer-to-peer dma is something that is only
recently possible on linux, but has been possible on windows? what
changed recently that allows for peer to peer dma in linux?

also, in the context of a game running opengl on some gpu, is the
"peer-to-peer" dma transfer something like: the game draw's to some
memory it has allocated, then a DMA transfer gets that and moves it
into the graphics card output?

also, i know it can be super annoying trying to debug an issue like
this, with someone like me who has all types of differences from a
normal setup (e.g. using it via egpu, using a kernel with custom
configs and stuff) so as a token of my appreciation i donated 50$ to
the red cross' corona virus outbreak charity thing, on behalf of
amd-gfx.

On Tue, May 19, 2020 at 4:13 PM Alex Deucher  wrote:
>
> On Tue, May 19, 2020 at 3:44 PM Javad Karabi  wrote:
> >
> > just a couple more questions:
> >
> > - based on what you are aware of, the technical details such as
> > "shared buffers go through system memory", and all that, do you see
> > any issues that might exist that i might be missing in my setup? i
> > cant imagine this being the case because the card works great in
> > windows, unless the windows driver does something different?
> >
>
> Windows has supported peer to peer DMA for years so it already has a
> numbers of optimizations that are only now becoming possible on Linux.
>
> > - as far as kernel config, is there anything in particular which
> > _should_ or _should not_ be enabled/disabled?
>
> You'll need the GPU drivers for your devices and dma-buf support.
>
> >
> > - does the vendor matter? for instance, this is an xfx card. when it
> > comes to different vendors, are there interface changes that might
> > make one vendor work better for linux than another? i dont really
> > understand the differences in vendors, but i imagine that the vbios
> > differs between vendors, and as such, the linux compatibility would
> > maybe change?
>
> board vendor shouldn't matter.
>
> >
> > - is the pcie bandwidth possible an issue? the pcie_bw file changes
> > between values like this:
> > 18446683600662707640 18446744071581623085 128
> > and sometimes i see this:
> > 4096 0 128
> > as you can see, the second value seems significantly lower. is that
> > possibly an issue? possibly due to aspm?
>
> pcie_bw is not implemented for navi yet so you are just seeing
> uninitialized data.  This patch set should clear that up.
> https://patchwork.freedesktop.org/patch/366262/
>
> Alex
>
> >
> > On Tue, May 19, 2020 at 2:20 PM Javad Karabi  wrote:
> > >
> > > im using Driver "amdgpu" in my xorg conf
> > >
> > > how does one verify which gpu is the primary? im assuming my intel
> > > card is the primary, since i have not done anything to change that.
> > >
> > > also, if all shared buffers have to go through system memory, then
> > > that means an eGPU amdgpu wont work very well in general right?
> > > because going through system memory for the egpu means going over the
> > > thunderbolt connection
> > >
> > > and what are the shared buffers youre referring to? for example, if an
> > > application is drawing to a buffer, is that an example of a shared
> > > buffer that has to go through system memory? if so, thats fine, right?
> > > because the application's memory is in system memory, so that copy
> > > wouldnt be an issue.
> > >
> > > in general, do you think the "copy buffer across system memory might
> > > be a hindrance for thunderbolt? im trying to figure out which
> > > directions to go to debug and im totally lost, so maybe i can do some
> > > testing that direction?
> > >
> > > and for what its worth, when i turn the display "off" via the gnome
> > > display settings, its the same issue as when the laptop lid is closed,
> > > so unless the motherboard reads the "closed lid" the same as "display
> > > off", then im not sure if its thermal issues.
> > >
> > > On Tue, May 19, 2020 at 2:14 PM Alex Deucher  
> > > wrote:
> > > >
> > > > On Tue, May 19, 2020 at 2:59 PM Javad Karabi  
> > > > wrote:
> > > > >
> > > > > given this setup:
> > > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> 
> > > > > monitor
> > > > > DRI_PRIME=1 glxgears gears gives me ~300fps
> > > > >
> > > > > given this setup:
> > > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
> > > > > laptop -hdmi-> monitor
> > > > >
> > > > > glx gears gives me ~1800fps
> > > > >
> > > > > this doesnt make sense to me because i thought that having the monitor
> > > > > plugged directly into the card should give best performance.
> > > > >
> > > >
> > > > Do you have displays connected to both GPUs?  If you are using X which
> > > > ddx are you using?  xf86-video-modesetting or xf86-vi

Re: slow rx 5600 xt fps

[Alex Deucher]

On Tue, May 19, 2020 at 3:44 PM Javad Karabi  wrote:
>
> just a couple more questions:
>
> - based on what you are aware of, the technical details such as
> "shared buffers go through system memory", and all that, do you see
> any issues that might exist that i might be missing in my setup? i
> cant imagine this being the case because the card works great in
> windows, unless the windows driver does something different?
>

Windows has supported peer to peer DMA for years so it already has a
numbers of optimizations that are only now becoming possible on Linux.

> - as far as kernel config, is there anything in particular which
> _should_ or _should not_ be enabled/disabled?

You'll need the GPU drivers for your devices and dma-buf support.

>
> - does the vendor matter? for instance, this is an xfx card. when it
> comes to different vendors, are there interface changes that might
> make one vendor work better for linux than another? i dont really
> understand the differences in vendors, but i imagine that the vbios
> differs between vendors, and as such, the linux compatibility would
> maybe change?

board vendor shouldn't matter.

>
> - is the pcie bandwidth possible an issue? the pcie_bw file changes
> between values like this:
> 18446683600662707640 18446744071581623085 128
> and sometimes i see this:
> 4096 0 128
> as you can see, the second value seems significantly lower. is that
> possibly an issue? possibly due to aspm?

pcie_bw is not implemented for navi yet so you are just seeing
uninitialized data.  This patch set should clear that up.
https://patchwork.freedesktop.org/patch/366262/

Alex

>
> On Tue, May 19, 2020 at 2:20 PM Javad Karabi  wrote:
> >
> > im using Driver "amdgpu" in my xorg conf
> >
> > how does one verify which gpu is the primary? im assuming my intel
> > card is the primary, since i have not done anything to change that.
> >
> > also, if all shared buffers have to go through system memory, then
> > that means an eGPU amdgpu wont work very well in general right?
> > because going through system memory for the egpu means going over the
> > thunderbolt connection
> >
> > and what are the shared buffers youre referring to? for example, if an
> > application is drawing to a buffer, is that an example of a shared
> > buffer that has to go through system memory? if so, thats fine, right?
> > because the application's memory is in system memory, so that copy
> > wouldnt be an issue.
> >
> > in general, do you think the "copy buffer across system memory might
> > be a hindrance for thunderbolt? im trying to figure out which
> > directions to go to debug and im totally lost, so maybe i can do some
> > testing that direction?
> >
> > and for what its worth, when i turn the display "off" via the gnome
> > display settings, its the same issue as when the laptop lid is closed,
> > so unless the motherboard reads the "closed lid" the same as "display
> > off", then im not sure if its thermal issues.
> >
> > On Tue, May 19, 2020 at 2:14 PM Alex Deucher  wrote:
> > >
> > > On Tue, May 19, 2020 at 2:59 PM Javad Karabi  
> > > wrote:
> > > >
> > > > given this setup:
> > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> 
> > > > monitor
> > > > DRI_PRIME=1 glxgears gears gives me ~300fps
> > > >
> > > > given this setup:
> > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
> > > > laptop -hdmi-> monitor
> > > >
> > > > glx gears gives me ~1800fps
> > > >
> > > > this doesnt make sense to me because i thought that having the monitor
> > > > plugged directly into the card should give best performance.
> > > >
> > >
> > > Do you have displays connected to both GPUs?  If you are using X which
> > > ddx are you using?  xf86-video-modesetting or xf86-video-amdgpu?
> > > IIRC, xf86-video-amdgpu has some optimizations for prime which are not
> > > yet in xf86-video-modesetting.  Which GPU is set up as the primary?
> > > Note that the GPU which does the rendering is not necessarily the one
> > > that the displays are attached to.  The render GPU renders to it's
> > > render buffer and then that data may end up being copied other GPUs
> > > for display.  Also, at this point, all shared buffers have to go
> > > through system memory (this will be changing eventually now that we
> > > support device memory via dma-buf), so there is often an extra copy
> > > involved.
> > >
> > > > theres another really weird issue...
> > > >
> > > > given setup 1, where the monitor is plugged in to the card:
> > > > when i close the laptop lid, my monitor is "active" and whatnot, and i
> > > > can "use it" in a sense
> > > >
> > > > however, heres the weirdness:
> > > > the mouse cursor will move along the monitor perfectly smooth and
> > > > fine, but all the other updates to the screen are delayed by about 2
> > > > or 3 seconds.
> > > > that is to say, its as if the laptop is doing everything (e.g. if i
> > > > open a terminal, the terminal will open, but it will take 2 seconds
> > > > f

[PATCH 2/2] drm/amdgpu: drop navi pcie bw callback

[Alex Deucher]

It's not implemented yet so just drop it so the sysfs
pcie bw file returns an appropriate error instead of
garbage.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/nv.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 9c42316c47c0..6655dd2009b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -548,13 +548,6 @@ static bool nv_need_full_reset(struct amdgpu_device *adev)
return true;
 }
 
-static void nv_get_pcie_usage(struct amdgpu_device *adev,
- uint64_t *count0,
- uint64_t *count1)
-{
-   /*TODO*/
-}
-
 static bool nv_need_reset_on_init(struct amdgpu_device *adev)
 {
 #if 0
@@ -629,7 +622,6 @@ static const struct amdgpu_asic_funcs nv_asic_funcs =
.invalidate_hdp = &nv_invalidate_hdp,
.init_doorbell_index = &nv_init_doorbell_index,
.need_full_reset = &nv_need_full_reset,
-   .get_pcie_usage = &nv_get_pcie_usage,
.need_reset_on_init = &nv_need_reset_on_init,
.get_pcie_replay_count = &nv_get_pcie_replay_count,
.supports_baco = &nv_asic_supports_baco,
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amdgpu: improve error handling in pcie_bw

[Alex Deucher]

1. Initialize the counters to 0 in case the callback
   fails to initialize them.
2. The counters don't exist on APUs so return an error
   for them.
3. Return an error if the callback doesn't exist.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index bc7de2f62d12..72bbb8175b22 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1646,9 +1646,15 @@ static ssize_t amdgpu_get_pcie_bw(struct device *dev,
 {
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = ddev->dev_private;
-   uint64_t count0, count1;
+   uint64_t count0 = 0, count1 = 0;
int ret;
 
+   if (adev->flags & AMD_IS_APU)
+   return -ENODATA;
+
+   if (!adev->asic_funcs->get_pcie_usage)
+   return -ENODATA;
+
ret = pm_runtime_get_sync(ddev->dev);
if (ret < 0)
return ret;
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[pull] amdgpu drm-next-5.8

[Alex Deucher]

Hi Dave, Daniel,

Last few bits for 5.8.

The following changes since commit 80c9b58e9503f33a707a23172b2dd8d015b8c036:

  Merge tag 'du-next-20200514' of git://linuxtv.org/pinchartl/media into 
drm-next (2020-05-14 13:41:51 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.8-2020-05-19

for you to fetch changes up to 43c8546bcd854806736d8a635a0d696504dd4c21:

  drm/amdgpu: Add a UAPI flag for user to call mem_sync (2020-05-18 11:24:21 
-0400)


amd-drm-next-5.8-2020-05-19:

amdgpu:
- Improved handling for CTF (Critical Thermal Fault) situations
- Clarify AC/DC mode switches
- SR-IOV fixes
- XGMI fixes for RAS
- Misc cleanups
- Add autodump debugfs node to aid in GPU hang debugging

UAPI:
- Add a MEM_SYNC IB flag for handling proper acquire memory semantics if UMDs 
expect the kernel to handle this
  Used by AMDVLK: 
https://github.com/GPUOpen-Drivers/pal/blob/dev/src/core/os/amdgpu/amdgpuQueue.cpp#L1262


Andrey Grodzovsky (4):
  drm/amdgpu: Add AQUIRE_MEM PACKET3 fields defintion
  drm/amdgpu: Add new ring callback to insert memory sync
  drm/amdgpu: Add mem_sync implementation for all the ASICs.
  drm/amdgpu: Add a UAPI flag for user to call mem_sync

Colin Ian King (1):
  drm/amdgpu: remove redundant assignment to variable ret

Evan Quan (3):
  drm/amd/powerplay: try to do a graceful shutdown on SW CTF
  drm/amd/powerplay: shutdown on HW CTF
  drm/amd/powerplay: report correct AC/DC event based on ctxid V2

Jiange Zhao (1):
  drm/amdgpu: Add autodump debugfs node for gpu reset v8

John Clements (4):
  drm/amdgpu: Add cmd to control XGMI link sleep
  drm/amdgpu: Add DPM function for XGMI link power down control
  drm/amdgpu: Update RAS XGMI error inject sequence
  drm/amdgpu: Updated XGMI power down control support check

Kevin Wang (2):
  drm/amdgpu: add amdgpu_virt_get_vf_mode helper function
  drm/amdgpu: optimize amdgpu device attribute code

Marek Olšák (1):
  drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too (v3)

Yintian Tao (1):
  drm/amdgpu: turn back rlcg write for gfx_v10

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c|  78 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h|   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c|  10 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h|   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 494 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h |  46 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c|  30 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   |  16 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h   |   8 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   |   2 +-
 drivers/gpu/drm/amd/amdgpu/cikd.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  45 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  20 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  34 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  36 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  27 +-
 drivers/gpu/drm/amd/amdgpu/nvd.h   |  48 ++
 drivers/gpu/drm/amd/amdgpu/soc15d.h|  25 +-
 drivers/gpu/drm/amd/amdgpu/vid.h   |   2 +-
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c |  22 +
 drivers/gpu/drm/amd/powerplay/arcturus_ppt.c   |  31 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c   |  37 +-
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |   2 +
 drivers/gpu/drm/amd/powerplay/inc/arcturus_ppsmc.h |   3 +-
 drivers/gpu/drm/amd/powerplay/inc/smu_types.h  |   1 +
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c  |  46 +-
 include/uapi/drm/amdgpu_drm.h  |   4 +
 32 files changed, 775 insertions(+), 313 deletions(-)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: slow rx 5600 xt fps

[Javad Karabi]

another tidbit:
when in linux, the gpu's fans _never_ come on.

even when i run 4 instances of glmark2, the fans do not come on :/
i see the temp hitting just below 50 deg c, and i saw some value that
says that 50c was the max?
isnt 50c low for a max gpu temp?


On Tue, May 19, 2020 at 2:44 PM Javad Karabi  wrote:
>
> just a couple more questions:
>
> - based on what you are aware of, the technical details such as
> "shared buffers go through system memory", and all that, do you see
> any issues that might exist that i might be missing in my setup? i
> cant imagine this being the case because the card works great in
> windows, unless the windows driver does something different?
>
> - as far as kernel config, is there anything in particular which
> _should_ or _should not_ be enabled/disabled?
>
> - does the vendor matter? for instance, this is an xfx card. when it
> comes to different vendors, are there interface changes that might
> make one vendor work better for linux than another? i dont really
> understand the differences in vendors, but i imagine that the vbios
> differs between vendors, and as such, the linux compatibility would
> maybe change?
>
> - is the pcie bandwidth possible an issue? the pcie_bw file changes
> between values like this:
> 18446683600662707640 18446744071581623085 128
> and sometimes i see this:
> 4096 0 128
> as you can see, the second value seems significantly lower. is that
> possibly an issue? possibly due to aspm?
>
> On Tue, May 19, 2020 at 2:20 PM Javad Karabi  wrote:
> >
> > im using Driver "amdgpu" in my xorg conf
> >
> > how does one verify which gpu is the primary? im assuming my intel
> > card is the primary, since i have not done anything to change that.
> >
> > also, if all shared buffers have to go through system memory, then
> > that means an eGPU amdgpu wont work very well in general right?
> > because going through system memory for the egpu means going over the
> > thunderbolt connection
> >
> > and what are the shared buffers youre referring to? for example, if an
> > application is drawing to a buffer, is that an example of a shared
> > buffer that has to go through system memory? if so, thats fine, right?
> > because the application's memory is in system memory, so that copy
> > wouldnt be an issue.
> >
> > in general, do you think the "copy buffer across system memory might
> > be a hindrance for thunderbolt? im trying to figure out which
> > directions to go to debug and im totally lost, so maybe i can do some
> > testing that direction?
> >
> > and for what its worth, when i turn the display "off" via the gnome
> > display settings, its the same issue as when the laptop lid is closed,
> > so unless the motherboard reads the "closed lid" the same as "display
> > off", then im not sure if its thermal issues.
> >
> > On Tue, May 19, 2020 at 2:14 PM Alex Deucher  wrote:
> > >
> > > On Tue, May 19, 2020 at 2:59 PM Javad Karabi  
> > > wrote:
> > > >
> > > > given this setup:
> > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> 
> > > > monitor
> > > > DRI_PRIME=1 glxgears gears gives me ~300fps
> > > >
> > > > given this setup:
> > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
> > > > laptop -hdmi-> monitor
> > > >
> > > > glx gears gives me ~1800fps
> > > >
> > > > this doesnt make sense to me because i thought that having the monitor
> > > > plugged directly into the card should give best performance.
> > > >
> > >
> > > Do you have displays connected to both GPUs?  If you are using X which
> > > ddx are you using?  xf86-video-modesetting or xf86-video-amdgpu?
> > > IIRC, xf86-video-amdgpu has some optimizations for prime which are not
> > > yet in xf86-video-modesetting.  Which GPU is set up as the primary?
> > > Note that the GPU which does the rendering is not necessarily the one
> > > that the displays are attached to.  The render GPU renders to it's
> > > render buffer and then that data may end up being copied other GPUs
> > > for display.  Also, at this point, all shared buffers have to go
> > > through system memory (this will be changing eventually now that we
> > > support device memory via dma-buf), so there is often an extra copy
> > > involved.
> > >
> > > > theres another really weird issue...
> > > >
> > > > given setup 1, where the monitor is plugged in to the card:
> > > > when i close the laptop lid, my monitor is "active" and whatnot, and i
> > > > can "use it" in a sense
> > > >
> > > > however, heres the weirdness:
> > > > the mouse cursor will move along the monitor perfectly smooth and
> > > > fine, but all the other updates to the screen are delayed by about 2
> > > > or 3 seconds.
> > > > that is to say, its as if the laptop is doing everything (e.g. if i
> > > > open a terminal, the terminal will open, but it will take 2 seconds
> > > > for me to see it)
> > > >
> > > > its almost as if all the frames and everything are being drawn, and
> > > > the laptop is running fine and everything, but i

Re: slow rx 5600 xt fps

[Javad Karabi]

just a couple more questions:

- based on what you are aware of, the technical details such as
"shared buffers go through system memory", and all that, do you see
any issues that might exist that i might be missing in my setup? i
cant imagine this being the case because the card works great in
windows, unless the windows driver does something different?

- as far as kernel config, is there anything in particular which
_should_ or _should not_ be enabled/disabled?

- does the vendor matter? for instance, this is an xfx card. when it
comes to different vendors, are there interface changes that might
make one vendor work better for linux than another? i dont really
understand the differences in vendors, but i imagine that the vbios
differs between vendors, and as such, the linux compatibility would
maybe change?

- is the pcie bandwidth possible an issue? the pcie_bw file changes
between values like this:
18446683600662707640 18446744071581623085 128
and sometimes i see this:
4096 0 128
as you can see, the second value seems significantly lower. is that
possibly an issue? possibly due to aspm?

On Tue, May 19, 2020 at 2:20 PM Javad Karabi  wrote:
>
> im using Driver "amdgpu" in my xorg conf
>
> how does one verify which gpu is the primary? im assuming my intel
> card is the primary, since i have not done anything to change that.
>
> also, if all shared buffers have to go through system memory, then
> that means an eGPU amdgpu wont work very well in general right?
> because going through system memory for the egpu means going over the
> thunderbolt connection
>
> and what are the shared buffers youre referring to? for example, if an
> application is drawing to a buffer, is that an example of a shared
> buffer that has to go through system memory? if so, thats fine, right?
> because the application's memory is in system memory, so that copy
> wouldnt be an issue.
>
> in general, do you think the "copy buffer across system memory might
> be a hindrance for thunderbolt? im trying to figure out which
> directions to go to debug and im totally lost, so maybe i can do some
> testing that direction?
>
> and for what its worth, when i turn the display "off" via the gnome
> display settings, its the same issue as when the laptop lid is closed,
> so unless the motherboard reads the "closed lid" the same as "display
> off", then im not sure if its thermal issues.
>
> On Tue, May 19, 2020 at 2:14 PM Alex Deucher  wrote:
> >
> > On Tue, May 19, 2020 at 2:59 PM Javad Karabi  wrote:
> > >
> > > given this setup:
> > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> monitor
> > > DRI_PRIME=1 glxgears gears gives me ~300fps
> > >
> > > given this setup:
> > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
> > > laptop -hdmi-> monitor
> > >
> > > glx gears gives me ~1800fps
> > >
> > > this doesnt make sense to me because i thought that having the monitor
> > > plugged directly into the card should give best performance.
> > >
> >
> > Do you have displays connected to both GPUs?  If you are using X which
> > ddx are you using?  xf86-video-modesetting or xf86-video-amdgpu?
> > IIRC, xf86-video-amdgpu has some optimizations for prime which are not
> > yet in xf86-video-modesetting.  Which GPU is set up as the primary?
> > Note that the GPU which does the rendering is not necessarily the one
> > that the displays are attached to.  The render GPU renders to it's
> > render buffer and then that data may end up being copied other GPUs
> > for display.  Also, at this point, all shared buffers have to go
> > through system memory (this will be changing eventually now that we
> > support device memory via dma-buf), so there is often an extra copy
> > involved.
> >
> > > theres another really weird issue...
> > >
> > > given setup 1, where the monitor is plugged in to the card:
> > > when i close the laptop lid, my monitor is "active" and whatnot, and i
> > > can "use it" in a sense
> > >
> > > however, heres the weirdness:
> > > the mouse cursor will move along the monitor perfectly smooth and
> > > fine, but all the other updates to the screen are delayed by about 2
> > > or 3 seconds.
> > > that is to say, its as if the laptop is doing everything (e.g. if i
> > > open a terminal, the terminal will open, but it will take 2 seconds
> > > for me to see it)
> > >
> > > its almost as if all the frames and everything are being drawn, and
> > > the laptop is running fine and everything, but i simply just dont get
> > > to see it on the monitor, except for one time every 2 seconds.
> > >
> > > its hard to articulate, because its so bizarre. its not like, a "low
> > > fps" per se, because the cursor is totally smooth. but its that
> > > _everything else_ is only updated once every couple seconds.
> >
> > This might also be related to which GPU is the primary.  It still may
> > be the integrated GPU since that is what is attached to the laptop
> > panel.  Also the platform and some drivers may do certain things wh

Re: slow rx 5600 xt fps

[Javad Karabi]

im using Driver "amdgpu" in my xorg conf

how does one verify which gpu is the primary? im assuming my intel
card is the primary, since i have not done anything to change that.

also, if all shared buffers have to go through system memory, then
that means an eGPU amdgpu wont work very well in general right?
because going through system memory for the egpu means going over the
thunderbolt connection

and what are the shared buffers youre referring to? for example, if an
application is drawing to a buffer, is that an example of a shared
buffer that has to go through system memory? if so, thats fine, right?
because the application's memory is in system memory, so that copy
wouldnt be an issue.

in general, do you think the "copy buffer across system memory might
be a hindrance for thunderbolt? im trying to figure out which
directions to go to debug and im totally lost, so maybe i can do some
testing that direction?

and for what its worth, when i turn the display "off" via the gnome
display settings, its the same issue as when the laptop lid is closed,
so unless the motherboard reads the "closed lid" the same as "display
off", then im not sure if its thermal issues.

On Tue, May 19, 2020 at 2:14 PM Alex Deucher  wrote:
>
> On Tue, May 19, 2020 at 2:59 PM Javad Karabi  wrote:
> >
> > given this setup:
> > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> monitor
> > DRI_PRIME=1 glxgears gears gives me ~300fps
> >
> > given this setup:
> > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
> > laptop -hdmi-> monitor
> >
> > glx gears gives me ~1800fps
> >
> > this doesnt make sense to me because i thought that having the monitor
> > plugged directly into the card should give best performance.
> >
>
> Do you have displays connected to both GPUs?  If you are using X which
> ddx are you using?  xf86-video-modesetting or xf86-video-amdgpu?
> IIRC, xf86-video-amdgpu has some optimizations for prime which are not
> yet in xf86-video-modesetting.  Which GPU is set up as the primary?
> Note that the GPU which does the rendering is not necessarily the one
> that the displays are attached to.  The render GPU renders to it's
> render buffer and then that data may end up being copied other GPUs
> for display.  Also, at this point, all shared buffers have to go
> through system memory (this will be changing eventually now that we
> support device memory via dma-buf), so there is often an extra copy
> involved.
>
> > theres another really weird issue...
> >
> > given setup 1, where the monitor is plugged in to the card:
> > when i close the laptop lid, my monitor is "active" and whatnot, and i
> > can "use it" in a sense
> >
> > however, heres the weirdness:
> > the mouse cursor will move along the monitor perfectly smooth and
> > fine, but all the other updates to the screen are delayed by about 2
> > or 3 seconds.
> > that is to say, its as if the laptop is doing everything (e.g. if i
> > open a terminal, the terminal will open, but it will take 2 seconds
> > for me to see it)
> >
> > its almost as if all the frames and everything are being drawn, and
> > the laptop is running fine and everything, but i simply just dont get
> > to see it on the monitor, except for one time every 2 seconds.
> >
> > its hard to articulate, because its so bizarre. its not like, a "low
> > fps" per se, because the cursor is totally smooth. but its that
> > _everything else_ is only updated once every couple seconds.
>
> This might also be related to which GPU is the primary.  It still may
> be the integrated GPU since that is what is attached to the laptop
> panel.  Also the platform and some drivers may do certain things when
> the lid is closed.  E.g., for thermal reasons, the integrated GPU or
> CPU may have a more limited TDP because the laptop cannot cool as
> efficiently.
>
> Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: slow rx 5600 xt fps

[Alex Deucher]

On Tue, May 19, 2020 at 2:59 PM Javad Karabi  wrote:
>
> given this setup:
> laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> monitor
> DRI_PRIME=1 glxgears gears gives me ~300fps
>
> given this setup:
> laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
> laptop -hdmi-> monitor
>
> glx gears gives me ~1800fps
>
> this doesnt make sense to me because i thought that having the monitor
> plugged directly into the card should give best performance.
>

Do you have displays connected to both GPUs?  If you are using X which
ddx are you using?  xf86-video-modesetting or xf86-video-amdgpu?
IIRC, xf86-video-amdgpu has some optimizations for prime which are not
yet in xf86-video-modesetting.  Which GPU is set up as the primary?
Note that the GPU which does the rendering is not necessarily the one
that the displays are attached to.  The render GPU renders to it's
render buffer and then that data may end up being copied other GPUs
for display.  Also, at this point, all shared buffers have to go
through system memory (this will be changing eventually now that we
support device memory via dma-buf), so there is often an extra copy
involved.

> theres another really weird issue...
>
> given setup 1, where the monitor is plugged in to the card:
> when i close the laptop lid, my monitor is "active" and whatnot, and i
> can "use it" in a sense
>
> however, heres the weirdness:
> the mouse cursor will move along the monitor perfectly smooth and
> fine, but all the other updates to the screen are delayed by about 2
> or 3 seconds.
> that is to say, its as if the laptop is doing everything (e.g. if i
> open a terminal, the terminal will open, but it will take 2 seconds
> for me to see it)
>
> its almost as if all the frames and everything are being drawn, and
> the laptop is running fine and everything, but i simply just dont get
> to see it on the monitor, except for one time every 2 seconds.
>
> its hard to articulate, because its so bizarre. its not like, a "low
> fps" per se, because the cursor is totally smooth. but its that
> _everything else_ is only updated once every couple seconds.

This might also be related to which GPU is the primary.  It still may
be the integrated GPU since that is what is attached to the laptop
panel.  Also the platform and some drivers may do certain things when
the lid is closed.  E.g., for thermal reasons, the integrated GPU or
CPU may have a more limited TDP because the laptop cannot cool as
efficiently.

Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

slow rx 5600 xt fps

[Javad Karabi]

given this setup:
laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> monitor
DRI_PRIME=1 glxgears gears gives me ~300fps

given this setup:
laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2
laptop -hdmi-> monitor

glx gears gives me ~1800fps

this doesnt make sense to me because i thought that having the monitor
plugged directly into the card should give best performance.

theres another really weird issue...

given setup 1, where the monitor is plugged in to the card:
when i close the laptop lid, my monitor is "active" and whatnot, and i
can "use it" in a sense

however, heres the weirdness:
the mouse cursor will move along the monitor perfectly smooth and
fine, but all the other updates to the screen are delayed by about 2
or 3 seconds.
that is to say, its as if the laptop is doing everything (e.g. if i
open a terminal, the terminal will open, but it will take 2 seconds
for me to see it)

its almost as if all the frames and everything are being drawn, and
the laptop is running fine and everything, but i simply just dont get
to see it on the monitor, except for one time every 2 seconds.

its hard to articulate, because its so bizarre. its not like, a "low
fps" per se, because the cursor is totally smooth. but its that
_everything else_ is only updated once every couple seconds.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: regarding vcn

[Javad Karabi]

thanks alex. i guess all the little things that i think are the
problem, are really red herrings lol. i keep finding little things
that i think might fix the 5600 issues im having but i guess theyre
unrelated. ill make another post which simply defines the issues im
having

On Tue, May 19, 2020 at 1:48 PM Alex Deucher  wrote:
>
> On Tue, May 19, 2020 at 2:45 PM Javad Karabi  wrote:
> >
> > for a rx 5600 xt graphics card, is VCN supposed to be set to disabled?
> >
> > if i understand correctly, 5600 is navi10, which has vcn
> >
> > but i currently see VCN: disabled
> >
> > $ sudo grep VCN /sys/kernel/debug/dri/1/amdgpu_pm_info
> > VCN: Disabled
>
> amdgpu_pm_info shows power information.  When the VCN block is not in
> use, the driver disables it to save power.  If you read back the
> amdgpu_pm_info while VCN is in use, it will show up as enabled.
>
> Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: regarding vcn

[Alex Deucher]

On Tue, May 19, 2020 at 2:45 PM Javad Karabi  wrote:
>
> for a rx 5600 xt graphics card, is VCN supposed to be set to disabled?
>
> if i understand correctly, 5600 is navi10, which has vcn
>
> but i currently see VCN: disabled
>
> $ sudo grep VCN /sys/kernel/debug/dri/1/amdgpu_pm_info
> VCN: Disabled

amdgpu_pm_info shows power information.  When the VCN block is not in
use, the driver disables it to save power.  If you read back the
amdgpu_pm_info while VCN is in use, it will show up as enabled.

Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

regarding vcn

[Javad Karabi]

for a rx 5600 xt graphics card, is VCN supposed to be set to disabled?

if i understand correctly, 5600 is navi10, which has vcn

but i currently see VCN: disabled

$ sudo grep VCN /sys/kernel/debug/dri/1/amdgpu_pm_info
VCN: Disabled
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdkfd: Fix boolreturn.cocci warnings

[Alex Deucher]

On Mon, May 18, 2020 at 12:37 PM Aishwarya Ramakrishnan
 wrote:
>
> Return statements in functions returning bool should use
> true/false instead of 1/0.
>
> drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c:40:9-10:
> WARNING: return of 0/1 in function 'event_interrupt_isr_v9' with return type 
> bool
>
> Generated by: scripts/coccinelle/misc/boolreturn.cocci
>
> Signed-off-by: Aishwarya Ramakrishnan 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
> index e05d75ecda21..fce6ccabe38b 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
> @@ -37,7 +37,7 @@ static bool event_interrupt_isr_v9(struct kfd_dev *dev,
> vmid = SOC15_VMID_FROM_IH_ENTRY(ih_ring_entry);
> if (vmid < dev->vm_info.first_vmid_kfd ||
> vmid > dev->vm_info.last_vmid_kfd)
> -   return 0;
> +   return false;
>
> source_id = SOC15_SOURCE_ID_FROM_IH_ENTRY(ih_ring_entry);
> client_id = SOC15_CLIENT_ID_FROM_IH_ENTRY(ih_ring_entry);
> @@ -69,7 +69,7 @@ static bool event_interrupt_isr_v9(struct kfd_dev *dev,
>
> /* If there is no valid PASID, it's likely a bug */
> if (WARN_ONCE(pasid == 0, "Bug: No PASID in KFD interrupt"))
> -   return 0;
> +   return false;
>
> /* Interrupt types we care about: various signals and faults.
>  * They will be forwarded to a work queue (see below).
> --
> 2.17.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 6/7] drm/amdgpu/sdma4: simplify the logic around powering up sdma

[Alex Deucher]

Just check if it's an APU.  The checks for the ppfuncs are
pointless because if we don't have them we can't power up
sdma anyway so we shouldn't even be in this code in the first
place.  I'm not sure about the in_gpu_reset check.  This
probably needs to be double checked.  The fini logic doesn't
match the init logic however with that in_gpu_reset check
in place which seems odd.

Signed-off-by: Alex Deucher 
---

Can someone test this on renoir?

 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 8545018747d6..4b47a267cbe8 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1913,9 +1913,7 @@ static int sdma_v4_0_hw_init(void *handle)
int r;
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
 
-   if ((adev->asic_type == CHIP_RAVEN && adev->powerplay.pp_funcs &&
-   adev->powerplay.pp_funcs->set_powergating_by_smu) ||
-   (adev->asic_type == CHIP_RENOIR && !adev->in_gpu_reset))
+   if (adev->flags & AMD_IS_APU)
amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_SDMA, 
false);
 
if (!amdgpu_sriov_vf(adev))
@@ -1942,9 +1940,7 @@ static int sdma_v4_0_hw_fini(void *handle)
sdma_v4_0_ctx_switch_enable(adev, false);
sdma_v4_0_enable(adev, false);
 
-   if ((adev->asic_type == CHIP_RAVEN && adev->powerplay.pp_funcs
-   && adev->powerplay.pp_funcs->set_powergating_by_smu) ||
-   adev->asic_type == CHIP_RENOIR)
+   if (adev->flags & AMD_IS_APU)
amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_SDMA, 
true);
 
return 0;
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 7/7] drm/amdgpu: put some case statments in family order

[Alex Deucher]

SI and CIK came before VI and newer asics.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 54 +++---
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 80a6c3156766..2f0e8da7bacf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1534,15 +1534,6 @@ static int amdgpu_device_parse_gpu_info_fw(struct 
amdgpu_device *adev)
adev->firmware.gpu_info_fw = NULL;
 
switch (adev->asic_type) {
-   case CHIP_TOPAZ:
-   case CHIP_TONGA:
-   case CHIP_FIJI:
-   case CHIP_POLARIS10:
-   case CHIP_POLARIS11:
-   case CHIP_POLARIS12:
-   case CHIP_VEGAM:
-   case CHIP_CARRIZO:
-   case CHIP_STONEY:
 #ifdef CONFIG_DRM_AMDGPU_SI
case CHIP_VERDE:
case CHIP_TAHITI:
@@ -1557,6 +1548,15 @@ static int amdgpu_device_parse_gpu_info_fw(struct 
amdgpu_device *adev)
case CHIP_KABINI:
case CHIP_MULLINS:
 #endif
+   case CHIP_TOPAZ:
+   case CHIP_TONGA:
+   case CHIP_FIJI:
+   case CHIP_POLARIS10:
+   case CHIP_POLARIS11:
+   case CHIP_POLARIS12:
+   case CHIP_VEGAM:
+   case CHIP_CARRIZO:
+   case CHIP_STONEY:
case CHIP_VEGA20:
default:
return 0;
@@ -1690,24 +1690,6 @@ static int amdgpu_device_ip_early_init(struct 
amdgpu_device *adev)
amdgpu_device_enable_virtual_display(adev);
 
switch (adev->asic_type) {
-   case CHIP_TOPAZ:
-   case CHIP_TONGA:
-   case CHIP_FIJI:
-   case CHIP_POLARIS10:
-   case CHIP_POLARIS11:
-   case CHIP_POLARIS12:
-   case CHIP_VEGAM:
-   case CHIP_CARRIZO:
-   case CHIP_STONEY:
-   if (adev->flags & AMD_IS_APU)
-   adev->family = AMDGPU_FAMILY_CZ;
-   else
-   adev->family = AMDGPU_FAMILY_VI;
-
-   r = vi_set_ip_blocks(adev);
-   if (r)
-   return r;
-   break;
 #ifdef CONFIG_DRM_AMDGPU_SI
case CHIP_VERDE:
case CHIP_TAHITI:
@@ -1736,6 +1718,24 @@ static int amdgpu_device_ip_early_init(struct 
amdgpu_device *adev)
return r;
break;
 #endif
+   case CHIP_TOPAZ:
+   case CHIP_TONGA:
+   case CHIP_FIJI:
+   case CHIP_POLARIS10:
+   case CHIP_POLARIS11:
+   case CHIP_POLARIS12:
+   case CHIP_VEGAM:
+   case CHIP_CARRIZO:
+   case CHIP_STONEY:
+   if (adev->flags & AMD_IS_APU)
+   adev->family = AMDGPU_FAMILY_CZ;
+   else
+   adev->family = AMDGPU_FAMILY_VI;
+
+   r = vi_set_ip_blocks(adev);
+   if (r)
+   return r;
+   break;
case CHIP_VEGA10:
case CHIP_VEGA12:
case CHIP_VEGA20:
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 5/7] drm/amdgpu: simplify mec2 fw check

[Alex Deucher]

Check if mec2 fw exists rather than checking asic types.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 4e4c9550dcf8..4d0bd149e1b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1339,8 +1339,7 @@ static int amdgpu_debugfs_firmware_info(struct seq_file 
*m, void *data)
   fw_info.feature, fw_info.ver);
 
/* MEC2 */
-   if (adev->asic_type == CHIP_KAVERI ||
-   (adev->asic_type > CHIP_TOPAZ && adev->asic_type != CHIP_STONEY)) {
+   if (adev->gfx.mec2_fw) {
query_fw.index = 1;
ret = amdgpu_firmware_info(&fw_info, &query_fw, adev);
if (ret)
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/7] drm/amdgpu/gfx10: add navi12 to gfxoff case

[Alex Deucher]

Looks like it should be handled here as well.

Signed-off-by: Alex Deucher 
---

Can someone test this on navi12?

 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index bd5dd4f64311..19de77cea890 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -7118,6 +7118,7 @@ static int gfx_v10_0_set_powergating_state(void *handle,
switch (adev->asic_type) {
case CHIP_NAVI10:
case CHIP_NAVI14:
+   case CHIP_NAVI12:
amdgpu_gfx_off_ctrl(adev, enable);
break;
default:
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 4/7] drm/amdgpu: simplify CZ/ST and KV/KB/ML checks

[Alex Deucher]

Just check for APU.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e036c868e354..80a6c3156766 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1699,7 +1699,7 @@ static int amdgpu_device_ip_early_init(struct 
amdgpu_device *adev)
case CHIP_VEGAM:
case CHIP_CARRIZO:
case CHIP_STONEY:
-   if (adev->asic_type == CHIP_CARRIZO || adev->asic_type == 
CHIP_STONEY)
+   if (adev->flags & AMD_IS_APU)
adev->family = AMDGPU_FAMILY_CZ;
else
adev->family = AMDGPU_FAMILY_VI;
@@ -1726,10 +1726,10 @@ static int amdgpu_device_ip_early_init(struct 
amdgpu_device *adev)
case CHIP_KAVERI:
case CHIP_KABINI:
case CHIP_MULLINS:
-   if ((adev->asic_type == CHIP_BONAIRE) || (adev->asic_type == 
CHIP_HAWAII))
-   adev->family = AMDGPU_FAMILY_CI;
-   else
+   if (adev->flags & AMD_IS_APU)
adev->family = AMDGPU_FAMILY_KV;
+   else
+   adev->family = AMDGPU_FAMILY_CI;
 
r = cik_set_ip_blocks(adev);
if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 2584ff74423b..0a6be88ebad9 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2342,7 +2342,7 @@ static u32 dce_v11_0_pick_pll(struct drm_crtc *crtc)
 
/* XXX need to determine what plls are available on each DCE11 part */
pll_in_use = amdgpu_pll_get_use_mask(crtc);
-   if (adev->asic_type == CHIP_CARRIZO || adev->asic_type == CHIP_STONEY) {
+   if (adev->flags & AMD_IS_APU) {
if (!(pll_in_use & (1 << ATOM_PPLL1)))
return ATOM_PPLL1;
if (!(pll_in_use & (1 << ATOM_PPLL0)))
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/7] drm/amdgpu/sdma4: add renoir to powergating setup

[Alex Deucher]

Looks like renoir should be handled here as well.

Signed-off-by: Alex Deucher 
---

Can someone test this on renoir?

 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 9077507b425a..a8cad03b1c42 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -2203,6 +2203,7 @@ static int sdma_v4_0_set_powergating_state(void *handle,
 
switch (adev->asic_type) {
case CHIP_RAVEN:
+   case CHIP_RENOIR:
sdma_v4_1_update_power_gating(adev,
state == AMD_PG_STATE_GATE ? true : false);
break;
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 3/7] drm/amdgpu: simplify raven and renoir checks

[Alex Deucher]

Just check for APU.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +--
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 4 ++--
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +-
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a027a8f7b281..e036c868e354 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1742,8 +1742,7 @@ static int amdgpu_device_ip_early_init(struct 
amdgpu_device *adev)
case CHIP_RAVEN:
case CHIP_ARCTURUS:
case CHIP_RENOIR:
-   if (adev->asic_type == CHIP_RAVEN ||
-   adev->asic_type == CHIP_RENOIR)
+   if (adev->flags & AMD_IS_APU)
adev->family = AMDGPU_FAMILY_RV;
else
adev->family = AMDGPU_FAMILY_AI;
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 711e9dd19705..22943773ae31 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1890,7 +1890,7 @@ static int gfx_v9_0_rlc_init(struct amdgpu_device *adev)
return r;
}
 
-   if (adev->asic_type == CHIP_RAVEN || adev->asic_type == CHIP_RENOIR) {
+   if (adev->flags & AMD_IS_APU) {
/* TODO: double check the cp_table_size for RV */
adev->gfx.rlc.cp_table_size = ALIGN(96 * 5 * 4, 2048) + (64 * 
1024); /* JT + GDS */
r = amdgpu_gfx_rlc_init_cpt(adev);
@@ -2384,7 +2384,7 @@ static int gfx_v9_0_sw_fini(void *handle)
 
gfx_v9_0_mec_fini(adev);
amdgpu_bo_unref(&adev->gfx.rlc.clear_state_obj);
-   if (adev->asic_type == CHIP_RAVEN || adev->asic_type == CHIP_RENOIR) {
+   if (adev->flags & AMD_IS_APU) {
amdgpu_bo_free_kernel(&adev->gfx.rlc.cp_table_obj,
&adev->gfx.rlc.cp_table_gpu_addr,
(void **)&adev->gfx.rlc.cp_table_ptr);
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index a8cad03b1c42..8545018747d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1775,7 +1775,7 @@ static int sdma_v4_0_early_init(void *handle)
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
int r;
 
-   if (adev->asic_type == CHIP_RAVEN || adev->asic_type == CHIP_RENOIR)
+   if (adev->flags & AMD_IS_APU)
adev->sdma.num_instances = 1;
else if (adev->asic_type == CHIP_ARCTURUS)
adev->sdma.num_instances = 8;
-- 
2.25.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amdgpu/jpeg2.5: Remove JPEG_ENC_MASK from clock ungating

[James Zhu]

Remove JPEG_ENC_MASK from clock ungating since MJPEG encoder
hasn't been support yet.

Signed-off-by: James Zhu 
---
 drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c 
b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
index 37df3f2..713c325 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
@@ -268,7 +268,6 @@ static void jpeg_v2_5_disable_clock_gating(struct 
amdgpu_device* adev, int inst)
data = RREG32_SOC15(JPEG, inst, mmJPEG_CGC_GATE);
data &= ~(JPEG_CGC_GATE__JPEG_DEC_MASK
| JPEG_CGC_GATE__JPEG2_DEC_MASK
-   | JPEG_CGC_GATE__JPEG_ENC_MASK
| JPEG_CGC_GATE__JMCIF_MASK
| JPEG_CGC_GATE__JRBBM_MASK);
WREG32_SOC15(JPEG, inst, mmJPEG_CGC_GATE, data);
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/2] drm/amdgpu/vcn2.5: Remove old DPG workaround

[James Zhu]

SCRATCH2 is used to keep decode wptr as a workaround
which fix a hardware DPG decode wptr update bug for
vcn2.5 beforehand.

Signed-off-by: James Zhu 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
index 34ed906..3c6eafb 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
@@ -1453,11 +1453,6 @@ static int vcn_v2_5_pause_dpg_mode(struct amdgpu_device 
*adev,
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_WPTR2, 
lower_32_bits(ring->wptr));

fw_shared->multi_queue.encode_lowlatency_queue_mode &= ~FW_QUEUE_RING_RESET;
 
-   fw_shared->multi_queue.decode_queue_mode |= 
FW_QUEUE_RING_RESET;
-   WREG32_SOC15(VCN, inst_idx, mmUVD_RBC_RB_WPTR,
-  RREG32_SOC15(VCN, inst_idx, 
mmUVD_SCRATCH2) & 0x7FFF);
-   fw_shared->multi_queue.decode_queue_mode &= 
~FW_QUEUE_RING_RESET;
-
/* Unstall DPG */
WREG32_P(SOC15_REG_OFFSET(VCN, inst_idx, 
mmUVD_POWER_STATUS),
   0, 
~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK);
@@ -1519,10 +1514,6 @@ static void vcn_v2_5_dec_ring_set_wptr(struct 
amdgpu_ring *ring)
 {
struct amdgpu_device *adev = ring->adev;
 
-   if (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG)
-   WREG32_SOC15(VCN, ring->me, mmUVD_SCRATCH2,
-   lower_32_bits(ring->wptr) | 0x8000);
-
if (ring->use_doorbell) {
adev->wb.wb[ring->wptr_offs] = lower_32_bits(ring->wptr);
WDOORBELL32(ring->doorbell_index, lower_32_bits(ring->wptr));
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] dma-fence: add might_sleep annotation to _wait()

[Daniel Vetter]

Do it uncontionally, there's a separate peek function with
dma_fence_is_signalled() which can be called from atomic context.

v2: Consensus calls for an unconditional might_sleep (Chris,
Christian)

Full audit:
- dma-fence.h: Uses MAX_SCHEDULE_TIMOUT, good chance this sleeps
- dma-resv.c: Timeout always at least 1
- st-dma-fence.c: Save to sleep in testcases
- amdgpu_cs.c: Both callers are for variants of the wait ioctl
- amdgpu_device.c: Two callers in vram recover code, both right next
  to mutex_lock.
- amdgpu_vm.c: Use in the vm_wait ioctl, next to _reserve/unreserve
- remaining functions in amdgpu: All for test_ib implementations for
  various engines, caller for that looks all safe (debugfs, driver
  load, reset)
- etnaviv: another wait ioctl
- habanalabs: another wait ioctl
- nouveau_fence.c: hardcoded 15*HZ ... glorious
- nouveau_gem.c: hardcoded 2*HZ ... so not even super consistent, but
  this one does have a WARN_ON :-/ At least this one is only a
  fallback path for when kmalloc fails. Maybe this should be put onto
  some worker list instead, instead of a work per unamp ...
- i915/selftests: Hardecoded HZ / 4 or HZ / 8
- i915/gt/selftests: Going up the callchain looks safe looking at
  nearby callers
- i915/gt/intel_gt_requests.c. Wrapped in a mutex_lock
- i915/gem_i915_gem_wait.c: The i915-version which is called instead
  for i915 fences already has a might_sleep() annotation, so all good

Cc: Alex Deucher 
Cc: Lucas Stach 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Ben Skeggs 
Cc: "VMware Graphics" 
Cc: Oded Gabbay 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/dma-buf/dma-fence.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 90edf2b281b0..656e9ac2d028 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -208,6 +208,8 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, 
signed long timeout)
if (WARN_ON(timeout < 0))
return -EINVAL;
 
+   might_sleep();
+
trace_dma_fence_wait_start(fence);
if (fence->ops->wait)
ret = fence->ops->wait(fence, intr, timeout);
-- 
2.26.2

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH AUTOSEL 5.6 33/50] drm/amdgpu: bump version for invalidate L2 before SDMA IBs

[Deucher, Alexander]

[AMD Public Use]

Yes, please drop this patch for stable.

Alex

From: Marek Olšák 
Sent: Monday, May 18, 2020 6:35 PM
To: Sasha Levin 
Cc: Linux Kernel Mailing List ; 
sta...@vger.kernel.org ; Pelloux-prayer, Pierre-eric 
; Olsak, Marek ; 
amd-gfx mailing list ; dri-devel 
; Deucher, Alexander 
; Koenig, Christian 
Subject: Re: [PATCH AUTOSEL 5.6 33/50] drm/amdgpu: bump version for invalidate 
L2 before SDMA IBs

Hi Sasha,

I disagree with this. Bumping the driver version will have implications on 
other new features, because it's like an ABI barrier exposing new functionality.

Marek

On Thu, May 7, 2020 at 10:28 AM Sasha Levin 
mailto:sas...@kernel.org>> wrote:
From: Marek Olšák mailto:marek.ol...@amd.com>>

[ Upstream commit 9017a4897a20658f010bebea825262963c10afa6 ]

This fixes GPU hangs due to cache coherency issues.
Bump the driver version. Split out from the original patch.

Signed-off-by: Marek Olšák mailto:marek.ol...@amd.com>>
Reviewed-by: Christian König 
mailto:christian.koe...@amd.com>>
Tested-by: Pierre-Eric Pelloux-Prayer 
mailto:pierre-eric.pelloux-pra...@amd.com>>
Signed-off-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>
Signed-off-by: Sasha Levin mailto:sas...@kernel.org>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 42f4febe24c6d..8d45a2b662aeb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -85,9 +85,10 @@
  * - 3.34.0 - Non-DC can flip correctly between buffers with different pitches
  * - 3.35.0 - Add drm_amdgpu_info_device::tcc_disabled_mask
  * - 3.36.0 - Allow reading more status registers on si/cik
+ * - 3.37.0 - L2 is invalidated before SDMA IBs, needed for correctness
  */
 #define KMS_DRIVER_MAJOR   3
-#define KMS_DRIVER_MINOR   36
+#define KMS_DRIVER_MINOR   37
 #define KMS_DRIVER_PATCHLEVEL  0

 int amdgpu_vram_limit = 0;
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition

[Zhang, Hawking]

[AMD Official Use Only - Internal Distribution Only]

Please only apply the check to arcturus - we don't need to check ras fatal 
error event on all the NV series.

Regards,
Hawking
From: Clements, John 
Sent: Tuesday, May 19, 2020 17:15
To: amd-gfx@lists.freedesktop.org; Zhang, Hawking 
Subject: [PATCH] drm/amdgpu: resolve ras recovery vs smi race condition


[AMD Official Use Only - Internal Distribution Only]

Submitting patch to block SMU access' via SMI during RAS recovery
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: resolve ras recovery vs smi race condition

[Clements, John]

[AMD Official Use Only - Internal Distribution Only]

Submitting patch to block SMU access' via SMI during RAS recovery


0001-drm-amdgpu-resolve-ras-recovery-vs-smi-race-conditio.patch
Description: 0001-drm-amdgpu-resolve-ras-recovery-vs-smi-race-conditio.patch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx