Nouvelle version pour le noyau Linux, avec une liste particulièrement importante d’améliorations sur le plan matériel. C’est notamment vrai pour la prise en charge des processeurs Intel et AMD en général, entre optimisations pour des fonctions existantes (codes CRC pour les puces supportant AVX-512) et support de technologies sur les dernières générations.
C’est le cas pour l’architecture Zen 5 d’AMD qui continue de recevoir de l’attention. Les évènements de performances prennent ainsi en charge le filtrage de la latence de charge et des calculs AES-CTR plus rapides. Le support de l’architecture RISC-V continue de grandir avec la prise en charge de BFloat16 et de plusieurs autres instructions.
On note également des améliorations significatives sur le code lié à Intel TDX, le support du SoC Versal NET d’AMD, une meilleure prise en charge de divers autres SoC (Arm Morello, Apple T2, MNT Reform 2…), divers progrès dans le pilote AMD P-State, les premières briques pour le support d’Intel APX, ou encore le support des Raptor Lake S d’Intel dans le pilote EDAC.
Du neuf sur le terrain des GPU, avec l’apparition des premiers éléments pour le successeur de Nouveau, le pilote open source pour les puces NVIDIA. Le nouveau venu, baptisé Nova, est écrit en Rust et s’appuie sur le GSP (GPU System Processor) de NVIDIA. Il ne s’agit que d’une base élémentaire, non exploitable par les utilisateurs, mais sur laquelle l’équipe s’appuiera pour progresser.
Côté GPU, tout le monde ou presque reçoit des améliorations. On en note plusieurs pour les puces Intel Xe, dont le support de la Shared Virtual Memory et de la température de la VRAM via le pilote. On remarque aussi le support de la vitesse des ventilateurs pour les Radeon RX 9070, dont l’information peut être donnée désormais par le pilote. Pour l’ensemble des GPU, le noyau 6.15 introduit en outre une méthode standardisée pour faire remonter des messages en espace utilisateur quand un GPU ne répond pas, même temporairement.
Parmi les autres améliorations, signalons une suppression beaucoup plus rapide des fichiers pour exFAT, le support des noms de plus de 1 024 caractères pour le système de fichiers FUSE, la prise en charge du paramètre zero-copy pour la réception des données réseau pour le sous-système io_uring, la suppression du support des systèmes 32 bits possédant plus de 8 CPU et/ou plus de 4 Go de mémoire, ou encore le support de la Touch Bar des Mac (qui n’est plus proposée par Apple depuis des années).
Si l'anglais ne vous fait pas peur, Phoronix a fait un gros récapitulatif des nouveautés de cette version 6.15. Comme toujours, la disponibilité du noyau dépend du système utilisé.
Commentaires (13)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousModifié le 26/05/2025 à 10h59
Côté bureau, on observe une fluidité accrue.
Côté jeux vidéo, j'ai perdu 5% sur le dernier Tomb Raider (version native) bien qu'il y ait une douzaine de commits pour ma CG (rx9070xt)
Le 26/05/2025 à 12h09
Qui plus est, on parle déjà d'un remplacement de nouveau par un driver qui a à peine le début du commencement de fait, n'est-ce pas un peu précipité ?
Enfin, je suis très surpris de l'acceptation de ce driver au sein du noyau. Vu la complexité des GPUs, est-ce véritablement une bonne idée de le faire en Rust, alors même que son avenir au sein du noyau linux est toujours incertain ?
Le 26/05/2025 à 13h57
Le faire en Rust n'est pas forcément déconnant. Image d'un langage moderne, à la mode, pas de GPL, moins cher qu'un dev C compétent, et cohérent pour l'aspect memory safety.
Le but de GSP sur lequel s'appuie Nova est déléguer la partie gestion du GPU non plus au CPU mais directement au GPU. Ainsi, Nvidia garde ses blobs dans son firmware (même plus besoin de charger un blob binaire dans le noyau), rend tout ceci opaque, ne communique rien (merci Rust qui "annule" la licence GPL) et ne fournit que le strict nécessaire en Rust pour que le kernel Linux puisse utiliser le GPU.
L’intérêt de Rust pour les GAFAM et autres, c'est 1. se débarrasser de la contaminante GPL 2. Avoir une main d’œuvre moins cher 3. Récupérer le travail du monde l'open-source sans rien devoir en retour (compatible avec la logique néo-féodal qu'on voit apparaître au US).
Le 26/05/2025 à 14h08
1) le côté moderne du langage, on s'en fiche pour le noyau Linux. Sinon, cela ferait belle lurette qu'il y aurait du Python dedans !
2) pas de GPL : j'avoue ne pas avoir compris les différents passages sur la GPL. Je ne comprends pas le côté "annulation". Peux-tu expliquer un peu plus ?
3) Moins cher qu'un dev C, je ne suis pas certains... Surtout que là, on parle quand même de GPU au sein du noyau Linux, donc ce n'est clairement pas le dev débutant (que ce soit en C ou en Rust) qui peut le faire
4) Cohérent pour l'aspect memory safety avec un langage qui pose justement des problèmes d'intégration vis-à-vis de son intégration dans le noyau à cause de son paradigme différent ? Rajouter des problèmes de "compatibilité", je ne suis pas vraiment sûr que cela soit plus sûr.
Donc nova est supporté par nvidia si je comprends bien ? (vrai question, je n'ai pas du tout suivi le développement de de driver)
Le 26/05/2025 à 14h54
2) En gros (je suis pas dans le droit) : Si tu utilises un code GPL, tu donnes devient GPL. Comme Nvidia utilise le noyau Linux et ses interfaces, en un sens il se doit de rendre compte GPL (et donc open-source) ; en pratique ce n'est pas aussi exact car des modifications ont été apporté afin de pouvoir introduire des blobs. Avec Rust, l'interface n'est plus GPL et de fait tu tranquilles "pomper" le travail des autres du noyau Linux sans rien fournir en retour.
3) Un dev Rust sera à terme moins chère qu'un dev C en raison de l'offre-demande mais aussi que coder en Rust demandera moins d'expérience/compétence qu'en C et que les offres low-cost suivront. Comme Rust n'a pas d'UB ni de problèmes avec la mémoire, tu pourras trouver des dev bas de gamme qui seront un faire un truc qui plante pas au premier pointeur. ça n’empêchera pas les problèmes de logiques, mais ça permettra d'avoir "des codes Indiens" qui marchent.
En outre, dans le cas qui nous interesse la programmation de NOVA en Rust est actuellement la partie la plus technique. A terme, il suffira de juste d'utiliser NOVA pour communiquer avec le GPU et ça sera bon puisque le GSP sera en charge de faire fonctionner le GPU et non plus le CPU comme avant. Et cette partie sera nettement moins technique, surtout si Nvidia fournit une doc.
NOVA est relativement simple par rapport à un scheduler ou la pagination mémoire.
4) Je suis d'accord avec toi que Rust ne devrait pas aller dans le kernel Linux. Seulement voilà, il n'est pas prêt de sortir du kernel sauf "gros scandales". Pour le moment Linus tient bon la barre.
Le problème de l'intégration, c'est surtout que Rust doit comprendre qu'intégrer le noyau Linux s'est accepter de faire "comme en C" et pas comme en Rust (je mets de coté les problèmes humains). Mais je ne pense que c'est problème d'intégration puisse représenter des problèmes de sécurité. En revanche, Rust peut prémunir de certains erreurs mémoires et autres qui peuvent faire planter le driver. (Prends en de la graine W11 !! ).
Point important car j'associe NOVA à Nvidia trop fortement:
NOVA est fait par RedHat mais Nvidia y contribue aussi indirectement pour le moment en sortant les firmwares GSP pour ces différents GPU. Le fait que j'utilise NOVA avec Nvidia de manière si entrelacé, c'est qu'il est pensé à la base pour les GPUs Nvidia uniquement, afin de remplacer Nouveau. Mais à la différence de nouveau lors de sa sortie, Nvidia m'a semblé enthousiaste avec NOVA. Pour une raison simple, si NOVA réussit Nvidia pourra tranquillement profiter du travail de RedHat, et à terme fournir uniquement de quoi communiquer avec GPU pour faire fonctionner le GSP, sur les distros sans se fouler. Néanmoins NOVA ne peut pas réussir sans l'appui, à minima indirect de Nvidia.
Le 26/05/2025 à 16h57
Par contre, pour le 2, je ne comprends toujours pas. Rust ne va pas magiquement faire sauter la "viralité" de la GPL. D'autant plus que je ne vois pas comment l'interface Rust puisse ne pas être en GPL dans un projet sous GPL. C'est une violation de la GPL.
Pour le 1, pour des projets important et à la vie longue, le point crucial est de garder une certaine homogénéité dans le code. Cela ouvre deux choix :
- soit on est très conservateur sur les conventions, au risque de paraitre un peu désuet
- soit on met à jour les conventions, mais dans ce cas, il faut aussi maintenir à jour la base de code et les outils tout autour.
Linux, par sa taille (plusieurs dizaine de millions de lignes de code) et tous les outils développés spécifiquement autour est sans doute plus dans la 2e catégorie que de la première. Donc une mise à jour des conventions doit être murement réfléchis avant d'être acté.
Le 26/05/2025 à 17h44
Pour le point 1. On est d'accord sur le principe. Mais l'ajout de Rust, même limité n'est pas anodin au contraire d'un peu lifting du C, qui sont plus une question de style de code. Et en plus le noyau a déjà subit ce genre d'évolution. Linus avait ses raisons pour sur. Mais vu les difficultés posées par Rust, tant sur le plan technique, qu'humain on peut légitimement s'interroger sur ce choix.
Modifié le 26/05/2025 à 15h07
Par ailleurs, le côté moderne de Rust compte (garanties pour la mémoire et le multithread) et a une grande valeur pour le Kernel. Aucun autre langage jusqu'ici avait les propriétés appropriées pour le Kernel. Par ex. Python est beaucoup trop lent, a un collecteur mémoire, et est interprété, ce n'est pas un langage système comme Rust ou le C.
Rust est là pour rester dans le noyau. Même si quelques dev historiques râlent, Linus s'est exprimé assez clairement sur le sujet.
Le 26/05/2025 à 17h03
Et aujourd'hui, le Rust est effectivement le seul à avoir cela.
Personnellement, je pense qu'inclure Rust dans un projet de plusieurs dizaines de millions de lignes de code et de plus de 30 ans d'âge, c'est une erreur. Mais :
1) ce n'est qu'un avis personnel
2) je ne suis ni mainteneur ni contributeur du noyau, donc mon avis, on s'en fout royalement ^^
Oui, enfin si j'ai bien suivi, Rust n'est autorisé que dans les drivers. Ce n'est pas demain qu'on va le voir dans le coeur même du noyau.
Modifié le 26/05/2025 à 20h38
Quand on voit les dev de code Rust sur le noyau, c'est pour beaucoup une nouvelle génération qui débarque et apporte un vent frais, sans lequel le projet pourrait pourrir et mourir.
Ils devraient également se débarrasser de leur système de mailing list et quelques autres outils, même si ça correspond bien à leurs besoins, c'est simplement obsolète aujourd'hui et c'est hautement rébarbatif pour les nouveaux (disclaimer: mon avis ne vaut pas grand chose non plus, je ne suis pas dev kernel).
S'ils ont la motivation et l'énergie pour écrire Git, ils peuvent écrire ou adapter un système de revue de code et de gestion de projet moderne et correspondant à leurs besoins.
Le 26/05/2025 à 21h00
J'avais trouvé il y a de nombreuses années (15 ou 20 ans peut être ?) un tuto pour faire un driver + le processus de communication. C'était très lourd à mettre en place et qui me semblait complètement anachronique. Alors aujourd'hui...
Modifié le 26/05/2025 à 17h57
Si tu peux éclairer sur ce point ?
Le 26/05/2025 à 12h45
Source : Blog Asahi - "progress report" de la mi-mai