Sur Linux, le module kernel du pilote NVIDIA est désormais open source !
Le 12 mai 2022 à 08h19
2 min
Logiciel
Logiciel
Voilà une nouvelle que plus personne n’attendait après de nombreuses années à l’espérer : NVIDIA a annoncé hier soir que la partie noyau de son pilote était désormais open source, sous une double licence GPL et MIT.
Le code source est disponible sur GitHub, avec la version 515.43 du pilote. Comme indiqué par NVIDIA, il n’attend plus que les modifications et pull requests des développeurs (plusieurs dizaines ont déjà été faites). Pour chaque version publiée, le constructeur publiera des moutures entièrement compilées et packagées.
NVIDIA se garde sous la main la partie espace utilisateur – la deuxième moitié du pilote – en sources fermées, mais c’est bien la plus importante des deux qui vient d’être libérée.
NVIDIA indique qu’il s’agit du résultat d’un travail de longue haleine, réalisé en partenariat avec Canonical, Red Hat et SUSE pour tout ce qui touche au packaging, au déploiement et à la manière dont le changement allait influer sur le support. Tous trois s’en félicitent bien sûr.
C’est probablement le support d’ailleurs qui en sera le plus vite affecté. Car la version open source sera envoyée sur les premières distributions dans les jours qui viennent, notamment Ubuntu 22.04. Les systèmes pourront intégrer beaucoup plus finement les fonctions et en surveiller l’utilisation. La découverte et la résolution de problèmes devraient être largement facilitées.
Pour les équipes derrière les distributions, l’ouverture du code signifie également l’exploitation de toutes les capacités offertes par les GPU des architectures Turing et Ampere, seules celles-ci étant supportées pour l’instant. Les systèmes pourront donc travailler leur support du G-Sync ou des écrans multiples sans avoir à passer par du code fermé.
La maintenance devrait en être nettement simplifiée. On a pu voir par exemple l’arrivée de Pop!_OS 22.04 avec une image ISO spécifique pour les possesseurs de cartes NVIDIA, ou encore la possibilité pour Fedora 36 d’ouvrir des sessions Wayland avec le pilote propriétaire. L’arrivée du module noyau open source devrait mettre fin à ces travaux spécifiques.
Le 12 mai 2022 à 08h19
Commentaires (51)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 12/05/2022 à 08h22
Fallait faire ca quand on pouvait encore acheter des cartes graphiques, gros malins !
Le 12/05/2022 à 08h25
Très bonne nouvelle !
Le 12/05/2022 à 08h32
Pour moi qui fait du jeux sous Linux, c’est une excellente nouvelle !
Le 12/05/2022 à 08h34
NVIDIA se garde sous la main la partie espace utilisateur – la deuxième moitié du pilote – en sources fermées, mais c’est bien la plus importante des deux qui vient d’être libérée.
Même en regardant le communiqué, je ne vois pas ce qui permet d’affirmer que c’est la plus importante des 2 qui vient d’être libérée.
S’il reste la moitié du code en code fermé, j’ai de gros doutes.
Le 12/05/2022 à 08h36
Ben c’est la partie qui a accès au kernel, donc je dirais que c’est la partie la plus critique pour bien s’intégrer au système avec les bugs etc.
Le 12/05/2022 à 08h48
Oui, mais est-ce que ça en fait la partie la plus importante ?
La plus critique du point de vue du noyau, oui.
Partie de réponse commune aux 2:
Je pense que le savoir faire de NVIDIA est dans la partie de code fermée, la partie module kernel n’est qu’une interface sans grand intérêt qui permet à la partie code fermée de communiquer avec le matériel. Ils ont probablement aussi libéré du code qui a peu de valeur et qui devait aussi exister dans les drivers libres.
Et comme une version du module kernel doit fonctionner avec une version compatible du logiciel en user mode, on reste verrouillé à ce code propriétaire.
Les seules choses facilitées seront le packaging dans les différentes distributions qui devient à la charge des mainteneurs des distributions et le debug de cette seule partie libre.
Le libre n’a rien gagné à mon avis.
Le 12/05/2022 à 19h31
NV a probablement migré le code sensible (les secrets industriels) en partie dans le firmware, pas seulement dans le userland.
La bonne nouvelle à mon sens, c’est aussi pour que nous puissions faire confiance au kernel.
Le 17/05/2022 à 16h10
Je partage cette analyse
Le 12/05/2022 à 08h36
L’un dépend de l’autre mais l’autre n’a pas besoin de l’un.
La partie noyau est la plus proche du matériel des 2. C’est donc elle la plus critique.
Le 12/05/2022 à 08h43
C’est surtout pour Nouveau que ça va représenter une bonne nouvelle : plus besoin de recréer du code par rétro-ingénierie, tout le nécessaire sera désormais en accès libre sous licences GPL et MIT. Ça va forcément améliorer les choses, pour eux.
Le 12/05/2022 à 08h49
Je pense que non puisqu’il reste du code fermé. Voir mon commentaire précédent.
Le 12/05/2022 à 08h59
C’est vrai que sans les lib OpenGL, Mesa, Vulkan, OpenCL, Cuda et aute adaptés le module sert presque à rien.
Le 12/05/2022 à 12h46
C’est un bon move mais il faudrait CUDA également effectivement. Si AMD arrive à se mettre à niveau sur ROCm (mais la route est longue), ça les fera peut-être bouger.
Le 12/05/2022 à 09h08
Pour les utilisateurs non technicien ça va probablement largement améliorer l’expérience d’utilisation aussi.
Avec le module kernel propriétaire chaque maj kernel pouvait potentiellement casser l’affichage et nécessiter des manipulation peu accessible au non initié qui se retrouve avec un système qui ne démarrait plus.
Si ce problème est réglé au pire ils arriveront sur un bureau avec une accélération 2D/3D non fonctionnel mais un accès au GUI, à Internet et probablement beaucoup plus de chance de s’en sortir.
Le 12/05/2022 à 09h27
Tu as raison, ça va aider aussi sur ce point. Mais est-ce que c’est fréquent ?
Je sais que le noyau Linux change a beaucoup moins de tabou qu’un Microsoft pour casser les compatibilités des modules avec le kernel, mais est-ce si fréquent que ça pose un problème sur les drivers proprio Nvidia ?
Plus je regarde leur code, plus je pense que je suis dans le vrai.
Ils ont libéré 2 parties : le code spécifique à Linux et le code commun avec d’autres OS qui permet à la partie non libérée de communiquer avec leur matériel.
Rien de bien folichon.
Le 12/05/2022 à 09h11
Ca reste plutôt positif. Nvidia utilise peut-être de la techno tierce sous NDA et ils ont libéré ce qui pouvait l’être et peut-être que les modules suivront. On verra.
Le 12/05/2022 à 09h13
Il faut plus voir ça comme une avancé sans détailler l’impact. Une fusée, ça avance comme une tortue mais pas à la même vitesse. Il arriveront peut être a faire de même avec le userspace dans quelques années (je n’y crois pas trop). Avant tout était fermé, maintenant il y a une petite portion d’ouverte.
Ils ont fait un blog pour l’expliquer chez Gnome
Le 12/05/2022 à 09h40
Merci pour le lien. C’est quelqu’un de RedHat qui a fait ce papier.
Il est plus complet que moi (forcément), mais il confirme ce que j’exprimais.
Le 12/05/2022 à 09h26
Faut encore garder le champagne au frigo pour les utilisateurs lambda, c’est pour l’instant priorité aux GPU dédiés aux serveurs avec déclinaison dans le temps aux GPU desktop (GeForce).
Grosses avancées tout de même, support des nouveaux chipsets dès leur sortie, la signature des pilotes Nvidia dans le kernel.
Je me demande quel événement a poussé le plus pour ce changement de politique. La montée en puissance des GPU AMD avec des pilotes open source depuis des lustres (dans les Xbox, Steam Deck) , la fuite de données Nvidia il y a quelques mois dont les pilotes,…
Le 12/05/2022 à 09h32
[mode troll]
Ceci est une révolution !
[/mode]
On attend la réaction de notre trolleur en chef
Sinon, j’ai lu par ailleurs que c’était probablement en réaction à la montée en puissance d’AMD sur le segment GPGPU, avec des MI250 qui ont l’air juste incroyables. Pour rappel, les pilotes AMD sont libérés depuis 7 ans.
Le 12/05/2022 à 09h57
Nvidia qui eux étaient pro propriétaire durant des années contrairement à AMD, c’est un sacré changement, à voir pour la suite.
Le 12/05/2022 à 09h58
Ça fait un moment que je n’ai plus de Nvidia sur mes machines desktop mais d’expérience il y a une dizaine d’année avec une distribution assez réputé (OpenSuse) ça pouvait arriver une ou deux fois par an sur les mises à jour majeur (qui passait sur une nouvelle version du kernel généralement).
En anticipant c’était théoriquement évitable, bloquer la montée en version kernel (qui propose plusieurs majeur par an même si elle ne sont pas toutes adoptées par les distribution) tant qu’une version compatible du driver proprio n’as pas été installé (et n’a pas mis en place le module nécessaire)… Mais ajouté au problématique de distribution, d’acceptation de licence et la latence de Nvidia à mettre a disposition des drivers à jour ça posait beaucoup de problème en pratique.
Puis plus généralement quand tu as du matériel récent (nouvelle config…) et qu’un de tes périphériques (wifi, cpu….) nécessite un kernel à jour ou que tu souhaites utiliser une rolling release il y a de forte chance que tu te retrouves coincé avec une Nvidia à attendre une mise à jour du drivers (bien que à ce niveau ils soient déjà devenu plus réactif ces dernières année j’ai l’impression).
Le 12/05/2022 à 10h14
Bah c’est celle qui permet de piloter le hardware.
La partie user (UMD) s’occupe de fournir les API “standard” (= OpenGL/Vulkan).
Certes, le code fermé de NVIDIA doit contenir des astuces secrètes permettant d’optimiser le pipeline graphique pour leur propre hardware. Mais on peut très bien s’en passer, voire faire du reverse-eng dans des cas où le gain de perf est notable.
C’est un peu comme sous windows avec les pilotes audio/video spécifiques et ceux génériques.
D’ailleurs, sous windows, j’utilise plus volontiers les pilotes audio génériques que les merdouilles spécifiques de realtek.
Le 12/05/2022 à 10h17
Tiens c’est marrant… On sent la décision murement réfléchie et pas du tout influencée par des détails tels que…
Pour les utilisateurs finaux ça change rien pour l’instant de ce que je comprends. C’est un (petit) pas dans la bonne direction.
Maintenant, vu que le marché des cartes graphiques reste outrageusement stupide en termes de dispo et tarifs, a) en l’état ça nous fait une belle jambe b) d’ici à ce que l’offre redevienne raisonnable ils auront largement eu le temps de tout libérer…
Le 12/05/2022 à 10h59
N’est-ce pas plutôt l’arrivée des GPU d’Intel qui a pu motiver ce mouvement ? Il me semble qu’Intel fournit plus facilement des drivers open source et est assez présent au niveau des contributions au kernel linux
Le 12/05/2022 à 12h49
Le PDG de Nvidia aurait déclaré lors d’une interview “Fuck you Linus Torvald” avec le majeur levé en l’air
Le 12/05/2022 à 12h57
Ou l’ultimatum suite au hack de LAPSUS$
Le 12/05/2022 à 16h03
Je me suis dis la même chose, mais le timing est pas bon.
Le 12/05/2022 à 13h54
C’est la vie, mais le type qui a courageusement développé Nouveau (le driver Nvidia libre) par reverse-engineering va voir une décennie de son travail passer à la trappe et son driver retiré du kernel pour faire place à celui de Nvidia…
Le 12/05/2022 à 14h04
Bah, il pourra contribuer au github de celui de nvidia. Et puis, d’après la FAQ il avait d’autres motivations que “j’aime pas le code fermé”.
Le 12/05/2022 à 14h07
Il vas rester toute la partie userland (opengl, vulkan, …) à nouveau.
C’est surtout à voir si nouveaux reste sur sont architecture ou passe par les drivers de nvidia.
Le 12/05/2022 à 14h15
il peut peut-être le voir autrement, et enfin être débarrassé du calvaire de faire de la rétro-ingénierie pour supporter chaque nouvelle puce (ce qui pourrait être “beau”, c’est qu’il se fasse embaucher par nvidia pour s’occuper de ce nouveau module)
Le 12/05/2022 à 14h37
C’est le truc que j’ai pensé aussi.
Ça reste que la partie noyau, mais pour l’utilisateur final, ça ne va rien révolutionner. J’ai l’impression qu”on était tellement habitué à ce que nVidia ignore le monde libre et surtout ses règles qu’on va considérer la moindre ouverture de code comme étant une énorme contribution. Alors qu’on est encore loin de ce qu’a fait Intel et surtout par la suite, niveau sensation, AMD.
Le 12/05/2022 à 15h06
Précisément, tous les pilotes graphiques Intel sont libres sauf pour l’architecture PowerVX rachetée à Imagination Technologies et publiée aux alentours de 2010.
Je n’ai pas oublié car j’avais à l’époque un petit netbook sous Linux qui embarquait l’infâme Poulsbo de cette gamme (nom de code du GMA 500) dont le pilote proprio d’Intel était catastrophique.
Le 12/05/2022 à 17h24
ah tiens, toi aussi t’as un eeepc avec la CG la moins supportée sous linux au monde? seule la version de l’année de sortie de l’ordi la supporte (pour ma part, deux releases ubuntu prennent en charge le power vx avec la 3d, pour les autres c’est l’insupportable mesa)
Le 12/05/2022 à 17h09
Non, c’était pour plaisanter.
Ca a surement davantage a voir avec les limitations des modules propriétaires dans le kernel, a savoir l’impossibilité d’accéder à des symboles exportés via “EXPORT_SYMBOL_GPL”. Et également le fait que ca doit être un peu chiant pour nvidia de devoir compiler un module kernel a chaque chgt dans les ABI.
Je crois comprendre que nvidia a transféré le code “sensible” du module kernel vers le firmware et/ou le module user. Le module kernel n’a donc plus de raison de rester proprio d’un point de vue business. C’est devenu un passe-plat entre deux trucs proprio de nvidia.
Le 12/05/2022 à 17h22
bordel de…..
bientot la meme chose pour broadcom/linux/bsd?
Le 12/05/2022 à 17h23
nvidia prend conscience que son partenaire AMD lui met un coup de froid concurrentiel, que d’autres fabricants de puces arrivent sur ses plates bandes, et que l’arm risque de lui congeler les parties..
Le 12/05/2022 à 17h32
les BSD et autres unix-likes libres sont ils aussi concernés?
Le 12/05/2022 à 17h43
Il semblerait que Nouveau sera adapté pour utiliser le driver kernel de NVIDIA, étant donné que Linux oblige la partie userspace du driver à être open source pour permettre l’intégration dans la branche principale, et que NVIDIA ne prévoit pas de libérer la partie userspace du driver propriétaire.
Donc le driver kernel de Nouveau partira a la poubelle, mais son code en espace utilisateur devrait devenir plus pertinent et utilisé que jamais auparavant, sauf si NVIDIA change encore d’avis et publie aussi le code de la partie en espace utilisateur.
Pour l’instant, ça ne concerne que le driver Linux malheureusement.
Le 12/05/2022 à 21h28
Enfin !
Pourvu que cela puisse se poursuivre avec l’ensemble des constructeurs dans tous les domaines !
Les pilotes au code privateur sont pour bonne partie responsables du maintien des parts de marché des systèmes d’exploitation privateurs.
Tous ceux qui souffrent/ont souffert avec Nouveau doivent se regarder et échanger un sourire sans avoir besoin de parler pour se comprendre…
Le 13/05/2022 à 06h43
Y’a des linuxien avec une carte NVidia ? faut être masochiste :)
En AMD tout marche parfaitement en open source depuis des années, le pilote propriétaire (fglrx) a été abandonné depuis des années : Il n’était pas plus performant, mais beaucoup moins stable.
Le 13/05/2022 à 07h39
Y’a des linuxiens qui ont besoin de Cuda
Le 13/05/2022 à 19h46
Clair. AMD est une catastrophe sur les calculs accélérés GPU :
https://linuxfr.org/news/opencl-sous-linux-l-etat-des-pilotes-amd-est-desormais-pire-que-ce-qu-il-etait-a-l-epoque-de-fglrx
Le 14/05/2022 à 12h16
A part ma 1er carte une ATI, je n’ai eut que des nvidia sous linux et je n’ai jamais rencontré de problème avec les drivers proprio. et désolé mais les drivers pour amd même s’ilss ont fait beaucoup de progrès depuis des années sont loin de couvrir tous les besoins.
Les problèmes qui sont cités la plupart du temps, ce sont des gens avec Nouveau qui est mis par défaut sur toute les distributions. Attention, je ne crache pas sur le boulot fait par l’équipe de Nouveau.
Mais quoi de plus frustrant pour plein de gens qu’après leur installation toute fraiche de ce retrouver avec avec un écran noir. Combien de fois, j’ai du expliquer a des débutant ou même à des confirmés pas habitué comment blacklister Nouveau dans le grub, d’installer les drivers nvidia et de passer sous xorg au lieu de wayland.
Le 13/05/2022 à 08h17
Ça fonctionne à merveille. Je ne comprend pas ce que tu y vois de masochiste.
Le 13/05/2022 à 09h51
Oui sur des stations de travaille avec des distributions stable (redhat, debian).
Le 13/05/2022 à 17h24
C’est madame Michu qui va être contente de plonger dans des centaines de millers de lignes de code pour accélérer l’affichage de ses jeux d’arcade 😁
Le 13/05/2022 à 21h37
Pour le coup c’était un netbook samsung mais la conséquence était la même…
Des heures et des heures sur les forums Ubuntu pour obtenir un truc potable !
Le 16/05/2022 à 06h48
C’est exactement ce genre de pb qui n’existe plus avec AMD, tout marche, et si tu recompiles un jour ton noyau, ça compile en même temps le pilote graphique ; ce qui est quand même bien plus simple que se retrouver avec un écran noir / comprendre ce qui se passe / faire un retour arrière / farfouiller le net en espérant que quelqu’un à une version compatible avec ton noyau et recommencer.
Edit: sauf peut-être CUDA ou OpenCL effectivement, mais c’est loin d’être l’usage commun
Le 18/05/2022 à 09h43
je pense qu’il peut être fortement intéressant et important pour la rédaction de rajouter ces éléments (linuxfr):