+Cc Tvrtko On Sat, 2026-08-08 at 23:33 +0000, [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. > > 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. > > 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. > > 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.
That might be the wisest thing to do; but let's hear if Tvrtko has an idea for a hotfix first. > > 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. Thanks for your effort and help. I had dared to hope that we could get this one through without a regression, but reality always catches up.. P.
