[PATCH] Revert "drm/amd/display: Allocate DCN32/1 dmub memory to GTT"

[PATCH] Revert "drm/amd/display: Allocate DCN32/1 dmub memory to GTT"

[Calvin Owens]

After commit a637a140ab860310 ("drm/amd/display: Allocate DCN32/1 dmub
memory to GTT"), a machine with a Radeon RX 7900 shows random garbage on
the screen. It reproduces sporadically, but at times it is so bad the
machine is more or less unusable.

The garbage is always horizontal bars extending across the entire
screen, always approximately 200 pixels tall on a 3840x2160 screen,
for what looks like a single frame. The bars are mostly black, but will
sometimes exhibit striping and periodic artifacts which smell like
non-framebuffer data is being rendered to the screen.

It took some patience on the "good" side, but I was able to nail it down
to commit a637a140ab860310818a14fb4d37e39e51a06be4 with this bisect:

  bad: [cee9395acd8043be0644b25c34bfa86623f2b935] Linux 7.3-rc1
  good: [8d3ae59288f1e7d58d76558a6ee96d533bc5019f] Linux 7.2
  good: [55ab7e14222e5f0b0fd9f7711ca391d2924b35e3] Merge tag 'for-7.3/block-20260819' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
  bad: [df51bdc5e80dae43cab81f6cc641e98638303c88] Merge tag 'mtd/for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
  bad: [29daacacf4cd84e6917f09de6a99fb170071c14c] Merge tag 'drm-rust-next-2026-08-08' of https://gitlab.freedesktop.org/drm/rust/kernel into drm-next
  good: [fff648aec5e2790d117a0ec5c849a284d9d33d70] drm/amdgpu: include amdgpu_video_codecs.h only where needed
  bad: [336e0cd576817ac64a4b394ca2b3680029f3e37f] Revert "drm/amdgpu: fix aperture mapping leak"
  bad: [789f7486a384ca58b9d7a76abba5efa0e80e8dab] drm/amd/display: Test plane colorop helper walkers
  good: [e0e426f10ad653c5e9dd33fb4a76d55f06101992] drm/amd/display: Test helper_check_state rejects
  bad: [982b2a43682b55e7d9800000f2592832ff2865ba] drm/amdgpu: Fix IP block NULL check during soft reset
  bad: [9102b39fa924dcc3dc75a3137bfa9633c40b88c0] drm/amdgpu/userq: fix indefinite fence wait during GPU reset
  bad: [b23470a026afe64de5c1df4ad181587b49c22923] drm/amd/display: Exit LS for ISHARP before coefficient write
  bad: [f02b2e47355e9d381a7f34acc997e1c47879ca21] drm/amd/display: Add KUnit test for wb jobs
  bad: [c6a13d145cc811b19c8a0620f25868cf7d5700c0] drm/amd/display: remove unused dcn42 socbb values
  good: [1d8327353de6f1f34063840f362c208c84064f54] drm/amd/display: Fix VABC Init and OLED Support
  bad: [a637a140ab860310818a14fb4d37e39e51a06be4] drm/amd/display: Allocate DCN32/1 dmub memory to GTT
  first 'bad' commit: [a637a140ab860310818a14fb4d37e39e51a06be4] drm/amd/display: Allocate DCN32/1 dmub memory to GTT

Sure enough, reverting a637a140ab860310818a14fb4d37e39e51a06be4 on top
of v7.3 completely and totally eliminates the problem for me.

Mikhail has separately reported this regression:

  https://lore.kernel.org/all/20260829010525.29935-1-mikhail.v.gavrilov@gmail.com/

...but it seems to be much more consistent for me than for Mikhail, it's
never taken more than 30 minutes even when the machine is completely
idle. I've also never been able to reproduce any artifact one single
time without commit a637a140, despite a lot of effort.

I'm not sure reverting this is the right way forward, since presumably
this would re-regress the timing issue Fangzhi alluded to in the
original commit. But nobody has proposed anything concrete yet... so
let's start the discussion here.

I'm happy to help test other better ideas as well :)

Signed-off-by: Calvin Owens <calvin@wbinvd.org>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c    | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c
index 9ff25bc8ee5ae..870534b7cf46d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c
@@ -511,7 +511,6 @@ int dm_dmub_sw_init(struct amdgpu_device *adev)
 		DMUB_WINDOW_MEMORY_TYPE_FB,		/* DMUB_WINDOW_CURSOR_OFFLOAD */
 	};
 	int r;
-	int mem_domain = AMDGPU_GEM_DOMAIN_GTT;
 
 	switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) {
 	case IP_VERSION(2, 1, 0):
@@ -648,19 +647,13 @@ int dm_dmub_sw_init(struct amdgpu_device *adev)
 		return -EINVAL;
 	}
 
-	/* Limit to allocate dmub to GTT on DCN32/1
-	 * TODO: Other asics with GDDR7 may have worse latency
-	 */
-	if (dmub_asic != DMUB_ASIC_DCN32 &&
-	    dmub_asic != DMUB_ASIC_DCN321)
-		mem_domain |= AMDGPU_GEM_DOMAIN_VRAM;
-
 	/*
 	 * Allocate a framebuffer based on the total size of all the regions.
 	 * TODO: Move this into GART.
 	 */
 	r = amdgpu_bo_create_kernel(adev, region_info.fb_size, PAGE_SIZE,
-				    mem_domain,
+				    AMDGPU_GEM_DOMAIN_VRAM |
+				    AMDGPU_GEM_DOMAIN_GTT,
 				    &adev->dm.dmub_bo,
 				    &adev->dm.dmub_bo_gpu_addr,
 				    &adev->dm.dmub_bo_cpu_addr);
-- 
2.47.3

Re: [PATCH] Revert "drm/amd/display: Allocate DCN32/1 dmub memory to GTT"

[Mikhail Gavrilov]

I see the same kind of single-frame band across the whole screen on an
RX 7900 XTX driving a 3840x2160 TV over HDMI, and measured a637a140ab86
against the same parent: 35 times more events, over about eleven hours
each [1].  What I found since may help decide how to fix it: here the
band needs both the commit and DC switching the memory clock through
sub-viewport (SubVP).  With either one missing, the rate stays at the
same low level.

Events per 1000 eligible frames (frames whose neighbours show unchanged
content), counted with the CRTC CRC as described in my report [4]:

  kernel                 refresh  SubVP  events / eligible  per 1000
  1d8327353de6 (parent)  4K@120   yes       7 / 3,019,571     0.0023
  a637a140ab86           4K@120   yes     293 / 3,632,444     0.0807
  7.3-rc6                4K@120   no        5 / 1,582,072     0.0032
  7.3-rc6                4K@100   yes     139 /   712,333     0.195

7.3-rc6 contains the commit.  The 4K@120 runs with and without SubVP
differ in the TV's VRR setting, which decides whether DC may use SubVP
at that rate; without SubVP, DC keeps the memory clock at its
maximum [2].  In the 4K@100 run, 138 of the 139 bad frames have CRCs
that occur nowhere else in the capture, so the content of the band is
new nearly every time, which fits your "non-framebuffer data".

A second user, on an RX 7900 XT, sees the band over HDMI and over
DisplayPort whenever amdgpu_dm_capabilities reports SubVP enabled, and
not when it is disabled [3].  The DC debugging documentation describes
this kind of symptom: "a horizontal fillet of flickering happens in some
specific part of the screen.  This could be an indication of
Sub-Viewport issues" (Documentation/gpu/amdgpu/display/dc-debug.rst).
It suggests force_disable_subvp to check; on a stock kernel that is
amdgpu.dcdebugmask=0x20000.

Since it reproduces within 30 minutes for you, could you check three
things on an unreverted kernel?

  1. The refresh rate, HDMI or DisplayPort, whether VRR/FreeSync is
     on, and what amdgpu_dm_capabilities says:

       sudo sh -c 'head -v /sys/kernel/debug/dri/0000:*/amdgpu_dm_capabilities'

  2. Whether the bars always appear in the same part of the screen,
     as in the documentation's description, and if so, where.

  3. Whether they come back when booted with amdgpu.dcdebugmask=0x20000.
     amdgpu_dm_capabilities should then say "sub-viewport supported:
     yes, enabled: no", and the memory clock may stay at its maximum.

I have not run the third test myself.

The commit moved DMUB memory to GTT because data from DMCUB sometimes
reached the driver late, after DMCUB had signalled it.  SubVP is a path
where DMCUB itself works to a deadline: DC budgets 15 us for its
processing when it sizes the SubVP region (subvp_fw_processing_delay_us
in dcn32_resource.c).  Since the commit, the windows the driver sets up
for the firmware's data, mailbox and state are in system memory.
Whether that can make the firmware miss its deadline is what I asked
AMD earlier [2]; it is still open.

If this goes in, Fixes: a637a140ab86 with Cc: stable would take it to
7.3.y, and a Closes: tag pointing at my report [4] would let the
regression tracker close it.

