Re: [PATCH v2] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
On Tue, Apr 24, 2018 at 11:44:27AM +0800, S, Shirish wrote:
>
>
> On 4/24/2018 8:19 AM, Huang Rui wrote:
> > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)"
> > Above patch defers the execution of gfx/compute ib tests. However, at that
> > time,
> > the gfx may already go into idle state. If "idle" gfx receives command
> > submission, then will get hang in the system. And it still has issue to
> > dynamically enable/disable gfxoff at runtime. So we have to use a
> > workaround to
> > skip the gfx/compute ib tests when gfx is already in "idle" state.
> >
> > Signed-off-by: Huang Rui
> > Cc: Shirish S
> > ---
> >
> > Changes from V1 -> V2:
> > - Remove unused definitions of smu10_hwmgr.
> > - Add WA descriptions into commit log and comments.
> >
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
> > drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 23
> > ++-
> Is it not required for older asics of cz/st?
> If not then please update the commit message accordingly.
No, it isn't. gfx8 asics don't support gfxoff. OK, I will add one note in
my commit log.
Thanks,
Ray
> Regards,
> Shirish S
> > drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 22
> > ++
> > 3 files changed, 26 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 59df4b7..a0263b9 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -905,6 +905,7 @@ struct amdgpu_gfx_funcs {
> > void (*read_wave_vgprs)(struct amdgpu_device *adev, uint32_t simd,
> > uint32_t wave, uint32_t thread, uint32_t start, uint32_t size, uint32_t
> > *dst);
> > void (*read_wave_sgprs)(struct amdgpu_device *adev, uint32_t simd,
> > uint32_t wave, uint32_t start, uint32_t size, uint32_t *dst);
> > void (*select_me_pipe_q)(struct amdgpu_device *adev, u32 me, u32 pipe,
> > u32 queue);
> > + bool (*is_gfx_on)(struct amdgpu_device *adev);
> > };
> >
> > struct amdgpu_ngg_buf {
> > @@ -1855,6 +1856,7 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
> > #define amdgpu_gds_switch(adev, r, v, d, w, a)
> > (adev)->gds.funcs->patch_gds_switch((r), (v), (d), (w), (a))
> > #define amdgpu_psp_check_fw_loading_status(adev, i)
> > (adev)->firmware.funcs->check_fw_loading_status((adev), (i))
> > #define amdgpu_gfx_select_me_pipe_q(adev, me, pipe, q)
> > (adev)->gfx.funcs->select_me_pipe_q((adev), (me), (pipe), (q))
> > +#define amdgpu_gfx_is_gfx_on(adev) (adev)->gfx.funcs->is_gfx_on((adev))
> >
> > /* Common functions */
> > int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > index 2c5e2a4..b8bd194 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > @@ -342,6 +342,18 @@ static int gfx_v9_0_ring_test_ring(struct amdgpu_ring
> > *ring)
> > return r;
> > }
> >
> > +static bool gfx_v9_0_is_gfx_on(struct amdgpu_device *adev)
> > +{
> > + uint32_t reg;
> > +
> > + reg = RREG32_SOC15(PWR, 0, mmPWR_MISC_CNTL_STATUS);
> > + if ((reg & PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS_MASK) ==
> > + (0x2 << PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS__SHIFT))
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > static int gfx_v9_0_ring_test_ib(struct amdgpu_ring *ring, long timeout)
> > {
> > struct amdgpu_device *adev = ring->adev;
> > @@ -353,6 +365,14 @@ static int gfx_v9_0_ring_test_ib(struct amdgpu_ring
> > *ring, long timeout)
> > uint32_t tmp;
> > long r;
> >
> > + /*
> > +* FIXME: It still has issue to dynamically enable/disable gfxoff at
> > +* runtime. So it has to skip the gfx/compute ib test when gfx is
> > +* already in "idle" state.
> > +*/
> > + if (!amdgpu_gfx_is_gfx_on(adev))
> > + return 0;
> > +
> > r = amdgpu_device_wb_get(adev, &index);
> > if (r) {
> > dev_err(adev->dev, "(%ld) failed to allocate wb slot\n", r);
> > @@ -1085,7 +1105,8 @@ static const struct amdgpu_gfx_funcs
> > gfx_v9_0_gfx_funcs = {
> > .read_wave_data = &gfx_v9_0_read_wave_data,
> > .read_wave_sgprs = &gfx_v9_0_read_wave_sgprs,
> > .read_wave_vgprs = &gfx_v9_0_read_wave_vgprs,
> > - .select_me_pipe_q = &gfx_v9_0_select_me_pipe_q
> > + .select_me_pipe_q = &gfx_v9_0_select_me_pipe_q,
> > + .is_gfx_on = &gfx_v9_0_is_gfx_on
> > };
> >
> > static void gfx_v9_0_gpu_early_init(struct amdgpu_device *adev)
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> > index 7712eb6..48c17fb 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> > @@ -42,12 +42,6 @@
> > #define SMU10_DISPCLK_BYPASS_THRESHOLD 1 /
Re: [PATCH v2] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
On 4/24/2018 8:19 AM, Huang Rui wrote:
"aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)"
Above patch defers the execution of gfx/compute ib tests. However, at that time,
the gfx may already go into idle state. If "idle" gfx receives command
submission, then will get hang in the system. And it still has issue to
dynamically enable/disable gfxoff at runtime. So we have to use a workaround to
skip the gfx/compute ib tests when gfx is already in "idle" state.
Signed-off-by: Huang Rui
Cc: Shirish S
---
Changes from V1 -> V2:
- Remove unused definitions of smu10_hwmgr.
- Add WA descriptions into commit log and comments.
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 23 ++-
Is it not required for older asics of cz/st?
If not then please update the commit message accordingly.
Regards,
Shirish S
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 22 ++
3 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 59df4b7..a0263b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -905,6 +905,7 @@ struct amdgpu_gfx_funcs {
void (*read_wave_vgprs)(struct amdgpu_device *adev, uint32_t simd,
uint32_t wave, uint32_t thread, uint32_t start, uint32_t size, uint32_t *dst);
void (*read_wave_sgprs)(struct amdgpu_device *adev, uint32_t simd,
uint32_t wave, uint32_t start, uint32_t size, uint32_t *dst);
void (*select_me_pipe_q)(struct amdgpu_device *adev, u32 me, u32 pipe,
u32 queue);
+ bool (*is_gfx_on)(struct amdgpu_device *adev);
};
struct amdgpu_ngg_buf {
@@ -1855,6 +1856,7 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
#define amdgpu_gds_switch(adev, r, v, d, w, a)
(adev)->gds.funcs->patch_gds_switch((r), (v), (d), (w), (a))
#define amdgpu_psp_check_fw_loading_status(adev, i)
(adev)->firmware.funcs->check_fw_loading_status((adev), (i))
#define amdgpu_gfx_select_me_pipe_q(adev, me, pipe, q)
(adev)->gfx.funcs->select_me_pipe_q((adev), (me), (pipe), (q))
+#define amdgpu_gfx_is_gfx_on(adev) (adev)->gfx.funcs->is_gfx_on((adev))
/* Common functions */
int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 2c5e2a4..b8bd194 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -342,6 +342,18 @@ static int gfx_v9_0_ring_test_ring(struct amdgpu_ring
*ring)
return r;
}
+static bool gfx_v9_0_is_gfx_on(struct amdgpu_device *adev)
+{
+ uint32_t reg;
+
+ reg = RREG32_SOC15(PWR, 0, mmPWR_MISC_CNTL_STATUS);
+ if ((reg & PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS_MASK) ==
+ (0x2 << PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS__SHIFT))
+ return true;
+
+ return false;
+}
+
static int gfx_v9_0_ring_test_ib(struct amdgpu_ring *ring, long timeout)
{
struct amdgpu_device *adev = ring->adev;
@@ -353,6 +365,14 @@ static int gfx_v9_0_ring_test_ib(struct amdgpu_ring *ring,
long timeout)
uint32_t tmp;
long r;
+ /*
+* FIXME: It still has issue to dynamically enable/disable gfxoff at
+* runtime. So it has to skip the gfx/compute ib test when gfx is
+* already in "idle" state.
+*/
+ if (!amdgpu_gfx_is_gfx_on(adev))
+ return 0;
+
r = amdgpu_device_wb_get(adev, &index);
if (r) {
dev_err(adev->dev, "(%ld) failed to allocate wb slot\n", r);
@@ -1085,7 +1105,8 @@ static const struct amdgpu_gfx_funcs gfx_v9_0_gfx_funcs =
{
.read_wave_data = &gfx_v9_0_read_wave_data,
.read_wave_sgprs = &gfx_v9_0_read_wave_sgprs,
.read_wave_vgprs = &gfx_v9_0_read_wave_vgprs,
- .select_me_pipe_q = &gfx_v9_0_select_me_pipe_q
+ .select_me_pipe_q = &gfx_v9_0_select_me_pipe_q,
+ .is_gfx_on = &gfx_v9_0_is_gfx_on
};
static void gfx_v9_0_gpu_early_init(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 7712eb6..48c17fb 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -42,12 +42,6 @@
#define SMU10_DISPCLK_BYPASS_THRESHOLD 1 /* 100Mhz */
#define SMC_RAM_END 0x4
-#define mmPWR_MISC_CNTL_STATUS 0x0183
-#define mmPWR_MISC_CNTL_STATUS_BASE_IDX0
-#define PWR_MISC_CNTL_STATUS__PWR_GFX_RLC_CGPG_EN__SHIFT 0x0
-#define PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS__SHIFT 0x1
-#define PWR_MISC_CNTL_STATUS__PWR_GFX_RLC_CGPG_EN_MASK 0x0001L
-#define PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS_MASK 0x0006L
static const unsigned long S
[PATCH v2] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
"aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)"
Above patch defers the execution of gfx/compute ib tests. However, at that time,
the gfx may already go into idle state. If "idle" gfx receives command
submission, then will get hang in the system. And it still has issue to
dynamically enable/disable gfxoff at runtime. So we have to use a workaround to
skip the gfx/compute ib tests when gfx is already in "idle" state.
Signed-off-by: Huang Rui
Cc: Shirish S
---
Changes from V1 -> V2:
- Remove unused definitions of smu10_hwmgr.
- Add WA descriptions into commit log and comments.
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 23 ++-
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 22 ++
3 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 59df4b7..a0263b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -905,6 +905,7 @@ struct amdgpu_gfx_funcs {
void (*read_wave_vgprs)(struct amdgpu_device *adev, uint32_t simd,
uint32_t wave, uint32_t thread, uint32_t start, uint32_t size, uint32_t *dst);
void (*read_wave_sgprs)(struct amdgpu_device *adev, uint32_t simd,
uint32_t wave, uint32_t start, uint32_t size, uint32_t *dst);
void (*select_me_pipe_q)(struct amdgpu_device *adev, u32 me, u32 pipe,
u32 queue);
+ bool (*is_gfx_on)(struct amdgpu_device *adev);
};
struct amdgpu_ngg_buf {
@@ -1855,6 +1856,7 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
#define amdgpu_gds_switch(adev, r, v, d, w, a)
(adev)->gds.funcs->patch_gds_switch((r), (v), (d), (w), (a))
#define amdgpu_psp_check_fw_loading_status(adev, i)
(adev)->firmware.funcs->check_fw_loading_status((adev), (i))
#define amdgpu_gfx_select_me_pipe_q(adev, me, pipe, q)
(adev)->gfx.funcs->select_me_pipe_q((adev), (me), (pipe), (q))
+#define amdgpu_gfx_is_gfx_on(adev) (adev)->gfx.funcs->is_gfx_on((adev))
/* Common functions */
int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 2c5e2a4..b8bd194 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -342,6 +342,18 @@ static int gfx_v9_0_ring_test_ring(struct amdgpu_ring
*ring)
return r;
}
+static bool gfx_v9_0_is_gfx_on(struct amdgpu_device *adev)
+{
+ uint32_t reg;
+
+ reg = RREG32_SOC15(PWR, 0, mmPWR_MISC_CNTL_STATUS);
+ if ((reg & PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS_MASK) ==
+ (0x2 << PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS__SHIFT))
+ return true;
+
+ return false;
+}
+
static int gfx_v9_0_ring_test_ib(struct amdgpu_ring *ring, long timeout)
{
struct amdgpu_device *adev = ring->adev;
@@ -353,6 +365,14 @@ static int gfx_v9_0_ring_test_ib(struct amdgpu_ring *ring,
long timeout)
uint32_t tmp;
long r;
+ /*
+* FIXME: It still has issue to dynamically enable/disable gfxoff at
+* runtime. So it has to skip the gfx/compute ib test when gfx is
+* already in "idle" state.
+*/
+ if (!amdgpu_gfx_is_gfx_on(adev))
+ return 0;
+
r = amdgpu_device_wb_get(adev, &index);
if (r) {
dev_err(adev->dev, "(%ld) failed to allocate wb slot\n", r);
@@ -1085,7 +1105,8 @@ static const struct amdgpu_gfx_funcs gfx_v9_0_gfx_funcs =
{
.read_wave_data = &gfx_v9_0_read_wave_data,
.read_wave_sgprs = &gfx_v9_0_read_wave_sgprs,
.read_wave_vgprs = &gfx_v9_0_read_wave_vgprs,
- .select_me_pipe_q = &gfx_v9_0_select_me_pipe_q
+ .select_me_pipe_q = &gfx_v9_0_select_me_pipe_q,
+ .is_gfx_on = &gfx_v9_0_is_gfx_on
};
static void gfx_v9_0_gpu_early_init(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 7712eb6..48c17fb 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -42,12 +42,6 @@
#define SMU10_DISPCLK_BYPASS_THRESHOLD 1 /* 100Mhz */
#define SMC_RAM_END 0x4
-#define mmPWR_MISC_CNTL_STATUS 0x0183
-#define mmPWR_MISC_CNTL_STATUS_BASE_IDX0
-#define PWR_MISC_CNTL_STATUS__PWR_GFX_RLC_CGPG_EN__SHIFT 0x0
-#define PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS__SHIFT 0x1
-#define PWR_MISC_CNTL_STATUS__PWR_GFX_RLC_CGPG_EN_MASK 0x0001L
-#define PWR_MISC_CNTL_STATUS__PWR_GFXOFF_STATUS_MASK 0x0006L
static const unsigned long SMU10_Magic = (unsigned long) PHM_Rv_Magic;
@@ -254,28 +248,16 @@ static int smu10_power_off_asic(struct pp_hwmgr *hwmgr)
return smu10_reset_cc6_data(hwmgr)
Re: [PATCH] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
On Mon, Apr 23, 2018 at 10:40:20PM +0800, Alex Deucher wrote: > On Mon, Apr 23, 2018 at 8:13 AM, Huang Rui wrote: > > On Mon, Apr 23, 2018 at 05:57:06PM +0800, Koenig, Christian wrote: > >> Hi Ray, > >> > >> Am 23.04.2018 11:47 schrieb Huang Rui : > >> > >> On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote: > >> > Am 20.04.2018 um 11:40 schrieb Huang Rui: > >> > > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)" > >> > > Above patch defers the execution of gfx/compute ib tests. However, > >> at > >> that time, > >> > > the gfx may already go into idle state. If "idle" gfx receives > >> command > >> > > submission, it will get hang in the system. So we must add > >> is_gfx_on > >> checking at > >> > > start of ib tests. > >> > > >> > Do I see that right that you just skip the IB test when the GFX > >> block is > >> > already turned of? In this case that would be a clear NAK. > >> > > >> > BTW: How do you detect that we need to turn GFX on again? > >> > >> Christian, I know point. But there is a hang issue if we would like > >> try to > >> disable/enable gfxoff with SMC message at runtime. Actually, I am > >> trying to > >> find a good sequence to fix it. After that, I can even expose an > >> debugfs > >> interface to configure that. So I have to skip the test for the moment > >> when > >> gfx is in "idle". > >> > >> > >> Working around that issue for the moment is ok, but please note that > >> explicitly > >> in both the commit message and a code comment. > > > > OK. Will add it at V2. > > > >> > >> But don't you run into the same problem when the UMD starts to submit > >> commands? > > > > When UMD starts, RLC firmware will detect the "draw" command, then it will > > power up gfx. So it won't have problem at that time. The mainly state > > machine doesn't expose to driver side yet. > > > >> > >> I mean the idea of the IB test is that you "simulate" an userspace command > >> submission and see if it works. > >> > > > > Yes, agree. Any idea to "simulate" the "draw" command? Or please wait for > > my fix for enabling/disabling gfxoff at runtime. > > > Is there some special formatting in the IB required? I don't really > see how this will work. There is likely tons of state before the > actual draw command in the IB. > No, there isn't. The mainly behavior to turn on/off gfx is almost in RLC firmware. From driver's perspective, we only just use smc mesg to enable/disable the feature. Thanks, Ray ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: RFC for a render API to support adaptive sync and VRR
On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote: > On 2018-04-20 04:32 PM, Manasi Navare wrote: > > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: > >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote: > >>> Michel Dänzer writes: > Time-based presentation seems to be the right approach for preventing > micro-stutter in games as well, Croteam developers have been researching > this. > >>> > >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present > >>> extension offer the ability to specify the desired display time in > >>> seconds. > >>> > >>> Similarly, I'd suggest that the min/max display refresh rate values be > >>> advertised as time between frames rather than frames per second. > > > > So there is a global min and max refresh rate as advertised by the monitor > > range descriptor. That I guess can be exposed as a global range in terms of > > min and max time between frames as a global property of the connector. > > > > We dont need the per mode min and max refresh rate to be exposed right? > > If I understand VRR right, with CinemaVRR acceptable refresh rates might fall > outside the range advertised by the monitor. Would we > 1) advertise 24/1.001 as a lower bound, > 2) expect media apps to use the lower bound simply for informational > purposes, > 3) or simply not support CinemaVRR? > > (1) has the added caveat that not all reported rates would be supported. > > Alternatively a bit could indicate that CinemaVRR is support, but I'm not > sure if user mode would need all these details. > > Harry Are there special CinemaVRR suported monitors? In that case we need to understand how those monitors advertise the monitor range and if they have a bit in EDID that indicate they are CinemaVRR capable as opposed to just the Adaptive Sync/VRR. Harry, if you have one of those monitors, could you send the EDID dump for that? Manasi > > > > >>> > >>> I'd also encourage using a single unit for all of these values, > >>> preferably nanoseconds. Absolute times should all be referenced to > >>> CLOCK_MONOTONIC. > >> > >> +1 on everything Keith said. I got somehow dragged in khr vk > >> discussions around preventing micro-stuttering, and consensus seems to > >> be that timestamps for scheduling frames is the way to go, most likely > >> absolute ones (not everything is running Linux unfortunately, so can't > >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC). > >> -Daniel > > > > And yes I also got consensus from Mesa and media folks about using the > > absolute timestamp for scheduling the frames and then the driver will > > modify the vblank logic to "present no earlier than the timestamp" > > > > Manasi > > > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > >> ___ > >> dri-devel mailing list > >> dri-de...@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: change pp_dpm clk/mclk/pcie input format
On Thu, Apr 19, 2018 at 4:51 PM, welu wrote:
> 1. support more than 8 values when setting get_pp_dpm_mclk/
> sclk/pcie, the former design just parse command format like
> "echo > pp_dpm_sclk" and current can parse "echo xx xxx
> > pp_dpm_sclk" whose operation is more user-friendly
> and convinent and can offer more values;
> 2. be compatible with former design like "xx".
> Bug:KFD-385
Please update the documentation labeled "DOC: pp_dpm_sclk pp_dpm_mclk
pp_dpm_pcie", With that fixed, patch is:
Reviewed-by: Alex Deucher
>
> Change-Id: Id7d95ce45f4ee0564b18ebcfc16976f1a5c6bf72
> Signed-off-by: welu
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 95
> --
> 1 file changed, 55 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index 744f105..58f46f9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -466,23 +466,27 @@ static ssize_t amdgpu_set_pp_dpm_sclk(struct device
> *dev,
> struct amdgpu_device *adev = ddev->dev_private;
> int ret;
> long level;
> - uint32_t i, mask = 0;
> - char sub_str[2];
> + uint32_t mask = 0;
> + char *sub_str = NULL;
> + char *tmp;
> + char buf_cpy[count];
> + const char delimiter[3] = {' ', '\n', '\0'};
>
> - for (i = 0; i < strlen(buf); i++) {
> - if (*(buf + i) == '\n')
> - continue;
> - sub_str[0] = *(buf + i);
> - sub_str[1] = '\0';
> - ret = kstrtol(sub_str, 0, &level);
> + memcpy(buf_cpy, buf, count+1);
> + tmp = buf_cpy;
> + while (tmp[0]) {
> + sub_str = strsep(&tmp, delimiter);
> + if (strlen(sub_str)) {
> + ret = kstrtol(sub_str, 0, &level);
>
> - if (ret) {
> - count = -EINVAL;
> - goto fail;
> - }
> - mask |= 1 << level;
> + if (ret) {
> + count = -EINVAL;
> + goto fail;
> + }
> + mask |= 1 << level;
> + } else
> + break;
> }
> -
> if (adev->powerplay.pp_funcs->force_clock_level)
> amdgpu_dpm_force_clock_level(adev, PP_SCLK, mask);
>
> @@ -512,21 +516,26 @@ static ssize_t amdgpu_set_pp_dpm_mclk(struct device
> *dev,
> struct amdgpu_device *adev = ddev->dev_private;
> int ret;
> long level;
> - uint32_t i, mask = 0;
> - char sub_str[2];
> + uint32_t mask = 0;
> + char *sub_str = NULL;
> + char *tmp;
> + char buf_cpy[count];
> + const char delimiter[3] = {' ', '\n', '\0'};
>
> - for (i = 0; i < strlen(buf); i++) {
> - if (*(buf + i) == '\n')
> - continue;
> - sub_str[0] = *(buf + i);
> - sub_str[1] = '\0';
> - ret = kstrtol(sub_str, 0, &level);
> + memcpy(buf_cpy, buf, count+1);
> + tmp = buf_cpy;
> + while (tmp[0]) {
> + sub_str = strsep(&tmp, delimiter);
> + if (strlen(sub_str)) {
> + ret = kstrtol(sub_str, 0, &level);
>
> - if (ret) {
> - count = -EINVAL;
> - goto fail;
> - }
> - mask |= 1 << level;
> + if (ret) {
> + count = -EINVAL;
> + goto fail;
> + }
> + mask |= 1 << level;
> + } else
> + break;
> }
> if (adev->powerplay.pp_funcs->force_clock_level)
> amdgpu_dpm_force_clock_level(adev, PP_MCLK, mask);
> @@ -557,21 +566,27 @@ static ssize_t amdgpu_set_pp_dpm_pcie(struct device
> *dev,
> struct amdgpu_device *adev = ddev->dev_private;
> int ret;
> long level;
> - uint32_t i, mask = 0;
> - char sub_str[2];
> + uint32_t mask = 0;
> + char *sub_str = NULL;
> + char *tmp;
> + char buf_cpy[count];
> + const char delimiter[3] = {' ', '\n', '\0'};
>
> - for (i = 0; i < strlen(buf); i++) {
> - if (*(buf + i) == '\n')
> - continue;
> - sub_str[0] = *(buf + i);
> - sub_str[1] = '\0';
> - ret = kstrtol(sub_str, 0, &level);
> + memcpy(buf_cpy, buf, count+1);
> + tmp = buf_cpy;
>
> - if (ret) {
> - count = -EINVAL;
> - goto fail;
> - }
> - mask |= 1 << level;
> + while (tmp[0]) {
> + sub_str = strsep(&tmp, delimiter);
> + if (strlen(su
Tracking: radeon 0000:00:10.0: ring 0 stalled for more than 10240msec
Hi there, I am pretty sure I was able to run kodi on an old Mac Mini G4 (big endian) with AMD RV280. Today it is failing to start with: [ 162.971551] radeon :00:10.0: ring 0 stalled for more than 10240msec [ 162.971568] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 163.482863] radeon :00:10.0: ring 0 stalled for more than 10752msec [ 163.482880] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 163.994225] radeon :00:10.0: ring 0 stalled for more than 11264msec [ 163.994241] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 164.505598] radeon :00:10.0: ring 0 stalled for more than 11776msec [ 164.505614] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 165.016996] radeon :00:10.0: ring 0 stalled for more than 12288msec [ 165.017013] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 165.528429] radeon :00:10.0: ring 0 stalled for more than 12800msec [ 165.528446] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 166.039865] radeon :00:10.0: ring 0 stalled for more than 13312msec [ 166.039882] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 166.551351] radeon :00:10.0: ring 0 stalled for more than 13824msec [ 166.551368] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 167.062819] radeon :00:10.0: ring 0 stalled for more than 14336msec [ 167.062836] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 167.574331] radeon :00:10.0: ring 0 stalled for more than 14848msec [ 167.574348] radeon :00:10.0: GPU lockup (current fence id 0x01d6 last fence id 0x01d7 on ring 0) [ 167.798244] [TTM] Buffer eviction failed [ 167.940488] radeon: wait for empty RBBM fifo failed! Bad things might happen. [ 168.076053] Failed to wait GUI idle while programming pipes. Bad things might happen. [ 168.092258] radeon :00:10.0: Saved 91 dwords of commands on ring 0. [ 168.092380] radeon :00:10.0: (r100_asic_reset:2560) RBBM_STATUS=0x83F96100 [ 168.589895] radeon :00:10.0: (r100_asic_reset:2581) RBBM_STATUS=0x80010140 [ 169.083456] radeon :00:10.0: (r100_asic_reset:2589) RBBM_STATUS=0x0140 [ 169.083482] radeon :00:10.0: GPU reset succeed [ 169.083487] radeon :00:10.0: GPU reset succeeded, trying to resume [ 169.083550] radeon :00:10.0: WB disabled [ 169.083561] radeon :00:10.0: fence driver on ring 0 use gpu addr 0x and cpu addr 0x883a5378 [ 169.083612] [drm] radeon: ring at 0x1000 [ 169.228838] [drm:r100_ring_test [radeon]] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD) [ 169.228910] [drm:r100_cp_init [radeon]] *ERROR* radeon: cp isn't working (-22). [ 169.228919] radeon :00:10.0: failed initializing CP (-22). How should I go and debug this (other than plain git-bisect) ? For reference: # modprobe radeon ... [ 100.369890] [drm] radeon kernel modesetting enabled. [ 100.377816] checking generic (9c008000 5a000) vs hw (9800 800) [ 100.377824] fb: switching to radeondrmfb from OFfb ATY,RockHo [ 100.382566] Console: switching to colour dummy device 80x25 [ 100.386224] radeon :00:10.0: enabling device (0006 -> 0007) [ 100.389596] [drm] initializing kernel modesetting (RV280 0x1002:0x5962 0x1002:0x5962 0x01). [ 100.389783] radeon :00:10.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x [ 100.389813] radeon :00:10.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x [ 100.390218] [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM [ 100.390247] [drm] Using device-tree clock info [ 100.390286] agpgart-uninorth :00:0b.0: putting AGP V2 device into 4x mode [ 100.390300] radeon :00:10.0: putting AGP V2 device into 4x mode [ 100.390345] radeon :00:10.0: GTT: 256M 0x - 0x0FFF [ 100.390355] [drm] Generation 2 PCI interface, using max accessible memory [ 100.390368] radeon :00:10.0: VRAM: 128M 0x9800 - 0x9FFF (32M used) [ 100.390406] [drm] Detected VRAM RAM=128M, BAR=128M [ 100.390415] [drm] RAM width 64bits DDR [ 100.405414] [TTM] Zone kernel: Available graphics memory: 254062 kiB [ 100.405444] [TTM] Initializing pool allocator [ 100.405542] [drm] radeon: 32M of VRAM memory ready [ 100.405554] [drm] radeon: 256M of GTT memory ready. [ 100.406161] radeon :00:10.0: WB disabled [ 100.406187] radeon :00:10.0: fence driver on ring 0 use gp
Re: [PATCH v5 1/1] drm/amdgpu: Enable scatter gather display support
On Mon, Apr 23, 2018 at 12:44 PM, Samuel Li wrote:
> Enables sg display if vram size <= THRESHOLD(256M); otherwise
> still use vram as display buffer.
> This patch fixed some potention issues introduced by change
> "allow framebuffer in GART memory as well" due to CZ/ST hardware
> limitation.
>
> v2: Change default setting to auto.
> v3: Move some logic from amdgpu_display_framebuffer_domains()
> to pin function, suggested by Christian.
> v4: Split into several patches.
> v5: Drop module parameter for now.
>
> Signed-off-by: Samuel Li
Reviewed-by: Alex Deucher
We can add the checks for preferred domains as a follow on patch.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 59df4b7..2d75009 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -138,6 +138,7 @@ extern int amdgpu_si_support;
> extern int amdgpu_cik_support;
> #endif
>
> +#define AMDGPU_SG_THRESHOLD(256*1024*1024)
> #define AMDGPU_DEFAULT_GTT_SIZE_MB 3072ULL /* 3GB by default */
> #define AMDGPU_WAIT_IDLE_TIMEOUT_IN_MS 3000
> #define AMDGPU_MAX_USEC_TIMEOUT10 /* 100 ms */
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 1985c08..e62153a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -701,6 +701,15 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
> domain,
> return -EINVAL;
> }
>
> + /* This assumes only APU display buffers are pinned with (VRAM|GTT).
> +* See function amdgpu_display_supported_domains()
> +*/
> + if (domain == (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
> + domain = AMDGPU_GEM_DOMAIN_VRAM;
> + if (adev->gmc.real_vram_size <= AMDGPU_SG_THRESHOLD)
> + domain = AMDGPU_GEM_DOMAIN_GTT;
> + }
> +
> if (bo->pin_count) {
> uint32_t mem_type = bo->tbo.mem.mem_type;
>
> --
> 2.7.4
>
> ___
> 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 v5 1/1] drm/amdgpu: Enable scatter gather display support
Enables sg display if vram size <= THRESHOLD(256M); otherwise
still use vram as display buffer.
This patch fixed some potention issues introduced by change
"allow framebuffer in GART memory as well" due to CZ/ST hardware
limitation.
v2: Change default setting to auto.
v3: Move some logic from amdgpu_display_framebuffer_domains()
to pin function, suggested by Christian.
v4: Split into several patches.
v5: Drop module parameter for now.
Signed-off-by: Samuel Li
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 59df4b7..2d75009 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -138,6 +138,7 @@ extern int amdgpu_si_support;
extern int amdgpu_cik_support;
#endif
+#define AMDGPU_SG_THRESHOLD(256*1024*1024)
#define AMDGPU_DEFAULT_GTT_SIZE_MB 3072ULL /* 3GB by default */
#define AMDGPU_WAIT_IDLE_TIMEOUT_IN_MS 3000
#define AMDGPU_MAX_USEC_TIMEOUT10 /* 100 ms */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 1985c08..e62153a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -701,6 +701,15 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
return -EINVAL;
}
+ /* This assumes only APU display buffers are pinned with (VRAM|GTT).
+* See function amdgpu_display_supported_domains()
+*/
+ if (domain == (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
+ domain = AMDGPU_GEM_DOMAIN_VRAM;
+ if (adev->gmc.real_vram_size <= AMDGPU_SG_THRESHOLD)
+ domain = AMDGPU_GEM_DOMAIN_GTT;
+ }
+
if (bo->pin_count) {
uint32_t mem_type = bo->tbo.mem.mem_type;
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/pp: Add OVERDRIVE support on Vega10
On Mon, Apr 23, 2018 at 6:14 AM, Rex Zhu wrote:
> when bit14 in module parameter ppfeaturemask was set.
> od feature will be enabled on Vega10 except vbios not support.
>
> user can read od range by reading sysfs pp_od_clk_voltage,
> cat pp_od_clk_voltage
> OD_SCLK:
> 0:852Mhz800mV
> 1:991Mhz900mV
> 2: 1138Mhz950mV
> 3: 1269Mhz 1000mV
> 4: 1348Mhz 1050mV
> 5: 1399Mhz 1100mV
> 6: 1440Mhz 1150mV
> 7: 1500Mhz 1200mV
> OD_MCLK:
> 0:167Mhz800mV
> 1:500Mhz800mV
> 2:800Mhz950mV
> 3:945Mhz 1000mV
> OD_RANGE:
> SCLK: 852MHz 2200MHz
> MCLK: 167MHz 1500MHz
> VDDC: 800mV1200mV
>
> and can configure the clock/voltage by writing pp_od_clk_voltage
> for example:
>
> echo "s 0 900 820">pp_od_clk_voltage to change the sclk/vddc
> to 900MHz and 820 mV in dpm level0.
>
> echo "r" to change the clk/voltage to default value.
>
> echo "c">pp_od_clk_voltage
> to commit the change
>
> Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 719
> +++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h | 25 +-
> .../gpu/drm/amd/powerplay/inc/hardwaremanager.h| 6 +-
> 3 files changed, 389 insertions(+), 361 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index 384aa07..99d5974 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -285,6 +285,48 @@ static int vega10_set_features_platform_caps(struct
> pp_hwmgr *hwmgr)
> return 0;
> }
>
> +static int vega10_odn_initial_default_setting(struct pp_hwmgr *hwmgr)
> +{
> + struct vega10_hwmgr *data = hwmgr->backend;
> + struct phm_ppt_v2_information *table_info =
> + (struct phm_ppt_v2_information *)(hwmgr->pptable);
> + struct vega10_odn_dpm_table *odn_table = &(data->odn_dpm_table);
> + struct vega10_odn_vddc_lookup_table *od_lookup_table;
> + struct phm_ppt_v1_voltage_lookup_table *vddc_lookup_table;
> + struct phm_ppt_v1_clock_voltage_dependency_table *dep_table[3];
> + struct phm_ppt_v1_clock_voltage_dependency_table *od_table[3];
> + uint32_t i;
> +
> + od_lookup_table = &odn_table->vddc_lookup_table;
> + vddc_lookup_table = table_info->vddc_lookup_table;
> +
> + for (i = 0; i < vddc_lookup_table->count; i++)
> + od_lookup_table->entries[i].us_vdd =
> vddc_lookup_table->entries[i].us_vdd;
> +
> + od_lookup_table->count = vddc_lookup_table->count;
> +
> + dep_table[0] = table_info->vdd_dep_on_sclk;
> + dep_table[1] = table_info->vdd_dep_on_mclk;
> + dep_table[2] = table_info->vdd_dep_on_socclk;
> + od_table[0] = (struct phm_ppt_v1_clock_voltage_dependency_table
> *)&odn_table->vdd_dep_on_sclk;
> + od_table[1] = (struct phm_ppt_v1_clock_voltage_dependency_table
> *)&odn_table->vdd_dep_on_mclk;
> + od_table[2] = (struct phm_ppt_v1_clock_voltage_dependency_table
> *)&odn_table->vdd_dep_on_socclk;
> +
> + for (i = 0; i < 3; i++)
> + smu_get_voltage_dependency_table_ppt_v1(dep_table[i],
> od_table[i]);
> +
> + if (odn_table->max_vddc == 0 || odn_table->max_vddc > 2000)
> + odn_table->max_vddc =
> dep_table[0]->entries[dep_table[0]->count - 1].vddc;
> + if (odn_table->min_vddc == 0 || odn_table->min_vddc > 2000)
> + odn_table->min_vddc = dep_table[0]->entries[0].vddc;
> +
> + i = od_table[2]->count - 1;
> + od_table[2]->entries[i].clk =
> hwmgr->platform_descriptor.overdriveLimit.memoryClock;
> + od_table[2]->entries[i].vddc = odn_table->max_vddc;
> +
> + return 0;
> +}
> +
> static void vega10_init_dpm_defaults(struct pp_hwmgr *hwmgr)
> {
> struct vega10_hwmgr *data = hwmgr->backend;
> @@ -421,7 +463,6 @@ static void vega10_init_dpm_defaults(struct pp_hwmgr
> *hwmgr)
> /* ACG firmware has major version 5 */
> if ((hwmgr->smu_version & 0xff00) == 0x500)
> data->smu_features[GNLD_ACG].supported = true;
> -
> if (data->registry_data.didt_support)
> data->smu_features[GNLD_DIDT].supported = true;
>
> @@ -1360,48 +1401,6 @@ static int vega10_setup_default_dpm_tables(struct
> pp_hwmgr *hwmgr)
> memcpy(&(data->golden_dpm_table), &(data->dpm_table),
> sizeof(struct vega10_dpm_table));
>
> - if (PP_CAP(PHM_PlatformCaps_ODNinACSupport) ||
> - PP_CAP(PHM_PlatformCaps_ODNinDCSupport)) {
> - data->odn_dpm_table.odn_core_clock_dpm_levels.num_of_pl =
> -
> data->dpm_table.gfx_table.count;
> - for (i = 0; i < data
Re: [PATCH] drm/amdgpu: set COMPUTE_PGM_RSRC1 for SGPR/VGPR clearing shaders
On Mon, Apr 23, 2018 at 7:41 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Otherwise, the SQ may skip some of the register writes, or shader waves may
> be allocated where we don't expect them, so that as a result we don't actually
> reset all of the register SRAMs. This can lead to spurious ECC errors later on
> if a shader uses an uninitialized register.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198883
> Signed-off-by: Nicolai Hähnle
Should probably CC stable as well.
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index a2d77bcf9a78..bdce864ab8fe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -1452,64 +1452,67 @@ static const u32 sgpr_init_compute_shader[] =
> 0xbee60004, 0xbee70005,
> 0xbeea0006, 0xbeeb0007,
> 0xbee80008, 0xbee90009,
> 0xbefc, 0xbf8a,
> 0xbf81, 0x,
> };
>
> static const u32 vgpr_init_regs[] =
> {
> mmCOMPUTE_STATIC_THREAD_MGMT_SE0, 0x,
> - mmCOMPUTE_RESOURCE_LIMITS, 0,
> + mmCOMPUTE_RESOURCE_LIMITS, 0x100, /* CU_GROUP_COUNT=1 */
> mmCOMPUTE_NUM_THREAD_X, 256*4,
> mmCOMPUTE_NUM_THREAD_Y, 1,
> mmCOMPUTE_NUM_THREAD_Z, 1,
> + mmCOMPUTE_PGM_RSRC1, 0x14f, /* VGPRS=15 (64 logical VGPRs),
> SGPRS=1 (16 SGPRs), BULKY=1 */
> mmCOMPUTE_PGM_RSRC2, 20,
> mmCOMPUTE_USER_DATA_0, 0xedcedc00,
> mmCOMPUTE_USER_DATA_1, 0xedcedc01,
> mmCOMPUTE_USER_DATA_2, 0xedcedc02,
> mmCOMPUTE_USER_DATA_3, 0xedcedc03,
> mmCOMPUTE_USER_DATA_4, 0xedcedc04,
> mmCOMPUTE_USER_DATA_5, 0xedcedc05,
> mmCOMPUTE_USER_DATA_6, 0xedcedc06,
> mmCOMPUTE_USER_DATA_7, 0xedcedc07,
> mmCOMPUTE_USER_DATA_8, 0xedcedc08,
> mmCOMPUTE_USER_DATA_9, 0xedcedc09,
> };
>
> static const u32 sgpr1_init_regs[] =
> {
> mmCOMPUTE_STATIC_THREAD_MGMT_SE0, 0x0f,
> - mmCOMPUTE_RESOURCE_LIMITS, 0x100,
> + mmCOMPUTE_RESOURCE_LIMITS, 0x100, /* CU_GROUP_COUNT=1 */
> mmCOMPUTE_NUM_THREAD_X, 256*5,
> mmCOMPUTE_NUM_THREAD_Y, 1,
> mmCOMPUTE_NUM_THREAD_Z, 1,
> + mmCOMPUTE_PGM_RSRC1, 0x240, /* SGPRS=9 (80 GPRS) */
> mmCOMPUTE_PGM_RSRC2, 20,
> mmCOMPUTE_USER_DATA_0, 0xedcedc00,
> mmCOMPUTE_USER_DATA_1, 0xedcedc01,
> mmCOMPUTE_USER_DATA_2, 0xedcedc02,
> mmCOMPUTE_USER_DATA_3, 0xedcedc03,
> mmCOMPUTE_USER_DATA_4, 0xedcedc04,
> mmCOMPUTE_USER_DATA_5, 0xedcedc05,
> mmCOMPUTE_USER_DATA_6, 0xedcedc06,
> mmCOMPUTE_USER_DATA_7, 0xedcedc07,
> mmCOMPUTE_USER_DATA_8, 0xedcedc08,
> mmCOMPUTE_USER_DATA_9, 0xedcedc09,
> };
>
> static const u32 sgpr2_init_regs[] =
> {
> mmCOMPUTE_STATIC_THREAD_MGMT_SE0, 0xf0,
> mmCOMPUTE_RESOURCE_LIMITS, 0x100,
> mmCOMPUTE_NUM_THREAD_X, 256*5,
> mmCOMPUTE_NUM_THREAD_Y, 1,
> mmCOMPUTE_NUM_THREAD_Z, 1,
> + mmCOMPUTE_PGM_RSRC1, 0x240, /* SGPRS=9 (80 GPRS) */
> mmCOMPUTE_PGM_RSRC2, 20,
> mmCOMPUTE_USER_DATA_0, 0xedcedc00,
> mmCOMPUTE_USER_DATA_1, 0xedcedc01,
> mmCOMPUTE_USER_DATA_2, 0xedcedc02,
> mmCOMPUTE_USER_DATA_3, 0xedcedc03,
> mmCOMPUTE_USER_DATA_4, 0xedcedc04,
> mmCOMPUTE_USER_DATA_5, 0xedcedc05,
> mmCOMPUTE_USER_DATA_6, 0xedcedc06,
> mmCOMPUTE_USER_DATA_7, 0xedcedc07,
> mmCOMPUTE_USER_DATA_8, 0xedcedc08,
> --
> 2.14.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: fix the ib test hang when gfx is in "idle" state
On Mon, Apr 23, 2018 at 8:13 AM, Huang Rui wrote: > On Mon, Apr 23, 2018 at 05:57:06PM +0800, Koenig, Christian wrote: >> Hi Ray, >> >> Am 23.04.2018 11:47 schrieb Huang Rui : >> >> On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote: >> > Am 20.04.2018 um 11:40 schrieb Huang Rui: >> > > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)" >> > > Above patch defers the execution of gfx/compute ib tests. However, at >> that time, >> > > the gfx may already go into idle state. If "idle" gfx receives >> command >> > > submission, it will get hang in the system. So we must add is_gfx_on >> checking at >> > > start of ib tests. >> > >> > Do I see that right that you just skip the IB test when the GFX block >> is >> > already turned of? In this case that would be a clear NAK. >> > >> > BTW: How do you detect that we need to turn GFX on again? >> >> Christian, I know point. But there is a hang issue if we would like try >> to >> disable/enable gfxoff with SMC message at runtime. Actually, I am trying >> to >> find a good sequence to fix it. After that, I can even expose an debugfs >> interface to configure that. So I have to skip the test for the moment >> when >> gfx is in "idle". >> >> >> Working around that issue for the moment is ok, but please note that >> explicitly >> in both the commit message and a code comment. > > OK. Will add it at V2. > >> >> But don't you run into the same problem when the UMD starts to submit >> commands? > > When UMD starts, RLC firmware will detect the "draw" command, then it will > power up gfx. So it won't have problem at that time. The mainly state > machine doesn't expose to driver side yet. > >> >> I mean the idea of the IB test is that you "simulate" an userspace command >> submission and see if it works. >> > > Yes, agree. Any idea to "simulate" the "draw" command? Or please wait for > my fix for enabling/disabling gfxoff at runtime. Is there some special formatting in the IB required? I don't really see how this will work. There is likely tons of state before the actual draw command in the IB. Alex > > Thanks, > Ray > ___ > 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: RFC for a render API to support adaptive sync and VRR
On 2018-04-20 04:32 PM, Manasi Navare wrote: > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote: >>> Michel Dänzer writes: Time-based presentation seems to be the right approach for preventing micro-stutter in games as well, Croteam developers have been researching this. >>> >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present >>> extension offer the ability to specify the desired display time in >>> seconds. >>> >>> Similarly, I'd suggest that the min/max display refresh rate values be >>> advertised as time between frames rather than frames per second. > > So there is a global min and max refresh rate as advertised by the monitor > range descriptor. That I guess can be exposed as a global range in terms of > min and max time between frames as a global property of the connector. > > We dont need the per mode min and max refresh rate to be exposed right? If I understand VRR right, with CinemaVRR acceptable refresh rates might fall outside the range advertised by the monitor. Would we 1) advertise 24/1.001 as a lower bound, 2) expect media apps to use the lower bound simply for informational purposes, 3) or simply not support CinemaVRR? (1) has the added caveat that not all reported rates would be supported. Alternatively a bit could indicate that CinemaVRR is support, but I'm not sure if user mode would need all these details. Harry > >>> >>> I'd also encourage using a single unit for all of these values, >>> preferably nanoseconds. Absolute times should all be referenced to >>> CLOCK_MONOTONIC. >> >> +1 on everything Keith said. I got somehow dragged in khr vk >> discussions around preventing micro-stuttering, and consensus seems to >> be that timestamps for scheduling frames is the way to go, most likely >> absolute ones (not everything is running Linux unfortunately, so can't >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC). >> -Daniel > > And yes I also got consensus from Mesa and media folks about using the > absolute timestamp for scheduling the frames and then the driver will > modify the vblank logic to "present no earlier than the timestamp" > > Manasi > >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
Hi Ray, Am 23.04.2018 14:08 schrieb Huang Rui Hi Ray, > > Am 23.04.2018 11:47 schrieb Huang Rui : > > On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote: > > Am 20.04.2018 um 11:40 schrieb Huang Rui: > > > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)" > > > Above patch defers the execution of gfx/compute ib tests. However, at > that time, > > > the gfx may already go into idle state. If "idle" gfx receives command > > > submission, it will get hang in the system. So we must add is_gfx_on > checking at > > > start of ib tests. > > > > Do I see that right that you just skip the IB test when the GFX block is > > already turned of? In this case that would be a clear NAK. > > > > BTW: How do you detect that we need to turn GFX on again? > > Christian, I know point. But there is a hang issue if we would like try to > disable/enable gfxoff with SMC message at runtime. Actually, I am trying > to > find a good sequence to fix it. After that, I can even expose an debugfs > interface to configure that. So I have to skip the test for the moment > when > gfx is in "idle". > > > Working around that issue for the moment is ok, but please note that > explicitly > in both the commit message and a code comment. OK. Will add it at V2. > > But don't you run into the same problem when the UMD starts to submit > commands? When UMD starts, RLC firmware will detect the "draw" command, then it will power up gfx. So it won't have problem at that time. The mainly state machine doesn't expose to driver side yet. > > I mean the idea of the IB test is that you "simulate" an userspace command > submission and see if it works. > Yes, agree. Any idea to "simulate" the "draw" command? Or please wait for my fix for enabling/disabling gfxoff at runtime. Thanks, Ray ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
On Mon, Apr 23, 2018 at 05:57:06PM +0800, Koenig, Christian wrote: > Hi Ray, > > Am 23.04.2018 11:47 schrieb Huang Rui : > > On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote: > > Am 20.04.2018 um 11:40 schrieb Huang Rui: > > > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)" > > > Above patch defers the execution of gfx/compute ib tests. However, at > that time, > > > the gfx may already go into idle state. If "idle" gfx receives command > > > submission, it will get hang in the system. So we must add is_gfx_on > checking at > > > start of ib tests. > > > > Do I see that right that you just skip the IB test when the GFX block is > > already turned of? In this case that would be a clear NAK. > > > > BTW: How do you detect that we need to turn GFX on again? > > Christian, I know point. But there is a hang issue if we would like try to > disable/enable gfxoff with SMC message at runtime. Actually, I am trying > to > find a good sequence to fix it. After that, I can even expose an debugfs > interface to configure that. So I have to skip the test for the moment > when > gfx is in "idle". > > > Working around that issue for the moment is ok, but please note that > explicitly > in both the commit message and a code comment. OK. Will add it at V2. > > But don't you run into the same problem when the UMD starts to submit > commands? When UMD starts, RLC firmware will detect the "draw" command, then it will power up gfx. So it won't have problem at that time. The mainly state machine doesn't expose to driver side yet. > > I mean the idea of the IB test is that you "simulate" an userspace command > submission and see if it works. > Yes, agree. Any idea to "simulate" the "draw" command? Or please wait for my fix for enabling/disabling gfxoff at runtime. Thanks, Ray ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: set COMPUTE_PGM_RSRC1 for SGPR/VGPR clearing shaders
From: Nicolai Hähnle
Otherwise, the SQ may skip some of the register writes, or shader waves may
be allocated where we don't expect them, so that as a result we don't actually
reset all of the register SRAMs. This can lead to spurious ECC errors later on
if a shader uses an uninitialized register.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198883
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index a2d77bcf9a78..bdce864ab8fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1452,64 +1452,67 @@ static const u32 sgpr_init_compute_shader[] =
0xbee60004, 0xbee70005,
0xbeea0006, 0xbeeb0007,
0xbee80008, 0xbee90009,
0xbefc, 0xbf8a,
0xbf81, 0x,
};
static const u32 vgpr_init_regs[] =
{
mmCOMPUTE_STATIC_THREAD_MGMT_SE0, 0x,
- mmCOMPUTE_RESOURCE_LIMITS, 0,
+ mmCOMPUTE_RESOURCE_LIMITS, 0x100, /* CU_GROUP_COUNT=1 */
mmCOMPUTE_NUM_THREAD_X, 256*4,
mmCOMPUTE_NUM_THREAD_Y, 1,
mmCOMPUTE_NUM_THREAD_Z, 1,
+ mmCOMPUTE_PGM_RSRC1, 0x14f, /* VGPRS=15 (64 logical VGPRs), SGPRS=1
(16 SGPRs), BULKY=1 */
mmCOMPUTE_PGM_RSRC2, 20,
mmCOMPUTE_USER_DATA_0, 0xedcedc00,
mmCOMPUTE_USER_DATA_1, 0xedcedc01,
mmCOMPUTE_USER_DATA_2, 0xedcedc02,
mmCOMPUTE_USER_DATA_3, 0xedcedc03,
mmCOMPUTE_USER_DATA_4, 0xedcedc04,
mmCOMPUTE_USER_DATA_5, 0xedcedc05,
mmCOMPUTE_USER_DATA_6, 0xedcedc06,
mmCOMPUTE_USER_DATA_7, 0xedcedc07,
mmCOMPUTE_USER_DATA_8, 0xedcedc08,
mmCOMPUTE_USER_DATA_9, 0xedcedc09,
};
static const u32 sgpr1_init_regs[] =
{
mmCOMPUTE_STATIC_THREAD_MGMT_SE0, 0x0f,
- mmCOMPUTE_RESOURCE_LIMITS, 0x100,
+ mmCOMPUTE_RESOURCE_LIMITS, 0x100, /* CU_GROUP_COUNT=1 */
mmCOMPUTE_NUM_THREAD_X, 256*5,
mmCOMPUTE_NUM_THREAD_Y, 1,
mmCOMPUTE_NUM_THREAD_Z, 1,
+ mmCOMPUTE_PGM_RSRC1, 0x240, /* SGPRS=9 (80 GPRS) */
mmCOMPUTE_PGM_RSRC2, 20,
mmCOMPUTE_USER_DATA_0, 0xedcedc00,
mmCOMPUTE_USER_DATA_1, 0xedcedc01,
mmCOMPUTE_USER_DATA_2, 0xedcedc02,
mmCOMPUTE_USER_DATA_3, 0xedcedc03,
mmCOMPUTE_USER_DATA_4, 0xedcedc04,
mmCOMPUTE_USER_DATA_5, 0xedcedc05,
mmCOMPUTE_USER_DATA_6, 0xedcedc06,
mmCOMPUTE_USER_DATA_7, 0xedcedc07,
mmCOMPUTE_USER_DATA_8, 0xedcedc08,
mmCOMPUTE_USER_DATA_9, 0xedcedc09,
};
static const u32 sgpr2_init_regs[] =
{
mmCOMPUTE_STATIC_THREAD_MGMT_SE0, 0xf0,
mmCOMPUTE_RESOURCE_LIMITS, 0x100,
mmCOMPUTE_NUM_THREAD_X, 256*5,
mmCOMPUTE_NUM_THREAD_Y, 1,
mmCOMPUTE_NUM_THREAD_Z, 1,
+ mmCOMPUTE_PGM_RSRC1, 0x240, /* SGPRS=9 (80 GPRS) */
mmCOMPUTE_PGM_RSRC2, 20,
mmCOMPUTE_USER_DATA_0, 0xedcedc00,
mmCOMPUTE_USER_DATA_1, 0xedcedc01,
mmCOMPUTE_USER_DATA_2, 0xedcedc02,
mmCOMPUTE_USER_DATA_3, 0xedcedc03,
mmCOMPUTE_USER_DATA_4, 0xedcedc04,
mmCOMPUTE_USER_DATA_5, 0xedcedc05,
mmCOMPUTE_USER_DATA_6, 0xedcedc06,
mmCOMPUTE_USER_DATA_7, 0xedcedc07,
mmCOMPUTE_USER_DATA_8, 0xedcedc08,
--
2.14.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/pp: Add OVERDRIVE support on Vega10
when bit14 in module parameter ppfeaturemask was set.
od feature will be enabled on Vega10 except vbios not support.
user can read od range by reading sysfs pp_od_clk_voltage,
cat pp_od_clk_voltage
OD_SCLK:
0:852Mhz800mV
1:991Mhz900mV
2: 1138Mhz950mV
3: 1269Mhz 1000mV
4: 1348Mhz 1050mV
5: 1399Mhz 1100mV
6: 1440Mhz 1150mV
7: 1500Mhz 1200mV
OD_MCLK:
0:167Mhz800mV
1:500Mhz800mV
2:800Mhz950mV
3:945Mhz 1000mV
OD_RANGE:
SCLK: 852MHz 2200MHz
MCLK: 167MHz 1500MHz
VDDC: 800mV1200mV
and can configure the clock/voltage by writing pp_od_clk_voltage
for example:
echo "s 0 900 820">pp_od_clk_voltage to change the sclk/vddc
to 900MHz and 820 mV in dpm level0.
echo "r" to change the clk/voltage to default value.
echo "c">pp_od_clk_voltage
to commit the change
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 719 +++--
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h | 25 +-
.../gpu/drm/amd/powerplay/inc/hardwaremanager.h| 6 +-
3 files changed, 389 insertions(+), 361 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 384aa07..99d5974 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -285,6 +285,48 @@ static int vega10_set_features_platform_caps(struct
pp_hwmgr *hwmgr)
return 0;
}
+static int vega10_odn_initial_default_setting(struct pp_hwmgr *hwmgr)
+{
+ struct vega10_hwmgr *data = hwmgr->backend;
+ struct phm_ppt_v2_information *table_info =
+ (struct phm_ppt_v2_information *)(hwmgr->pptable);
+ struct vega10_odn_dpm_table *odn_table = &(data->odn_dpm_table);
+ struct vega10_odn_vddc_lookup_table *od_lookup_table;
+ struct phm_ppt_v1_voltage_lookup_table *vddc_lookup_table;
+ struct phm_ppt_v1_clock_voltage_dependency_table *dep_table[3];
+ struct phm_ppt_v1_clock_voltage_dependency_table *od_table[3];
+ uint32_t i;
+
+ od_lookup_table = &odn_table->vddc_lookup_table;
+ vddc_lookup_table = table_info->vddc_lookup_table;
+
+ for (i = 0; i < vddc_lookup_table->count; i++)
+ od_lookup_table->entries[i].us_vdd =
vddc_lookup_table->entries[i].us_vdd;
+
+ od_lookup_table->count = vddc_lookup_table->count;
+
+ dep_table[0] = table_info->vdd_dep_on_sclk;
+ dep_table[1] = table_info->vdd_dep_on_mclk;
+ dep_table[2] = table_info->vdd_dep_on_socclk;
+ od_table[0] = (struct phm_ppt_v1_clock_voltage_dependency_table
*)&odn_table->vdd_dep_on_sclk;
+ od_table[1] = (struct phm_ppt_v1_clock_voltage_dependency_table
*)&odn_table->vdd_dep_on_mclk;
+ od_table[2] = (struct phm_ppt_v1_clock_voltage_dependency_table
*)&odn_table->vdd_dep_on_socclk;
+
+ for (i = 0; i < 3; i++)
+ smu_get_voltage_dependency_table_ppt_v1(dep_table[i],
od_table[i]);
+
+ if (odn_table->max_vddc == 0 || odn_table->max_vddc > 2000)
+ odn_table->max_vddc = dep_table[0]->entries[dep_table[0]->count
- 1].vddc;
+ if (odn_table->min_vddc == 0 || odn_table->min_vddc > 2000)
+ odn_table->min_vddc = dep_table[0]->entries[0].vddc;
+
+ i = od_table[2]->count - 1;
+ od_table[2]->entries[i].clk =
hwmgr->platform_descriptor.overdriveLimit.memoryClock;
+ od_table[2]->entries[i].vddc = odn_table->max_vddc;
+
+ return 0;
+}
+
static void vega10_init_dpm_defaults(struct pp_hwmgr *hwmgr)
{
struct vega10_hwmgr *data = hwmgr->backend;
@@ -421,7 +463,6 @@ static void vega10_init_dpm_defaults(struct pp_hwmgr *hwmgr)
/* ACG firmware has major version 5 */
if ((hwmgr->smu_version & 0xff00) == 0x500)
data->smu_features[GNLD_ACG].supported = true;
-
if (data->registry_data.didt_support)
data->smu_features[GNLD_DIDT].supported = true;
@@ -1360,48 +1401,6 @@ static int vega10_setup_default_dpm_tables(struct
pp_hwmgr *hwmgr)
memcpy(&(data->golden_dpm_table), &(data->dpm_table),
sizeof(struct vega10_dpm_table));
- if (PP_CAP(PHM_PlatformCaps_ODNinACSupport) ||
- PP_CAP(PHM_PlatformCaps_ODNinDCSupport)) {
- data->odn_dpm_table.odn_core_clock_dpm_levels.num_of_pl =
- data->dpm_table.gfx_table.count;
- for (i = 0; i < data->dpm_table.gfx_table.count; i++) {
-
data->odn_dpm_table.odn_core_clock_dpm_levels.entries[i].clock =
-
data->dpm_table.gfx_table.dpm_levels[i].value;
-
data->odn_dpm_table.odn_core_clock_dpm_levels.entries[i].enabled = true;
-
Re: [PATCH] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
Hi Ray, Am 23.04.2018 11:47 schrieb Huang Rui : On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote: > Am 20.04.2018 um 11:40 schrieb Huang Rui: > > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)" > > Above patch defers the execution of gfx/compute ib tests. However, at that > > time, > > the gfx may already go into idle state. If "idle" gfx receives command > > submission, it will get hang in the system. So we must add is_gfx_on > > checking at > > start of ib tests. > > Do I see that right that you just skip the IB test when the GFX block is > already turned of? In this case that would be a clear NAK. > > BTW: How do you detect that we need to turn GFX on again? Christian, I know point. But there is a hang issue if we would like try to disable/enable gfxoff with SMC message at runtime. Actually, I am trying to find a good sequence to fix it. After that, I can even expose an debugfs interface to configure that. So I have to skip the test for the moment when gfx is in "idle". Working around that issue for the moment is ok, but please note that explicitly in both the commit message and a code comment. But don't you run into the same problem when the UMD starts to submit commands? I mean the idea of the IB test is that you "simulate" an userspace command submission and see if it works. Regards, Christian. Thanks, Ray On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote: > Am 20.04.2018 um 11:40 schrieb Huang Rui: > > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)" > > Above patch defers the execution of gfx/compute ib tests. However, at that > > time, > > the gfx may already go into idle state. If "idle" gfx receives command > > submission, it will get hang in the system. So we must add is_gfx_on > > checking at > > start of ib tests. > > Do I see that right that you just skip the IB test when the GFX block is > already turned of? In this case that would be a clear NAK. > > BTW: How do you detect that we need to turn GFX on again? Christian, I know point. But there is a hang issue if we would like try to disable/enable gfxoff with SMC message at runtime. Actually, I am trying to find a good sequence to fix it. After that, I can even expose an debugfs interface to configure that. So I have to skip the test for the moment when gfx is in "idle". Thanks, Ray ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
On Mon, Apr 23, 2018 at 05:52:28PM +0800, Huang Rui wrote: > On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote: > > Am 20.04.2018 um 11:40 schrieb Huang Rui: > > > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)" > > > Above patch defers the execution of gfx/compute ib tests. However, at > > > that time, > > > the gfx may already go into idle state. If "idle" gfx receives command > > > submission, it will get hang in the system. So we must add is_gfx_on > > > checking at > > > start of ib tests. > > > > Do I see that right that you just skip the IB test when the GFX block is > > already turned of? In this case that would be a clear NAK. > > > > BTW: How do you detect that we need to turn GFX on again? > > Christian, I know point. But there is a hang issue if we would like try to > disable/enable gfxoff with SMC message at runtime. Actually, I am trying to > find a good sequence to fix it. After that, I can even expose an debugfs > interface to configure that. So I have to skip the test for the moment when > gfx is in "idle". > And in normal case, driver won't explicitly turn on/off the gfx. RLC firmware will handle it. Thanks, Ray ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix the ib test hang when gfx is in "idle" state
On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote: > Am 20.04.2018 um 11:40 schrieb Huang Rui: > > "aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)" > > Above patch defers the execution of gfx/compute ib tests. However, at that > > time, > > the gfx may already go into idle state. If "idle" gfx receives command > > submission, it will get hang in the system. So we must add is_gfx_on > > checking at > > start of ib tests. > > Do I see that right that you just skip the IB test when the GFX block is > already turned of? In this case that would be a clear NAK. > > BTW: How do you detect that we need to turn GFX on again? Christian, I know point. But there is a hang issue if we would like try to disable/enable gfxoff with SMC message at runtime. Actually, I am trying to find a good sequence to fix it. After that, I can even expose an debugfs interface to configure that. So I have to skip the test for the moment when gfx is in "idle". Thanks, Ray ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: bo could be null when access in vm bo update
Reviewed-by: Chunming Zhou
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Junwei Zhang
Sent: Monday, April 23, 2018 5:29 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jerry
Subject: [PATCH] drm/amdgpu: bo could be null when access in vm bo update
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6a372ca..1c00f1a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1509,7 +1509,6 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
struct drm_mm_node *nodes;
struct dma_fence *exclusive, **last_update;
uint64_t flags;
- uint32_t mem_type;
int r;
if (clear || !bo_va->base.bo) {
@@ -1568,9 +1567,9 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
* the evicted list so that it gets validated again on the
* next command submission.
*/
- mem_type = bo->tbo.mem.mem_type;
if (bo && bo->tbo.resv == vm->root.base.bo->tbo.resv &&
- !(bo->preferred_domains & amdgpu_mem_type_to_domain(mem_type)))
+ !(bo->preferred_domains &
+ amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type)))
list_add_tail(&bo_va->base.vm_status, &vm->evicted);
spin_unlock(&vm->status_lock);
--
1.9.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] drm/amdgpu: bo could be null when access in vm bo update
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6a372ca..1c00f1a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1509,7 +1509,6 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
struct drm_mm_node *nodes;
struct dma_fence *exclusive, **last_update;
uint64_t flags;
- uint32_t mem_type;
int r;
if (clear || !bo_va->base.bo) {
@@ -1568,9 +1567,9 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
* the evicted list so that it gets validated again on the
* next command submission.
*/
- mem_type = bo->tbo.mem.mem_type;
if (bo && bo->tbo.resv == vm->root.base.bo->tbo.resv &&
- !(bo->preferred_domains & amdgpu_mem_type_to_domain(mem_type)))
+ !(bo->preferred_domains &
+ amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type)))
list_add_tail(&bo_va->base.vm_status, &vm->evicted);
spin_unlock(&vm->status_lock);
--
1.9.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [OOPS] [AMDGPU] Problem with R7 360 card and 4.16.x kernel.
On 2018-04-22 02:03 PM, Chris Rankin wrote: > Hi, > > I have recently upgraded to the 4.16 kernel, and have now noticed the > following appearing in my dmesg log. This didn't happen with the 4.15 > kernel. I am also noticing that my graphics card runs ~10C hotter with 4.16. > > The PCI numbers for this card are: 1002:665f (rev 81) > > More information available on request, > Cheers, > Chris > > [ 9229.654917] amdgpu :02:00.0: swiotlb buffer is full (sz: 2097152 > bytes) > [ 9229.660763] amdgpu :02:00.0: swiotlb: coherent allocation failed, > size=2097152 See https://bugs.freedesktop.org/show_bug.cgi?id=104082#c40 and later comments. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[OOPS] [AMDGPU] Problem with R7 360 card and 4.16.x kernel.
Hi, I have recently upgraded to the 4.16 kernel, and have now noticed the following appearing in my dmesg log. This didn't happen with the 4.15 kernel. I am also noticing that my graphics card runs ~10C hotter with 4.16. The PCI numbers for this card are: 1002:665f (rev 81) [ 9229.654917] amdgpu :02:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ 9229.660763] amdgpu :02:00.0: swiotlb: coherent allocation failed, size=2097152 [ 9229.667131] CPU: 4 PID: 18225 Comm: Wow-64.exe Tainted: G I 4.16.2 #1 [ 9229.673514] Hardware name: Gigabyte Technology Co., Ltd. EX58-UD3R/EX58-UD3R, BIOS FB 05/04/2009 [ 9229.681212] Call Trace: [ 9229.682393] dump_stack+0x46/0x59 [ 9229.684462] swiotlb_alloc_coherent+0x162/0x173 [ 9229.687758] ttm_dma_pool_get_pages+0x170/0x3f7 [ttm] [ 9229.691604] ttm_dma_populate+0xfb/0x29c [ttm] [ 9229.694784] ttm_tt_bind+0x2d/0x52 [ttm] [ 9229.697427] ttm_bo_handle_move_mem+0x11a/0x323 [ttm] [ 9229.701276] ? ttm_bo_mem_space+0x14c/0x370 [ttm] [ 9229.704732] ttm_bo_validate+0x76/0xd4 [ttm] [ 9229.707792] ? drm_vma_offset_add+0x3b/0x4f [drm] [ 9229.711268] ttm_bo_init_reserved+0x30b/0x3a3 [ttm] [ 9229.714945] amdgpu_bo_do_create+0x224/0x3be [amdgpu] [ 9229.718753] ? amdgpu_bo_unref+0x2f/0x2f [amdgpu] [ 9229.722325] ? amdgpu_vm_bo_update+0x3e1/0x426 [amdgpu] [ 9229.726275] amdgpu_bo_create+0x3e/0x181 [amdgpu] [ 9229.729788] amdgpu_gem_object_create+0x5c/0xd3 [amdgpu] [ 9229.733834] amdgpu_gem_create_ioctl+0x138/0x1f6 [amdgpu] [ 9229.737952] ? resched_curr+0x38/0x4f [ 9229.740351] ? amdgpu_gem_object_close+0x19f/0x19f [amdgpu] [ 9229.744639] drm_ioctl_kernel+0x5f/0x9b [drm] [ 9229.747699] drm_ioctl+0x1ef/0x2d5 [drm] [ 9229.750371] ? amdgpu_gem_object_close+0x19f/0x19f [amdgpu] [ 9229.754662] ? rpm_resume+0x89/0x3cb [ 9229.757059] amdgpu_drm_ioctl+0x45/0x73 [amdgpu] [ 9229.760399] vfs_ioctl+0x19/0x26 [ 9229.762353] do_vfs_ioctl+0x506/0x519 [ 9229.764725] ? __audit_syscall_entry+0xba/0xde [ 9229.767895] SyS_ioctl+0x4d/0x6f [ 9229.769854] do_syscall_64+0x5c/0xe7 [ 9229.772188] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 9229.776023] RIP: 0033:0x7f3af27290f7 [ 9229.778494] RSP: 002b:0326d8c8 EFLAGS: 0246 ORIG_RAX: 0010 [ 9229.778496] RAX: ffda RBX: 7f3a9aa8bbc0 RCX: 7f3af27290f7 [ 9229.778497] RDX: 0326d910 RSI: c0206440 RDI: 008a [ 9229.778498] RBP: 0326d910 R08: 7f3a9aa8bbc0 R09: 0004 [ 9229.778499] R10: 7f3a980008d0 R11: 0246 R12: c0206440 [ 9229.778500] R13: 008a R14: 0326d988 R15: 7f39d9e3e560 [ 9397.135877] amdgpu :02:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ 9397.141657] amdgpu :02:00.0: swiotlb: coherent allocation failed, size=2097152 [ 9397.147968] CPU: 6 PID: 18225 Comm: Wow-64.exe Tainted: G I 4.16.2 #1 [ 9397.154352] Hardware name: Gigabyte Technology Co., Ltd. EX58-UD3R/EX58-UD3R, BIOS FB 05/04/2009 [ 9397.161996] Call Trace: [ 9397.163182] dump_stack+0x46/0x59 [ 9397.165214] swiotlb_alloc_coherent+0x162/0x173 [ 9397.168526] ttm_dma_pool_get_pages+0x170/0x3f7 [ttm] [ 9397.172279] ttm_dma_populate+0xfb/0x29c [ttm] [ 9397.175432] ttm_tt_bind+0x2d/0x52 [ttm] [ 9397.178180] ttm_bo_handle_move_mem+0x11a/0x323 [ttm] [ 9397.181943] ? ttm_bo_mem_space+0x14c/0x370 [ttm] [ 9397.185381] ? __slab_alloc.isra.20.constprop.25+0x3d/0x46 [ 9397.189714] ttm_bo_validate+0x76/0xd4 [ttm] [ 9397.192713] ? drm_vma_offset_add+0x3b/0x4f [drm] [ 9397.196127] ttm_bo_init_reserved+0x30b/0x3a3 [ttm] [ 9397.199767] amdgpu_bo_do_create+0x224/0x3be [amdgpu] [ 9397.203536] ? amdgpu_bo_unref+0x2f/0x2f [amdgpu] [ 9397.206993] amdgpu_bo_create+0x3e/0x181 [amdgpu] [ 9397.210443] amdgpu_gem_object_create+0x5c/0xd3 [amdgpu] [ 9397.214533] amdgpu_gem_create_ioctl+0x138/0x1f6 [amdgpu] [ 9397.218637] ? preempt_count_add+0x75/0x87 [ 9397.221534] ? amdgpu_gem_object_close+0x19f/0x19f [amdgpu] [ 9397.225880] drm_ioctl_kernel+0x5f/0x9b [drm] [ 9397.225887] drm_ioctl+0x1ef/0x2d5 [drm] [ 9397.231658] ? amdgpu_gem_object_close+0x19f/0x19f [amdgpu] [ 9397.235979] ? rpm_resume+0x89/0x3cb [ 9397.238266] amdgpu_drm_ioctl+0x45/0x73 [amdgpu] [ 9397.241673] vfs_ioctl+0x19/0x26 [ 9397.243619] do_vfs_ioctl+0x506/0x519 [ 9397.245997] ? __audit_syscall_entry+0xba/0xde [ 9397.249175] SyS_ioctl+0x4d/0x6f [ 9397.251127] do_syscall_64+0x5c/0xe7 [ 9397.253434] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 9397.257208] RIP: 0033:0x7f3af27290f7 [ 9397.259522] RSP: 002b:0326d8c8 EFLAGS: 0246 ORIG_RAX: 0010 [ 9397.265814] RAX: ffda RBX: 7f39da2eaa90 RCX: 7f3af27290f7 [ 9397.271691] RDX: 0326d910 RSI: c0206440 RDI: 008a [ 9397.277600] RBP: 0326d910 R08: 7f39da2eaa90 R09: 0004 [ 9397.283566] R10: 7f3a980008d0 R11: 0246 R12: c0206440 [ 9397.283567] R13: 008a R14:
