Linux 7.2 devait sortir avec la politique fair du planificateur DRM par défaut, en remplacement de la politique FIFO qu'AMDGPU et la plupart des pilotes graphiques du noyau utilisent depuis des années. Ce ne sera pas le cas. Tvrtko Ursulin, d'Igalia, qui a mené le travail sur le planificateur fair, a envoyé mardi 11 août une série de dix-neuf correctifs de retour arrière, après qu'un utilisateur a signalé qu'une charge GPU soutenue sur une Radeon RX 9070 XT faisait tomber un jeu à une dizaine d'images par seconde et pouvait figer complètement une session KDE Plasma Wayland. La version stable 7.2 étant attendue sous quelques jours, la politique est annulée et marquée expérimentale plutôt que corrigée dans l'urgence.
The short answer
La politique fair du planificateur DRM devait devenir la valeur par défaut de Linux 7.2, en remplacement de FIFO chez AMDGPU et les autres pilotes qui partagent ce planificateur. Un rapport de régression sur une Radeon RX 9070 XT a changé la donne. Tvrtko Ursulin, d'Igalia, qui a mené le travail sur la politique fair, a envoyé le mardi 11 août une série de dix-neuf correctifs qui rétablit FIFO et marque la politique fair comme expérimentale. La version stable 7.2 n'étant qu'à quelques jours, annuler était le geste sûr, pas un jugement sur la conception.
Il existe un type de rapport de bogue que les mainteneurs redoutent, et ce n'est pas celui qui décrit un plantage. C'est celui qui arrive six jours avant une version stable, décrit quelque chose d'intermittent, et fournit une reproduction qui se résume à : mettez le GPU sous charge et attendez.
C'est ce rapport qui a sorti le planificateur fair de Linux 7.2.
Ce qui devait sortir
Le planificateur DRM est du code partagé du noyau. Quand un pilote graphique a du travail à soumettre à un GPU, c'est cette couche qui décide qui passe en premier, et son usage dépasse largement les pilotes graphiques auxquels on pense d'abord : AMDGPU, Etnaviv, Panfrost et Nova, plus des pilotes d'accélérateurs comme ethosu, rocket et amdxdna.
Pendant des années, il a appliqué une politique FIFO. Les travaux passent dans l'ordre indiqué par leurs horodatages virtuels, ce qui est simple, prévisible, et parfaitement indifférent au fait qu'un client monopolise le matériel.
La politique fair, développée par Tvrtko Ursulin chez Igalia au fil de nombreuses rondes de relecture, s'inspire du raisonnement derrière le planificateur processeur. Au lieu du strict ordre d'arrivée, elle vise des parts proportionnelles, pour qu'un client interactif reste réactif pendant qu'une tâche de fond lourde travaille. Les essais s'étaient bien passés, y compris sur Steam Deck, et aucune régression d'ordonnancement face à FIFO n'était remontée. En faire la valeur par défaut de 7.2 semblait la suite logique, et le changement est arrivé via drm-misc-next plus tôt dans le cycle.
Le rapport qui a tout changé
Luke Wildhardt a déposé la régression pendant le week-end, et elle mérite une lecture attentive, car c'est sa forme qui est intéressante.
Une charge GPU pleine et soutenue sur une Radeon RX 9070 XT provoquait une dégradation sévère. Un jeu lancé via Proton tombait à une dizaine d'images par seconde, ou se figeait franchement pendant que son audio continuait. La session KDE Plasma Wayland pouvait se verrouiller entièrement, récupérable seulement par un redémarrage ou en tuant le compositeur.
Et pas seulement les jeux : laisser un jeu tourner en arrière-plan, revenir au bureau et lancer une vidéo pouvait figer tout l'environnement.
Deux détails font de ce rapport un rapport de planificateur plutôt qu'un rapport d'application. Réduire la charge GPU arrêtait le bégaiement immédiatement : revenir au bureau, ou ouvrir un menu dans le jeu, suffisait. Et augmenter la charge, en montant les ombres pour faire chuter la fréquence d'images, raccourcissait de façon fiable le délai avant panne. La saturation soutenue était le déclencheur, avec un délai variable mais une issue constante.
Pourquoi dix-neuf correctifs
C'est là que se comprend la pression du calendrier.
La politique fair n'est pas arrivée sous la forme d'un changement d'une ligne qu'il suffirait de repasser à l'envers. La série qui l'a introduite avait aussi simplifié le planificateur pour ne conserver qu'une seule file d'exécution, intégré ce singleton dans la structure même du planificateur, et supprimé les chemins FIFO et tourniquet devenus du code mort. Une fois le nombre de files figé à un, l'argument num_rqs que les pilotes passaient à drm_sched_init_args n'avait plus d'objet, et il a été retiré de tous les appelants.
Rétablir FIFO, c'est remettre tout cela. La série annule donc des changements dans amdgpu, etnaviv et les pilotes d'accélérateurs ethosu, rocket et amdxdna, en plus du cœur du planificateur.
Ursulin a envoyé une première version en vingt correctifs, puis une v2, puis une v3 ramenée à dix-neuf, le tout dans la même journée. Danilo Krummrich l'a acquittée et Philipp Stanner l'a relue.
Le dix-neuvième correctif est le seul qui ne soit pas un retour arrière. Il marque la politique fair comme expérimentale, avec un message de commit aussi bref que la situation le mérite : expérimentale jusqu'à ce que les régressions signalées soient traitées.
L'arbitrage qui mérite d'être remarqué
Avec la version stable 7.2 attendue le week-end suivant, Ursulin avait deux options. Déboguer en moins d'une semaine une régression dépendante de la charge, sur du matériel qu'il n'a pas sous la main, et livrer le correctif. Ou annuler, livrer la politique connue comme bonne, et prendre le temps de faire les choses correctement.
Il a choisi la seconde, et c'est le bon choix pour une raison qui n'a rien à voir avec les mérites techniques de l'une ou l'autre politique. Une régression d'ordonnancement qui n'apparaît que sous saturation soutenue est exactement le genre qui échappe à un correctif fait dans l'urgence et atterrit chez les utilisateurs. Le code fair n'est pas supprimé, il est étiqueté. Rien de la conception n'a été renié.
Nous avons écrit récemment sur Linux 7.2-rc7, arrivé volumineux et tard dans le cycle, et c'est le même cycle qui continue d'être agité jusqu'à la sortie.
Ce que cela change en pratique
Si vous utilisez un noyau de distribution, cette histoire raconte quelque chose qui ne vous arrivera pas. Linux 7.2 sort avec FIFO, la même politique que 7.1, et votre bureau se comporte comme avant.
Les personnes réellement concernées font tourner des versions candidates 7.2 sur du matériel AMD aujourd'hui. Si vous êtes sur une carte RDNA 4 et que vous constatez des gels de bureau ou un bégaiement sévère sous charge GPU soutenue, en soupçonnant Mesa, Proton ou votre compositeur, voilà un candidat sérieux pour la cause réelle. Cela se règle quand les correctifs arrivent.
Les mainteneurs de pilotes ont un point plus modeste à noter : num_rqs revient, donc tout ce qui a été rebasé sur l'interface simplifiée du planificateur mérite un nouveau regard.
Sources et pour aller plus loin
- Linux 7.2 to revert back to the FIFO DRM scheduler policy due to fair regressions, Phoronix, 12 août 2026
- PATCH v3 00/19, Revert switching default DRM scheduler policy to fair, dri-devel, 11 août 2026
- Linux 7.2 to set default DRM scheduler priority to fair, Phoronix
- Fair(er) DRM scheduler, LWN.net
- Fair(er) DRM GPU scheduler, Tvrtko Ursulin, blog Igalia
Questions fréquentes
À quoi sert le planificateur DRM, et pourquoi sa politique compte-t-elle ?
Tout pilote graphique du noyau qui soumet du travail à un GPU doit décider quels travaux passent en premier. Le planificateur DRM est le morceau de code partagé du noyau qui prend cette décision, et il est utilisé par AMDGPU, Xe, Panfrost, Etnaviv, le pilote Nova et un nombre croissant de pilotes d'accélérateurs. La politique, c'est la règle appliquée. FIFO est la plus simple : les travaux passent dans l'ordre indiqué par leurs horodatages virtuels. La politique fair s'inspire des idées du planificateur processeur et cherche à donner à chaque client une part proportionnelle du temps GPU, pour qu'un calcul en arrière-plan ne puisse pas affamer un bureau interactif. Les deux conceptions se défendent, et le choix reste invisible jusqu'au moment où quelque chose se passe mal : là, c'est la différence entre un bureau fluide et un bureau figé.
À quoi ressemblait exactement la régression ?
Luke Wildhardt l'a signalée contre la politique fair telle que livrée dans le cycle de développement 7.2. Une charge GPU soutenue à cent pour cent sur une Radeon RX 9070 XT provoquait une dégradation sévère : un jeu lancé via Proton tombait à une dizaine d'images par seconde ou se figeait purement et simplement pendant que son audio continuait, et la session KDE Plasma Wayland pouvait se verrouiller entièrement, exigeant un redémarrage ou la mise à mort du compositeur. Le problème ne se limitait pas aux jeux : laisser un jeu en arrière-plan, revenir au bureau puis lancer une vidéo pouvait figer tout l'environnement. Le signe révélateur, c'est que réduire la charge GPU arrêtait immédiatement le bégaiement, et que l'augmenter raccourcissait le délai avant panne. Ce motif désigne le planificateur, pas une application particulière.
Pourquoi annuler dix-neuf correctifs plutôt que corriger celui qui changeait la valeur par défaut ?
Parce que la politique fair n'est pas arrivée sous la forme d'un simple interrupteur. En plus de changer la valeur par défaut, la série avait simplifié le planificateur pour ne garder qu'une seule file d'exécution, intégré ce singleton dans la structure du planificateur, supprimé entièrement les chemins de code FIFO et tourniquet, puis retiré l'argument num_rqs devenu inutile chez tous les pilotes appelants. Pour rétablir FIFO, il faut remettre tout cela en place, d'où des retours arrière dans amdgpu, etnaviv et les pilotes d'accélérateurs ethosu, rocket et amdxdna, en plus du cœur du planificateur. Le dernier correctif est le seul qui ne soit pas un retour arrière : il marque la politique fair comme expérimentale pour que le travail survive pendant l'investigation.
Est-ce à dire que le planificateur fair était une mauvaise idée ?
Non, et la façon dont l'affaire a été traitée laisse penser que les mainteneurs ne le croient pas non plus. Le travail a traversé de nombreuses rondes de relecture, s'est bien comporté à l'essai, y compris sur Steam Deck, et aucune régression d'ordonnancement n'avait été trouvée face à FIFO avant ce rapport. Ce qui s'est produit, c'est qu'une régression est apparue tard dans le cycle, à quelques jours d'une version stable, sur une carte actuelle et répandue. Annuler dans ces conditions relève de la prudence, pas d'un verdict sur la conception. Danilo Krummrich a acquitté la série, Philipp Stanner l'a relue, et le code fair reste dans l'arbre derrière une étiquette expérimentale au lieu d'être supprimé.
Que faut-il faire, côté utilisateur ?
Pour presque tout le monde, rien. Si vous utilisez un noyau de distribution, vous recevrez 7.2 avec FIFO rétabli et le comportement que vous aviez déjà en 7.1, ce qui est précisément l'objectif de l'annulation. Le public à signaler, ce sont les personnes qui font tourner des versions candidates 7.2 sur du matériel AMD en ce moment, en particulier sur cartes RDNA 4, et qui constatent des gels du bureau sous charge soutenue en accusant Mesa, Proton ou leur compositeur. C'était très probablement cela, et le problème se réglera tout seul quand les correctifs arriveront. Si vous maintenez un pilote qui appelle le planificateur DRM, l'argument num_rqs revient, donc un rebasage vous attend.