Here are some videos I took of what I encountered Stock 7.2.0-rc7 https://www.youtube.com/watch?v=DAmnZ25i1uA
The first patch you sent me: https://www.youtube.com/watch?v=86kYUwGwv2c My initial quick observation with the patch you sent me might have just been a fluke, or things were just right for it not to freeze entirely. Additional games I saw this in was Spyro: Reignited Trilogy Hitman: Absolution Same sort of deal, opening a menu (which reduced GPU load) recovered the game. At least in the original game, Project Silverfish, and a small amount of time in Spyro, it appeared that playing with gamescope stopped the issue from appearing. Maybe gamescope does something under the hood that changes the scheduling? On Tuesday, August 11th, 2026 at 12:46 AM, Tvrtko Ursulin <[email protected]> wrote: > > 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. > > > >
