Re: [REGRESSION] drm/sched: FAIR policy causes serious performance degradation at max GPU load on 9070XT

[Luke . Wildhardt]

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 <tursulin@xxxxxxxxxxx> wrote:

>
> On 09/08/2026 00:33, Luke.Wildhardt@xxxxxxxxx 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.
> >
>
>