NVIDIA commence à faire évoluer le support Linux en annonçant un changement technique essentiel pour ses futures GPU, nommé Nova, le nouveau pilote graphique du noyau écrit en Rust. Ce pilote, développé en open source et dans une optique upstream, introduit dans une série de correctifs une étape capitale: la transition de l’ancien NV_PMC_BOOT_0 vers le nouveau NV_PMC_BOOT_42, qui servira de référence pour identifier la génération et la révision des prochains chips. Concrètement, les générations à venir cesseront d’utiliser l’ancien BOOT_0 et utiliseront BOOT_42 comme source d’informations fiable pour leur démarrage.

La série de correctifs — signée par John Hubbard — dépasse la simple curiosité technique. Elle constitue, selon les propres mots de l’ingénieur, une adaptation nécessaire pour que Nova puisse “reconnaître” de manière stable les architectures Turing et ultérieures, tout en étant prête pour les GPU issus de la génération Blackwell, supposée sous le nom de code Rubin. Sur le plan pratique, ce changement modifie la logique de sélection du pilote et documente l’évolution, étape par étape, des registres de démarrage de la gamme GPU de NVIDIA, précisant comment le code doit se comporter selon l’ère architecturale concernée.

Qu’est-ce que Nova exactement et pourquoi est-ce important ?

Nova représente la tentative de NVIDIA de faire un bond générationnel dans sa présence open source sur Linux. Il s’agit d’un pilote du noyau écrit en Rust, pensé pour les GPU avec GSP (GPU System Processor) et appelé à devenir le successeur de Nouveau dans la branche principale du noyau pour les générations modernes (à partir de Turing/RTX 20), couvrant Ampere, Ada et Blackwell. Sa stratégie technique combine deux objectifs : sûreté et robustesse (grâce aux garanties de Rust en matière de mémoire et de concurrence) et alignement avec la feuille de route de NVIDIA, qui depuis Turing exige la présence du firmware GSP pour certaines fonctionnalités basses niveau.

Bien que toujours en développement, Nova symbolise une expérience inédite de NVIDIA, visant à développer en vue de la communauté des éléments clés du support Linux, via la publication de correctifs dans le prochain et lointain futur, en intégrant des retours upstream. Dans ce contexte, l’adoption de BOOT42 apparaît comme une étape essentielle pour que le pilote reconnaisse et configure adéquatement les GPU produits après Blackwell.

De BOOT0 à BOOT42: une clé pour la nouvelle ère

Jusqu’à présent, le registre NV_PMC_BOOT_0 indiquait la architecture et la révision du GPU. Nova — comme tout logiciel devant identifier le silicium devant lui — consultait cette valeur pour déterminer les routes d’initialisation et les tables spécifiques à chaque famille (de NV04 à Turing/Ampere/Ada/Blackwell). Le correctif publié par NVIDIA prévoit que, pour les chips futurs, ces informations ne soient plus stockées dans BOOT_0; à la place, elles seront dans NV_PMC_BOOT_42, et BOOT_0 sera mis à zéro.

Ce changement va au-delà d’une simple substitution d’adresses : il oblige à simplifier et aérer la logique de détection pour qu’elle fonctionne de Turing et au-delà sans recourir à des ifs fragiles. Le diff associé supprime notamment des types comme Spec et Revision et réduit d’environ 33 lignes la logique du module de détection, renforçant la clarté et la maintenabilité. La note de présentation de la série insiste sur le fait que cette stratégie permettra à Nova « de reconnaître Turing et ultérieures de façon fiable pour un bon moment », sans modifications supplémentaires dans cette partie.

Contexte industriel : une arrivée en temps utile au noyau

Ces dernières années, le support graphique Linux de NVIDIA a évolué sur deux plans : d’un côté, le pilote propriétaire (binaires) diffusé pour ses gammes GeForce/Quadro/Data Center ; de l’autre, l’écosystème ouvert (Nouveau), historiquement freiné par le manque de documentation et la dépendance au firmware. Nova cherche à combler cette lacune pour les GPU modernes, en utilisant Rust, GSP et une meilleure collaborative upstream, rapprochant la logique du kernel et ce que les distributions commerciales proposent à leurs utilisateurs.

