On 09/08/2026 00:33, [email protected] wrote:
Since the DRM scheduler default policy was switched to FAIR in 7.2, sustained
100% GPU load in-game on my RX 9070 XT causes severe performance degradation.
In the example title running through Proton, Project Silverfish, the foreground
application degrades to roughly 10 fps or freezes outright while audio
continues, and the KDE Plasma Wayland session can lock up entirely, requiring a
reboot or killing the compositor to recover. The problem is not limited to
games. Running the game in the background + alt tabbing, then playing a YouTube
video can also cause the entire desktop to freeze.
Was there anything interesting in dmesg then the total UI lockup happened?
Then, if the game starts to stutter, either alt-tabbing, or opening up a menu
in game (which reduced the load on the GPU) immediately stops the stuttering.
The issue is reliably reproducible under sustained GPU saturation, although the
time-to-failure varies. Increasing shadow load (which decreases in-game frame
rate) substantially shortens the time-to-failure.
In game, MangoHud does not reveal any frametime discrepancy.
What exactly did you mean by not revealing discrepancy? Game is at 10fps
and HUD shows 10fps? Or game appears to stutter but HUD shows "normal" fps?
Bisection / test matrix
Reproducer: Project Silverfish (Proton) at settings that saturate the GPU, with
a second GPU client active (browser video). Other titles show the same symptom
under sustained load; I have not yet re-tested those specific titles against
the fix.
Could you list the other titles which showed the issue?
Regards,
Tvrtko
Kernel Result
torvalds/master stock FAIR (default) FAIL
same as above + reverts below gpu_sched.sched_policy=2 (FAIR) FAIL
same as above + reverts below gpu_sched.sched_policy=1 (FIFO) PASS
7.1.5 release PASS
drm-next FAIR (default) FAIL
Reverted Commits:
d09339388b77 drm/sched: Remove drm_sched_init_args->num_rqs
2833a0512b4c drm/sched: Remove drm_sched_init_args->num_rqs usage
16e7698bc04d drm/sched: Embed run queue singleton into the scheduler
77a6809f1dc3 drm/sched: Remove FIFO and RR and simplify to a single run queue
45c211ddf92a drm/sched: Switch default policy to fair
2462a0ce23b0 drm/amdgpu: Remove drm_sched_init_args->num_rqs usage
Kernel (failing): 7.2.0-rc6 (stock), also current drm-next
Kernel (working): 7.2.0-rc6-default-revert-00006-g7e5de9b07e3d with
sched_policy=1
7.1 release
Distro: Arch Linux
Session: KDE Plasma 6.7.4 / Wayland (KWin), Qt 6.11.1, KF 6.28.0
CPU: AMD Ryzen 9 9950X3D
RAM: 64 GiB
GPU: Sapphire Pulse Radeon RX 9070 XT
03:00.0 [1002:7550] rev c0, subsys Sapphire 1478
Motherboard: ASUS (AM5 / 800-series chipset)
Mesa: 26.1.6-arch1.1 (RADV, driverVersion 26.1.6)
Vulkan: instance 1.4.357 / device 1.4.354
On the same reverted kernel build, changing only gpu_sched.sched_policy from 2
(FAIR) to 1 (FIFO) changes the result from reliably failing to passing extended
stress testing.
Possible mitigation options
Given that 7.2 is late in the release cycle and 77a6809f1dc3 removes FIFO/RR as
selectable policies, there is currently no runtime workaround for affected
systems.
Revert 45c211ddf92a so FIFO remains the default while FAIR remains available
for further testing.
If necessary, also revert 77a6809f1dc3 and dependent changes to restore runtime
policy selection.
Alternatively, fix the underlying FAIR regression if a suitable fix can be
identified in time for 7.2.
I mention the revert options because the justification for removing FIFO/RR
included the absence of known regressions relative to those policies. This
report appears to provide at least one counterexample.
I am willing to test patches responsively and collect data if necessary.
