Linux has 'almost no control' over GPU task priority, say the engineers rewriting it
The Linux kernel "has almost no control anymore over task prioritization" on modern graphics hardware, according to a slide shown by the two engineers writing its replacement. The claim comes from a Linux Plumbers Conference talk on October 5 by Daniel Almeida of Collabora and Philipp Stanner, whose employer the title slide gives as Red Hat.
A Steam Deck showing the SteamOS library screen. Credit: Valve. Image: Valve
Their subject is drm_sched, the kernel code that takes a game's command buffers, waits for their dependencies, hands them to the graphics card and steps in when one takes too long. The talk is listed as "GPU Job Scheduling: Current Development", a 30 minute slot in the Gaming on Linux microconference at the Prague Congress Centre, and its six page deck was read at 21:02 UTC on October 8.
The developers' own slide is the harshest review
One slide is headed "drm_sched codebase is in bad shape" and lists what is wrong with it: race conditions, inconsistent and even missing locking, dma_fence signalling issues, refcounting issues, legacy code, missing documentation and "Unclear / unenforced lifetimes of scheduler objects". For anyone who reads that as an opportunity, it adds: "In case you're searching for work: Code base contains many FIXMEs :)"
The deeper complaint is that the scheduler has been overtaken by the hardware. "Many GPUs don't have hardware rings anymore, but an arbitrary number of firmware rings," the deck says, so the "Scheduler now is not a scheduler anymore (for many drivers)", and the consequence is the line about task prioritisation. Its own open questions are whether firmware rings could be made preemptible, and whether priority levels could be set per ring through firmware.
The diagram of the arrangement that still works the old way is annotated "Depicted is the classic usecase, relevant e.g. for amdgpu (steam deck)". That is an example of the classic design rather than a complaint about any device, and the deck names no faulty hardware and no crashing game. Driver-level faults on that stack do get named elsewhere, as when Valve said grey colours in Linux VR streaming may be an AMD encoder bug, but this is a talk about the kernel's own plumbing.
A question put to game developers
The abstract asks the room something that rarely gets asked out loud. "One reason why drm_sched is in bad shape is that super-priority was given to performance, for example by omitting locks," it says. "Fixing some of these missing locks has been rejected, due to reported massive performance regressions. Would video game developers argue that ~100% reliability is worth significant sacrifices with frames per second?"
It also asks which GPUs and drivers are most important for gaming on Linux, and what the major kernel stability problems are, "e.g., crashing video games". Neither the deck nor the abstract blames a particular crash on drm_sched.
The replacement is Rust, and it is not a scheduler
The successor is drm::JobQueue, which the abstract says engineers at Collabora and Red Hat are developing together in Rust. It gives up on the name: "Not a scheduler: it tracks dependencies and lifecycle. The firmware decides what runs." Every job lives in one XArray, and a driver has to write exactly one callback.
The lifetime problems get handed to the compiler. "Teardown drains: dropping the queue signals every fence and guarantees no callback fires afterwards," one slide says, and another notes that a job outliving its JobQueue "does not compile". Its own open questions are whether the "stage" model is worth it at all and what data structure to use, so nothing here has replaced drm_sched yet. Until something does, the layer between a game and an AMD graphics card is the one its own developers describe as carrying many FIXMEs, and it is the firmware, not the kernel, that decides what runs first.
