I have to correct my own report. The 90x figure I gave for a637a140ab86 does not hold up. Since sending it I have measured five more sessions, and the rate turns out to be controlled by something other than the kernel. Please do not spend time on the commit on the strength of that number.
What the artefact actually does is sit in one of two states, and the state changes during a session. All figures are events per 1000 eligible frames, where an eligible frame is one the detector could have judged - the method is unchanged from my first mail. 60 Hz 0.0000 0.0045 0.0252 120 Hz, quiet state 0.0308 0.0372 0.0400 120 Hz, excited state 0.5208 0.5739 0.7115 1.3027 1.9153 The three groups are about a decade apart from each other, and the kernel does not sort them. 0.0308 is the run on the kernel with a637a140ab86 reverted; 0.0372 and 0.0400 are runs on unreverted kernels in the quiet state. Those three are the same measurement. My original pair simply caught one kernel quiet and the other excited. Worse, every kernel comparison I made began with a reboot, and a reboot resets the state. So the bisect was measuring how soon after boot I happened to load the machine. I no longer consider the attribution to a637a140ab86 supported, and I cannot say from my data whether this is a 7.3 regression at all. The two transitions ------------------- I can now move the artefact in both directions, but only as bundles of variables - I have not separated what inside each bundle does the work. Excited by: a long session of a heavy 3D game (Dying Light: The Beast). Measured twice on the same kernel and refresh rate: 0.0372 -> 1.3027 (35x) and 0.0400 -> 0.5208 (13x). The effect outlasts the game by hours and decays gradually. That bundle contains sustained shader load, large VRAM allocation and eviction, GTT traffic, clock and power-state churn, heating, and fullscreen presentation. Calmed by: about three hours spent at 60 Hz, after which returning to 120 Hz gave 1.9153 -> 0.0400 (48x), on an unreverted kernel. That bundle contains two modesets, three hours of elapsed time, half the pixel clock, a different pixel encoding (this display uses YCbCr 4:2:0 at 120 Hz and 4:4:4 at 60 Hz), different watermarks, and an idle GPU. Also calmed by: a reboot. Which single variable in each bundle matters, I do not know. A short 120 -> 60 -> 120 toggle would separate "a modeset" from "time at 60 Hz", and a compute-only load would separate "GPU busy" from "memory pressure". I am happy to run whichever of those would be most useful. What did survive ---------------- The dependency on frame rate is unchanged and now rests on four independent sessions: 120 Hz and 100 Hz show the artefact, 60 Hz is at least an order of magnitude below the quiet 120 Hz state. Forcing YCbCr 4:2:0 at 60 Hz, so that the encoding matches 120 Hz, gave 0 events in 1,290,588 eligible frames, so this is frame rate and not chroma subsampling or link bandwidth. Swapping the HDMI cable made no difference. And one negative result that may be the most useful thing in this mail: DTN snapshots taken seconds after real events in the excited state are byte-identical to snapshots taken in the quiet state - 195 lines against 195, differing only in the scanout buffer address. Watermarks, dcfclk, dispclk, dppclk, fclk, HUBP and OTG underflow, vtotal and the DRR select bits, DSC, RQ, DLG and TTU are all the same in both states, at a fifty-fold difference in artefact rate. So whatever holds this state is not in anything DTN exposes. Is there something in DMCUB, in the memory path, or in link state that could persist across a game, decay over hours, be cleared by a reboot, and leave every register in the DTN dump identical? That is the question I am stuck on. Thorsten: the regzbot entry points at a637a140ab86 on the strength of the bisect above, which I no longer trust. I do not know yet whether there is a regression here at all, so I would rather not close it as invalid; please handle it however is appropriate for an entry whose attribution has fallen apart. The GitLab issue has been updated with the same correction: https://gitlab.freedesktop.org/drm/amd/-/work_items/5714 Sorry for the noise on the first pass. -- Thanks, Mikhail Gavrilov
