The band appears while DC switches the memory clock through
sub-viewport (SubVP). When SubVP is not in use, a kernel that contains
a637a140ab86 shows the same low rate as that commit's parent. On my
display, whether SubVP is used at 120 Hz is decided by a TV setting,
which also gives affected users a workaround.
Two runs on the same kernel (7.3-rc6), the same TV setting and ordinary
desktop use, differing only in the refresh rate. SubVP state and the
memory clock were read once a minute from amdgpu_dm_capabilities and
pp_dpm_mclk. SubVP never changed state within a run; the memory clock
stayed at 1249 MHz for the whole 120 Hz run and moved through all four
levels at 100 Hz:
mode SubVP memory clock events eligible per 1000 (95%)
4K@120 no 1249 MHz 5 1,582,072 0.0032 (0.0010-0.0074)
4K@100 yes 96..1249 MHz 139 712,333 0.195 (0.164-0.230)
138 of the 139 events at 100 Hz carry CRC triples that occur nowhere
else in the capture; the remaining one recurs seven times. All twenty
DTN snapshots taken after events show watermark set A at the register
maximum and a calculated DCFCLK of 400 MHz: the SubVP override in
dcn20_optimize_bandwidth() and MIN_SUBVP_DCFCLK_KHZ.
With SubVP in use the commit matters. The parent/commit pair I
reported earlier ran at 120 Hz in HDMI VRR mode, where DC uses SubVP
(the revert kernel's DTN snapshots carry the same two values), and
measured 0.0023 against 0.0807 per 1000. Without SubVP, the kernel
with the commit is at 0.0032.
Why a TV setting decides it
---------------------------
The LG OLED42C3 offers "VRR & G-Sync" (HDMI Forum VRR) and "AMD FreeSync
Premium". With the first, the EDID carries the HF-VSDB VRR range 40-120
Hz and no AMD VSDB; with the second, the HF-VSDB VRR range is zero and
an AMD VSDB v2 with 40-120 Hz appears. amdgpu_dm_update_freesync_caps()
takes FreeSync on HDMI only from the AMD VSDB, so:
- HDMI VRR mode: the stream has allow_freesync = false, and
dcn32_allow_subvp_high_refresh_rate() permits SubVP for a single
display at 120 Hz. amdgpu_dm_capabilities reports sub-viewport
enabled at 120 and 100 Hz; visual confirm 16 draws red at 120 Hz.
- FreeSync mode: SubVP is not permitted at 120 Hz. DC finds no
p-state method (watermark set A p-state 0, no visual confirm colour)
and keeps UCLK at its maximum, which pp_dpm_mclk showed for six
hours. At 100 Hz, below the 120 Hz threshold in
dcn32_assign_subvp_pipe(), SubVP is used in this mode too.
- 60 Hz, either mode: the switch happens in vactive without DMUB
(visual confirm 16: magenta). My 60 Hz runs measured between 0
and 0.025 per 1000, one of them 0 in 1,290,588 eligible frames.
All my earlier measurements were taken in HDMI VRR mode. The line
"FreeSync: enabled, range 40-120" in my original report was wrong: in
that mode amdgpu does not enable FreeSync.
For affected users with such a TV, selecting FreeSync instead of HDMI
VRR avoids SubVP at 120 Hz, at the cost of the memory clock staying at
its maximum. I have not tried amdgpu.dcdebugmask=0x20000
(DC_DISABLE_SUBVP_FAMS) in HDMI VRR mode; I can if that would help.
The question
------------
SubVP is carried out by the DMUB firmware, and DC budgets the
firmware's reaction time when it sizes the phantom pipe's MALL region:
subvp_fw_processing_delay_us = 15 and subvp_pstate_allow_width_us = 20
in dcn32_resource.c, used in dcn32_fpu.c. a637a140ab86 moves every DMUB
window -- instruction constants, stack, BSS data, mailbox, firmware
state and the rest -- from VRAM to GTT. Is the firmware's SubVP timing
sensitive to where its memory lives? Asking, not claiming.
DMCUB firmware here is 0x07003300 (7.0.51).
Also
----
A second user reports the same on an RX 7900 XT with two TVs over HDMI
at 120 Hz and above: from 7.3 on, not on a DisplayPort monitor, and gone
when he locks the GPU clocks. If the lock includes the memory clock, it
stops memory clock switching, which fits the above; I have asked which
VRR mode his TVs use:
https://gitlab.freedesktop.org/drm/amd/-/work_items/5714#note_3692576
Two more corrections to my original report. The DTN "CALCULATED
Clocks" line prints DC's calculated requirements, not the clocks the SMU
is running at, so it says nothing about clock transitions. And a
snapshot taken seconds after an event cannot exclude what the firmware
does around a switch: with SubVP it lowers watermark set A when the
switch starts, so "the watermark sets are configuration, not
instantaneous state" was wrong as well.
The GitLab issue has the same data:
https://gitlab.freedesktop.org/drm/amd/-/work_items/5714
--
Thanks,
Mikhail
