Le noyau Linux 7.3 corrige un problème de deadlock et introduit des heuristiques pour limiter le ralentissement quand la VRAM vient à manquer,

Ce qui a un impact sur les GPU dotés de mémoire vidéo limitée

Le noyau Linux 7.3 apporte des améliorations majeures pour optimiser la gestion de la mémoire vidéo (VRAM). Développées initialement par Natalie Vock chez Valve pour SteamOS, ces nouveautés permettent aux systèmes de mieux supporter l'overcommitment, évitant ainsi les plantages lorsque les jeux dépassent la capacité physique du processeur graphique. Le nouveau code résout un problème de deadlock complexe et introduit des heuristiques de régulation pour empêcher le transfert incessant de données entre la VRAM et la mémoire vive. Grâce à ces optimisations, les performances restent acceptables même en situation de saturation.

Le noyau Linux 7.3 introduit des modifications importantes pour améliorer l'expérience de jeu sur les systèmes disposant d'une mémoire vidéo limitée. Ce travail vise à rendre la saturation de la VRAM beaucoup moins pénalisante, en particulier pour le pilote de cartes graphiques AMDGPU. Auparavant, dépasser la capacité physique de la VRAM provoquait souvent des effondrements de performance majeurs ainsi que des plantages de l'application.

Désormais, le système gère cette surcharge de manière beaucoup plus fluide en permettant au GPU d'accéder plus efficacement à la mémoire système globale. Comme le souligne Natalie Vock : « avec ces correctifs, l'overcommit de la VRAM n'est pas vraiment un problème aussi important qu'on pourrait le penser au premier abord ». Cette optimisation est d'ores et déjà déployée dans les versions stables et préliminaires du SteamOS de Valve.

Contraintes physiques et impact de l'overcommit de la VRAM

Lorsqu'un jeu demande plus de VRAM qu'il n'en existe physiquement, le pilote doit déplacer ou évincer une partie des données vers la mémoire vive classique du processeur. Cependant, pour le processeur graphique, lire des données stockées dans la RAM système s'avère extrêmement lent, car l'accès doit obligatoirement transiter par le bus PCI Express, ce qui limite drastiquement la bande passante disponible et augmente la latence du système.


Par exemple, avec une connexion PCIe 4.0x16, la bande passante maximale utilisable est légèrement inférieure à 32 Go/s, soit environ 32,2 Mo de données transférables par milliseconde. Pour maintenir un affichage fluide à un minimum de 30 images par seconde, le temps d'affichage par image ne doit pas dépasser 33,3 millisecondes, limitant ainsi la quantité absolue de données évincées que le GPU peut récupérer à environ 1 Go par image.

Si le GPU doit lire plus d'un gigaoctet de données par image hors de sa mémoire dédiée, l'objectif des 30 images par seconde devient physiquement impossible à atteindre. Néanmoins, l'impact réel de l'éviction varie considérablement selon la structure des accès à la mémoire et l'utilisation du cache.

Si les données accédées tiennent dans le cache L2 du GPU (qui est de 6 Mo sur une architecture RDNA3), la latence d'accès reste inchangée, que la mémoire sous-jacente se trouve dans la VRAM ou dans la RAM du processeur. Mais un échec de cache obligeant à traverser le bus PCIe se traduit par une latence 7,3 fois plus élevée qu'un accès au cache de niveau supérieur (Infinity Cache) et 4,6 fois plus élevée qu'une lecture directe en VRAM.

Résolution des blocages et intégration de drm_exec dans TTM

Sur le plan de la stabilité, la saturation de la VRAM provoquait jusqu'ici des dysfonctionnements critiques. Le pilote graphique RADV renvoyait régulièrement l'erreur « radv/amdgpu: Not enough memory for command submission », car le noyau signalait une erreur d'absence de mémoire (-ENOMEM) au moment de soumettre les commandes graphiques, alors même que les allocations de ressources initiales avaient été acceptées sans problème.

Cette anomalie s'expliquait par des conflits d'accès dans la gestion des verrous du noyau : à chaque soumission de commande, le pilote AMDGPU doit verrouiller les ressources mémoire référencées par le GPU pour éviter qu'une autre application ne les déplace. Si deux processus concurrents tentaient simultanément d'effectuer des soumissions tout en essayant d'évincer des ressources verrouillées par l'autre, ils se retrouvaient dans une situation d'interblocage réciproque (ou ABBA deadlock).

Bien que le noyau Linux possède un mécanisme robuste de détection et de résolution des interblocages basé sur des boucles d'annulation et de reprise, la bibliothèque de gestion de mémoire partagée pour les GPU, nommée TTM, n'exploitait pas le gestionnaire de verrous standard drm_exec. En adaptant et en corrigeant des correctifs existants pour intégrer drm_exec au sein de TTM, Natalie Vock a réussi à éliminer ces échecs de verrouillage brutaux, transformant les plantages de jeux en de simples ralentissements gérables.

Le problème du ping-ponging et des images de scanout contiguës

Une fois les plantages résolus, les analyses ont révélé une autre anomalie de performance : le ping-ponging de la mémoire. Deux processus gourmands, à l'instar de gamescope et d'un jeu vidéo, passaient leur temps à s'évincer mutuellement les mêmes blocs de données de la mémoire vidéo, ce qui effondrait les performances à un niveau inférieur à celui obtenu si les données n'avaient jamais été déplacées en VRAM.