[1] https://lore.kernel.org/all/20260919200820.799243-1-mikhail.v.gavrilov@gmail.com/
[2] https://lore.kernel.org/all/20261011201833.853907-1-mikhail.v.gavrilov@gmail.com/
[3] https://gitlab.freedesktop.org/drm/amd/-/work_items/5714
[4] https://lore.kernel.org/all/20260829010525.29935-1-mikhail.v.gavrilov@gmail.com/

-- 
Thanks,
Mikhail

Re: [PATCH] Revert "drm/amd/display: Allocate DCN32/1 dmub memory to GTT"

[Josh Kasten]

I am able to reproduce this issue on kernel 7.3 on the AMD RX 7900 XT GPU.
* XT is not a typo, however both XT & XTX variants are Navi 31 anyway.
Never seen this issue on 7.2.8, 7.2.11, or 6.18.54.

### Conditions to reproduce banding issue
#### 1. When sub-viewport (AKA SubVP) is enabled
Check if it is enabled with the following command:
`sudo sh -c 'head -v /sys/kernel/debug/dri/0000:*/amdgpu_dm_capabilities'`

I think the amdgpu driver is in control when SubVP is enabled. In my testing
with a single active display this gets enabled when at 4K and it's frequency
is 100hz to 120 hz, inclusive.
Mikhail Gavrilov gave me this description for additional conditions if SubVP
get enabled:
> On DCN 3.2, SubVP itself is limited to:

> * refresh below 120 Hz; or 120–175 Hz for 3840x2160, 3440x1440, 2560x1440
> and 1920x1080 without scaling, and then, on a single display, only with
> FreeSync off;
> * pixel rate up to 1800 MHz;
> * no overlay planes and no rotation.

#### 2. Memory clock changes
Make sure the video memory clocks are not locked as the banding only happens
when the GPU changes it's memory frequency when the frame is being outputted.

This happens more often if the GPU is mostly idle and you move a window or
resize it in a desktop environment like KDE. I see it as often as a few times
a second, but sometimes it takes up to 10 seconds of doing this.

#### 3. 10x more often if amdgpu overdrive is enabled
While I know AMD overdrive needs to be disabled before reporting a bug enabling
it will allow you to reproduce the bug more often and faster. When 
`amdgpu.ppfeaturemask=0xfffd7fff` is set I see this bug about 10x more often.

### Confirmed revert of a637a140 fully fixes this
I confirm on next-20261023 by reverting a637a140 I am no longer seeing this
issue.

The revert didn't go clean on kernel next-20261023, as there was some changes
on top, so attached is the patch I generated for the revert of commit a637a140.

### Summary

I don't understand the optimization done in commit a637a140, or if there is
another related commit that should also be reverted. However what I can say
is I haven't notice any side effects after running with this revert for a few
days so far. It might be worth considering reverting commit a637a140 in a 7.3.x
patch release until a new fix can be tested in next.

Hoping this gets resolved in a future kernel release soon, the banding gets
to me sometimes and won't want this happing on other AMD GPUs. :(
Let me know if I can help at all with any additional testing or information!

Signed-off-by: Josh Kasten <jkasten@gmail.com>
---
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c
@@ -538,7 +538,6 @@ int dm_dmub_sw_init(struct amdgpu_device *adev)
 		DMUB_WINDOW_MEMORY_TYPE_FB,		/* DMUB_WINDOW_CURSOR_OFFLOAD */
 	};
 	int r;
-	int mem_domain = AMDGPU_GEM_DOMAIN_GTT;
 
 	switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) {
 	case IP_VERSION(2, 1, 0):
@@ -675,19 +674,13 @@ int dm_dmub_sw_init(struct amdgpu_device *adev)
 		return -EINVAL;
 	}
 
-	/* Limit to allocate dmub to GTT on DCN32/1
-	 * TODO: Other asics with GDDR7 may have worse latency
-	 */
-	if (dmub_asic != DMUB_ASIC_DCN32 &&
-	    dmub_asic != DMUB_ASIC_DCN321)
-		mem_domain |= AMDGPU_GEM_DOMAIN_VRAM;
-
 	/*
 	 * Allocate a framebuffer based on the total size of all the regions.
 	 * TODO: Move this into GART.
 	 */
 	r = dmub_bo_create_kernel(adev, region_info.fb_size, PAGE_SIZE,
-				  mem_domain,
+				  AMDGPU_GEM_DOMAIN_VRAM |
+				  AMDGPU_GEM_DOMAIN_GTT,
 				  &adev->dm.dmub_bo,
 				  &adev->dm.dmub_bo_gpu_addr,
 				  &adev->dm.dmub_bo_cpu_addr);
---