KDE Plasma 6.8 cesse de faire transiter les images par la mémoire système quand une application dessine sur un GPU différent de celui du compositeur, ce qui est la première cause des mauvaises performances en GPU externe sous Wayland. Xaver Hugl a intégré à KWin la version 6 du protocole linux-dmabuf, qui permet au compositeur d'annoncer une liste de GPU plutôt qu'un seul et aux applications de choisir quel GPU importe un tampon. Sur un Framework Laptop 13 équipé d'une RX 5700 XT en boîtier externe, vkcube passe de 55 à 120 images par seconde et Cyberpunk 2077 en préréglage bas de 27 à 50. Les portables hybrides gagnent bien moins.
The short answer
Le développeur de KWin Xaver Hugl a publié le trente et un juillet les résultats de son travail sur le multi GPU. KWin implémente désormais la version 6 du protocole linux-dmabuf, qui permet à un compositeur Wayland d'annoncer plusieurs GPU au lieu d'un seul et aux clients de choisir quel GPU importe un tampon. Cela supprime l'aller retour forcé par la mémoire système quand une application dessine sur un GPU sur lequel le compositeur ne tourne pas. Les gains sont les plus élevés sur les GPU externes, où cet aller retour traversait un lien USB-C. Le travail arrive pour Plasma 6.8, exige Wayland plutôt que X11, et suppose l'écran raccordé au GPU principal.
Les boîtiers GPU externes sous Linux ont toujours eu un écart entre le matériel payé et le nombre d'images obtenu. La carte allait bien. Le goulet d'étranglement, c'était que chaque image terminée repartait par le câble d'où elle venait d'arriver.
Le problème était dans le protocole
Les compositeurs Wayland se passent les tampons via linux-dmabuf, et jusqu'ici ce protocole décrivait un seul GPU. Le compositeur annonçait « voici mon périphérique », et les clients allouaient des tampons que ce périphérique savait importer.
Cela convient quand il y a un GPU. Quand un jeu dessine sur une carte dédiée pendant que le compositeur tourne sur la carte intégrée, le tampon doit devenir lisible par le second périphérique, et le noyau y parvient en le faisant transiter par la mémoire système. Chaque image quitte la mémoire vidéo, traverse le bus et revient. Sur une carte interne c'est un impôt. Sur un GPU externe, où le bus est une connexion USB-C, c'est l'essentiel de vos performances.
La version 6 du protocole change la forme de la conversation. Le compositeur annonce une liste de GPU, et le client indique quel GPU doit importer un tampon donné. Dès lors que le compositeur peut afficher directement depuis la carte qui a dessiné l'image, il n'y a plus de copie à faire.
Le diff du protocole est la petite partie. Hugl décrit plus de deux ans de travail dans KWin pour y arriver : suivi de plusieurs GPU, gestion du branchement à chaud quand une carte apparaît ou disparaît, et construction d'un chemin Vulkan pour les copies multi GPU réellement inévitables, plus les changements côté pilote sans lesquels la copie ne peut pas être évitée du tout.
Les chiffres, et la machine dont ils viennent
Hugl a mesuré sur un Framework Laptop 13 avec une RX 5700 XT en boîtier externe, pilotant un écran 5120x1440 à 120 Hz.
vkcube est passé de 55 images par seconde à 120, soit la fréquence de rafraîchissement complète de l'écran : le plafond est désormais le moniteur et non le lien. Cyberpunk 2077 en préréglage bas est passé de 27 à 50, ce que Hugl chiffre à plus de 80% de mieux.
La réserve tient à la configuration, pas au code. Ce sont des chiffres de GPU externe, où la copie traversait un lien USB-C. Sur un portable dont le GPU dédié est soudé à côté de l'intégré, la copie n'a jamais été le coût principal, et Hugl attend plutôt de l'ordre de 5 à 10%.
Lisez les conditions avant d'espérer
Trois limites décident si tout cela vous parvient.
La composition se fait toujours sur le GPU principal. Le gain vient de l'affichage direct, donc l'écran doit être raccordé à ce GPU pour que le tampon aille droit à la dalle. Si votre moniteur est branché sur l'autre carte, le chemin que l'optimisation supprime est toujours emprunté.
Tout ce qui oblige le compositeur à toucher le tampon bloque l'optimisation. Sur du matériel sans prise en charge du pipeline de couleur, ce qui inclut le GPU de test de Hugl, cela veut dire HDR, mode nuit et profils colorimétriques désactivés pour obtenir le chemin rapide.
Et c'est réservé à Wayland. Hugl est direct sur la raison : implémenter le protocole utilement dans Xwayland est extrêmement difficile à cause des hypothèses que fait X11 sur le fonctionnement des tampons. Les applications X11 n'en profitent pas.
Il faut aussi l'autre moitié de la pile. Le pilote doit savoir qu'il peut sauter la copie, et cette prise en charge arrive dans Mesa et dans le pilote NVIDIA en parallèle du travail côté KWin.
La suite
Le billet est intitulé première partie. Hugl indique avoir déjà une demande de fusion ouverte pour lever la restriction qui impose la composition sur le GPU principal, c'est à dire la contrainte qui décide aujourd'hui qui en profite. La supprimer transformerait un correctif pour les gens dont l'écran est branché sur la bonne carte en un correctif pour quiconque fait tourner deux GPU.
Pour l'instant, si vous avez un GPU externe et une session Wayland, Plasma 6.8 est la version à surveiller. Si vous avez un portable hybride, attendez quelques pourcents et laissez vous agréablement surprendre s'il y a plus.
Sources et pour aller plus loin
- Xaver Hugl : réparer les performances multi GPU, première partie
- Phoronix : KDE Plasma 6.8 va profiter de gros gains en multi GPU et GPU externe
- Le bureau KDE Plasma
- Les protocoles Wayland, dont linux-dmabuf
Questions fréquentes
Qu'est ce qui n'allait pas avec le multi GPU avant cela ?
Le protocole linux-dmabuf ne permettait au compositeur d'annoncer qu'un seul GPU. Quand un jeu dessinait sur une carte dédiée ou externe pendant que le compositeur tournait sur la carte intégrée, le tampon devait devenir lisible par le GPU du compositeur, et le noyau réglait le problème en le faisant transiter par la mémoire système. Chaque image faisait donc un aller retour hors de la mémoire vidéo puis retour. Sur un GPU dédié interne cela vous coûte quelque chose. Sur un GPU externe derrière un lien USB-C, c'est quasiment catastrophique, puisque l'image traverse une connexion à une fraction de la bande passante.
Qu'apporte la version 6 du protocole ?
Elle permet au compositeur d'annoncer une liste de GPU au lieu d'un seul, et à une application d'indiquer quel GPU doit importer un tampon donné. Cela suffit à rendre la copie évitable : si le compositeur peut afficher directement un tampon depuis le GPU qui l'a produit, il n'y a plus rien à déplacer. Le changement de protocole est modeste, le travail derrière ne l'est pas. Hugl décrit plus de deux ans de chantier dans KWin, avec le suivi des GPU, la gestion du branchement à chaud et un nouveau chemin Vulkan pour les copies multi GPU qui restent inévitables.
Le gain est de combien, vraiment ?
Cela dépend entièrement de votre configuration, et le résumé honnête est que les GPU externes gagnent beaucoup et les portables hybrides internes gagnent peu. Sur la machine de test de Hugl, un Framework Laptop 13 avec une RX 5700 XT en boîtier pilotant un écran 5120x1440 à 120 Hz, vkcube est passé de 55 à 120 images par seconde, soit la fréquence de rafraîchissement complète de l'écran, et Cyberpunk 2077 en préréglage bas de 27 à 50, plus de 80% de mieux. Un portable hybride classique avec un GPU dédié interne se situe plutôt vers 5 à 10%, parce que le lien entre les deux GPU n'y est pas le goulet d'étranglement.
Quelles conditions faut-il réunir pour en profiter ?
Trois, et elles comptent. La composition se fait toujours sur le GPU principal, donc le bénéfice vient de l'affichage direct, ce qui suppose que l'écran soit raccordé à ce GPU. L'optimisation est bloquée dès que le compositeur ne peut pas transmettre le tampon intact à l'affichage, si bien que sur du matériel sans prise en charge du pipeline de couleur il faut désactiver le HDR, le mode nuit et les profils colorimétriques. Et c'est réservé à Wayland. Hugl est explicite : implémenter cela utilement dans Xwayland est très difficile à cause des hypothèses que fait X11, donc les applications X11 n'en bénéficient pas.
Le chantier est-il terminé ?
Non. Hugl appelle cela la première partie et indique qu'il a déjà une demande de fusion pour lever la restriction qui impose la composition sur le GPU principal, avec une seconde partie à suivre. Cette restriction est celle qui décide combien de configurations en profitent aujourd'hui, donc la lever fait la différence entre un correctif pour les gens dont l'écran est branché sur la bonne carte et un correctif pour tous ceux qui ont deux GPU. Il faut aussi l'autre moitié de la pile : le pilote doit savoir sauter la copie, et cette prise en charge arrive dans Mesa et dans le pilote NVIDIA en parallèle du travail côté KWin.