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.
Commentaires (51)
#1
Fallait faire ca quand on pouvait encore acheter des cartes graphiques, gros malins !
#2
Très bonne nouvelle !
#3
Pour moi qui fait du jeux sous Linux, c’est une excellente nouvelle !
#4
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.
#4.1
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.
#4.3
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.
#4.4
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.
#4.5
Je partage cette analyse
#4.2
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.
#5
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.
#6
Je pense que non puisqu’il reste du code fermé. Voir mon commentaire précédent.
#7
C’est vrai que sans les lib OpenGL, Mesa, Vulkan, OpenCL, Cuda et aute adaptés le module sert presque à rien.
#7.1
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.
#8
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.
#8.1
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.
#9
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.
#10
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
#10.1
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.
#11
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,…
#12
[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.
#13
Nvidia qui eux étaient pro propriétaire durant des années contrairement à AMD, c’est un sacré changement, à voir pour la suite.
#14
Ç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).
#15
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.
#16
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…
#17
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
#18
Le PDG de Nvidia aurait déclaré lors d’une interview “Fuck you Linus Torvald” avec le majeur levé en l’air
#19
Ou l’ultimatum suite au hack de LAPSUS$
#19.1
Je me suis dis la même chose, mais le timing est pas bon.
#20
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…
#20.1
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é”.
#20.2
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.
#20.3
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)
#20.4
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.
#21
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.
#21.1
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)
#22
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.
#23
bordel de…..
bientot la meme chose pour broadcom/linux/bsd?
#24
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..
#25
les BSD et autres unix-likes libres sont ils aussi concernés?
#26
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.
#27
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…
#28
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.
#28.1
Y’a des linuxiens qui ont besoin de Cuda
#28.2
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
#28.3
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.
#29
Ça fonctionne à merveille. Je ne comprend pas ce que tu y vois de masochiste.
#29.1
Oui sur des stations de travaille avec des distributions stable (redhat, debian).
#30
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 😁
#31
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 !
#32
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
#33
je pense qu’il peut être fortement intéressant et important pour la rédaction de rajouter ces éléments (linuxfr):