Ce changement sous Linux nous permettra de mieux gérer l'utilisation de la RAM par les jeux

La proposition se concrétise sur le parcours /sys/class/drm/card1/memstat/un répertoire conçu pour exposer les régions de mémoire telle que vRAM et GTT avec un format commun. Jusqu'à présent, chaque pilote rapportait ces données à sa manière, avec des lectures cryptées ou des appels propriétaires qui rendaient difficile la comparaison de l'état du GPU entre les fabricants. Le but est que n'importe quelle application puisse lire ces chiffres sans que nous ayons à deviner au préalable quelle carte graphique l'ordinateur a installé.

Le correctif AMDGPU met memstat à l'épreuve

L'exemple de correctif qui accompagne la proposition se concentre sur le pilote AMDGPU et définit une structure commune pour lire l'état de la mémoire. Chaque région identifiée renvoie sa capacité totale et sa consommation en temps réel, en mégaoctetssans avoir à interpréter des fichiers avec des noms non descriptifs ni à croire que le pilote lui-même résoudra la lecture par lui-même.

Jusqu'à présent, savoir quelle quantité de VRAM était réellement utilisée sous Linux dépendait de mécanismes spécifiques au fabricant ou d'astuces mal documentées qui variaient d'une distribution à l'autre. Avec memstatles techniciens disposent d'un numéro clair et comparable entre les cartes, ce qui leur permettra de distinguer si un GPU fonctionne à la limite de sa capacité ou a encore suffisamment de marge pour assumer de nouvelles charges de travail, sans recourir à des outils tiers externes.

Moteurs de surveillance et de rendu sous Linux

La fragmentation actuelle oblige chaque pilote à exposer ses données différemment, ce qui complique le développement de logiciels devant fonctionner avec des GPU de plusieurs constructeurs en même temps. En unifiant la requête sous sysfs, les outils de surveillance et les moteurs de rendu pourront lire l'état de la VRAM sans implémenter de chemins spécifiques pour chaque carte.

Le changement affecte directement les pipelines de rendu VFX et les studios de développement de jeux vidéo, où il est courant de combiner des graphiques de plusieurs fournisseurs au sein d'une même ferme de rendu ou d'un même poste de travail. Les équipes gérant les moteurs graphiques n'auront plus besoin de gérer plusieurs chemins de code pour interroger chaque carte séparément, mais pourront centraliser cette requête dans un seul appel système, ce qui simplifierait la maintenance à long terme du logiciel. L'adoption complète de ce modèle dépendra dans tous les cas du transfert par d'autres fabricants de la même structure sur leurs propres contrôleurs, à la fois libres et propriétaires.

Si vous travaillez avec des stations dédiées à la modélisation 3D ou à la composition d'effets visuels, cette lecture commune vous donnera des données objectives et comparables entre GPU de différents fournisseurs, ce qui facilite la répartition des tâches dans des fermes de rendu ou dans des environnements de développement multiplateformes sans dépendre de la documentation particulière de chaque fabricant. Le interface memstat Cela n'empêchera pas un projet d'échouer en raison d'un manque de mémoire si les actifs dépassent la capacité physique de la carte, mais cela fournira les chiffres exacts de vRAM et de GTT nécessaires pour ajuster la scène avant que le système ne s'effondre, ce qui nécessitait jusqu'à présent de comparer différentes lectures en fonction du fabricant du GPU installé sur chaque poste de travail.