Le fait que les premiers correctifs “post-Blackwell” apparaissent si vite est significatif. Cela indique premièrement que les équipes Linux de NVIDIA ont une bonne visibilité sur la future architecture, leur permettant de préparer dès aujourd’hui certaines couches fondamentales du pilote. Deuxièmement, cela montre une maturité dans leur processus interne : changer la source d’identification graphique (de BOOT_0 à BOOT_42) implique d’optimiser rapidement le code dépendant pour éviter de subir une “dette technique” au lancement des premiers échantillons de silice.

Ce que peuvent attendre Linux (et ce qu’il ne faut pas encore espérer)

Il est important de distinguer la réalité des attentes. Ces correctifs ne proposent pas encore un support fonctionnel complet pour la gamme Rubin ni n’améliorent immédiatement les performances de vos GPUs actuels. Ils constituent davantage une infrastructure : le terrain préparé pour reconnaître plus efficacement les nouvelles générations dès leur arrivée, en simplifiant la détection d’architectures comme Turing, Ada, Blackwell.

Pour l’utilisateur final, la nouveauté sera limitée dans l’immédiat. Cependant, pour les distributeurs, développeurs et mainteneurs de l’écosystème Linux, c’est une étape importante :

• Les distributions suivant la branche principale pourront intégrer rapidement ces changements, afin de garantir la compatibilité avec Turing/Ampere/Ada/Blackwell.
• Les projets user-space (Mesa, Wayland/GBM, gestionnaires de fenêtres) ont maintenant de meilleures indications pour anticiper les noms ou chemins de détection liés à udev, à l’identification de périphériques, ou à certains “quirks”.
• Les outils de diagnostic et de télémétrie pourront ajouter la détection de BOOT_42 dans leurs rapports, le rendant utile pour les systèmes de nouvelle génération.

Restent toutefois en suspens la grande question du rythme et de l’étendue du support opérationnel de Nova, notamment pour les GPU de nouvelle génération dès leur commercialisation. Si l’histoire du support open NVIDIA a été progressive, souvent prudente sur le 3D ou la gestion d’énergie, l’adoption de Rust et l’approche upstream apportent de meilleurs fondamentaux pour permettre une évolution plus rapide et plus solide, même si ce n’est pas garanti dans l’immédiat.

Et Blackwell… qu’en est-il de Rubin ?

Bien que NVIDIA reste discret sur l’architecture suivant Blackwell, certains regards attentifs et médias spécialisés associent ce “next-gen” à Rubin, le nom de code circulant en interne pour la prochaine génération. La documentation des correctifs mentionne d’ailleurs que jusqu’à Blackwell, on utilisait BOOT_0 pour l’identification, alors qu’après, ce sera BOOT_42 et BOOT_0 sera mis à zéro, signe qu’on passe “au-delà de Blackwell”.

Sur le plan de la compatibilité, Nova vise à faire reconnaître ces GPU à partir de Turing et plus tard, sans toucher aux générations plus anciennes (NV4x, Tesla, Fermi, Kepler, Maxwell, Pascal), où Nouveau continuera d’être pertinent. Quant à la gamme GSP (Turing+) moderne, Nova pourrait devenir, à terme, le pilote principal dans le noyau.

Sécurité, Rust et qualité du code

Ce qui motive la programmation de Nova en Rust n’est pas un choix cosmétique. En contexte de pilotes de kernel, où une erreur comme un dépassement de tampon, une double libération ou une condition de course peut mener à de graves vulnérabilités, les garanties offertes par Rust — propriété de mémoire, prêts, lifetime — permettent de réduire considérablement les surfaces d’attentat. La suppression de types complexes et la simplification apportée par les correctifs, qui allègent la logique de détection, traduisent une volonté de “payer la dette technique” et de préparer un terrain solide pour les évolutions futures, sans dépendances excessives.