Le principal coupable de cette instabilité était la mémoire d'affichage liée au scanout. Le matériel d'affichage nécessite que les images destinées à être projetées sur l'écran soient stockées dans un espace physique de la VRAM qui soit entièrement contigu, en contournant l'architecture de mémoire virtuelle du GPU.

Lorsque la mémoire vidéo est saturée et fragmentée, le déplacement d'un espace de scanout hors de la VRAM, suivi de sa réintégration immédiate lors du rafraîchissement d'écran, poussait l'algorithme d'éviction très rudimentaire du noyau à faire de la place par la force. Natalie Vock a constaté que jusqu'à 4 Go de données de VRAM importantes étaient parfois vidés pour faire de la place à une unique image de scanout de seulement 32 Mo, provoquant des pauses de transfert de l'ordre de 130 millisecondes.

Pour corriger ce problème, de nouvelles heuristiques d'attente ont été implémentées. Lors d'une éviction détectée, le pilote entre d'abord dans une phase de « restriction stricte » de quelques millisecondes durant laquelle il s'interdiet de rapatrier des données de l'application en VRAM. Il passe ensuite par une phase de « restriction souple » de plusieurs secondes où il réutilise l'espace VRAM qui se libère sans forcer l'éviction de données d'autres applications, avant de lever les restrictions une fois la stabilité retrouvée.

L'étape finale de l'optimisation réside dans la capacité des applications à communiquer directement leurs besoins prioritaires au pilote graphique. Cela s'effectue grâce à l'extension Vulkan « VK_EXT_pageable_device_local_memory » et sa fonction associée « vkSetDeviceMemoryPriorityEXT ». Natalie Vock a connecté ces priorités d'applications à la liste de traitement d'éviction du noyau. Ainsi, au lieu d'évincer des ressources de manière aléatoire ou simplement chronologique, le noyau trie sa liste pour évincer en priorité absolue les blocs mémoire déclarés comme de faible importance par l'application.

Bien que peu de jeux Vulkan natifs intègrent directement cette extension, la couche de compatibilité « vkd3d-proton » (utilisée pour traduire les jeux Direct3D 12 sous Linux) relaie automatiquement les priorités définies par les APIs de Microsoft vers le pilote Vulkan. Cette synergie de priorités rend les performances en cas de surcharge beaucoup plus stables dans le temps et permet des gains de performance allant jusqu'à 30 % dans les scénarios de forte saturation par rapport à une éviction non hiérarchisée.

Résultats pratiques et performances mesurées en jeu

L'efficacité de l'ensemble de ces optimisations a été démontrée à travers des tests poussés sur le jeu « Indiana Jones: The Great Circle». En configurant le titre de manière à solliciter 9 Go de mémoire sur un système équipé d'une carte graphique de 8 Go (soit 1 Go de surcharge stocké dans la RAM système), le jeu est resté parfaitement jouable, affichant un temps de calcul moyen de 19,6 millisecondes par image.

En poussant l'exigence graphique à 10 Go (soit 2 Go de surcharge), la moyenne s'est établie autour de 29,8 millisecondes par image, bien qu'au prix d'une variabilité et de pics de saccades plus marqués. L'expérience globale démontre que malgré la baisse inévitable de performance liée à l'utilisation de la RAM système, le ralentissement reste tout à fait tolérable grâce à une coordination intelligente entre les applications, le pilote graphique et le système d'exploitation.

Les modifications apportées au noyau pour améliorer la gestion de la VRAM devraient être intégrées au noyau Linux 7.3. Natalie Vock poursuit également ses efforts pour apporter encore davantage d’améliorations au comportement de gestion de la mémoire vidéo des pilotes GPU sous Linux.

Qui en bénéficie le plus ?

Ces changements sont particulièrement importants pour deux groupes. Les joueurs équipés de cartes graphiques plus anciennes disposant d’une mémoire vidéo (VRAM) limitée constateront moins de baisses de fréquence d’images lorsqu’ils poussent les paramètres à l’extrême. Les utilisateurs professionnels travaillant avec des textures volumineuses ou des scènes 3D complexes pourront continuer à travailler sans subir de blocages soudains.

Les améliorations sont moins perceptibles sur les cartes graphiques haut de gamme dotées d’une mémoire vidéo abondante, mais même dans ce cas, la nouvelle gestion de la mémoire contribue à prévenir de rares cas limites.

Les compromis à connaître

Le nouveau système n’est pas parfait. Le transfert des tampons vers la mémoire vive du système introduit une latence ; vous pourriez donc constater une légère baisse de performances lorsque la mémoire vidéo est épuisée. Le noyau doit également décider quels tampons dégrader, et il ne fait pas toujours le bon choix. Dans certains cas, vous devrez peut-être encore ajuster les paramètres de l’application pour éviter d’atteindre les limites de la mémoire vidéo dès le départ.

Linux 7.3 n'est qu'une première étape. Les futurs noyaux affineront probablement les politiques d'éviction et amélioreront la coordination entre les pilotes GPU et le...