Impact sur le développement logiciel et outils

Les applications et toolchains utilisant un accès bas niveau à la GPU — qu’il s’agisse de systèmes de provisioning, de monitoring ou de diagnostic matériel — devront probablement mettre à jour leur logique si elles dépendaient du contenu de NV_PMC_BOOT_0. Dans les environnements professionnels automatisant inventaire et conformité selon la famille de GPU, il sera prudent d’anticiper la prise en charge combinée de BOOT0 et BOOT42, jusqu’à ce que le parc Rubin s’impose définitivement.

Les projets tierces partis prenantes à Nova sont fortement encouragés à suivre attentivement le forum, le dépôt de code et toutes les documentations, car les API internes et les constantes évoluent rapidement pour intégrer ce changement majeur. La transparence du processus facilite la communication et prévient les surprises.

Perspectives futures

Si NVIDIA maintient son rythme, il faut s’attendre à de nouveaux correctifs visant à enrichir tables, routes d’initialisation et gestion de l’énergie, correspondant aux premiers prototypes de la prochaine génération. La documentation relative à BOOT42, et le travail pour Blackwell, continueront également dans les prochains mois, tout comme l’intégration de Nova dans le pilote propriétaire, en fonction des calendriers de commercialisation.

Recommandations pour les utilisateurs et early adopters Linux

• Suis le mainline: si tu aimes tester, compile des kernels récents ou utilise une distribution rolling pour bénéficier rapidement de ces correctifs et vérifier la stabilité sous Turing/Ada/Blackwell.
• Surveille le dmesg: lors de la mise à jour vers une build avec Nova, vérifie les messages liés à la détection et l’initialisation de la GPU; cela te dira si le code “reconnaît” correctement ton périphérique.
• Garde des attentes réalistes: cela ne concerne pas encore les performances ou le 3D avancé. C’est une étape préparatoire pour reconnaître les futures cartes, cela viendra dans de prochaines séries de correctifs.
• Participe: en signalant toute régression ou problème dans l’identification via des outils comme lspci -nn ou dmesg. Ta contribution peut aider à améliorer cette transition.

Questions fréquentes

Qu’est-ce que NV_PMC_BOOT_42 et pourquoi le remplace-t-il ?
Ce registre de démarrage stocke l’architecture et la révision du chip. Historiquement dans BOOT_0, il sera désormais dans BOOT_42 pour les générations post-Blackwell, qui laisseront BOOT_0 à zéro. Nova adapte la lecture pour une détection efficace des nouveaux GPU.

Différences entre Nova et Nouveau en Linux ?
Nouveau est un pilote libre traditionnel pour GPU NVIDIA, supporté depuis longtemps dans le kernel principal, mais limité par l’absence de composants propriétaires. Nova, écrit en Rust, cible spécifiquement les GPU avec GSP, et son développement transparent vise à remplacer progressivement Nouveau pour les architectures modernes.

Est-ce que mes GPU actuels seront plus rapides ou plus compatibles ?
Pas immédiatement. Ces correctifs préparent l’identification et la détection pour la prochaine génération. Les améliorations de performance ou de fonctionnalités arriveront dans des séries ultérieures.

Le nom “Rubin” est-il confirmé ? Et quand sortiront ces GPU ?
Le terme “next-gen GPU” indique des modèles au-delà de Blackwell, souvent associé à “Rubin” par les analystes. NVIDIA n’a pas encore publié d’informations officielles ou de calendrier précis. Pour l’instant, ce sont des signes techniques, pas des annonces commerciales.

Sources: Annonces officielles, patchs des listes de diffusion du noyau (notamment “gpu: nova: add boot42 support for next-gen GPUs” de John Hubbard) et analyses spécialisées sur Phoronix ; documentation Rust-for-Linux concernant Nova.

via : phoronix