… mais cet article Phoronix est plutôt pas mal, assez détaillé, avec quelques angles non discutés par ailleurs : depuis combien de temps le boulot était en cours mais gardé secret, quelques mots sur le (non) support FreeBSD, etc.
Ce n'est pas le driver complet qui est libéré, mais la partie s’interfaçant avec le noyau.
Il reste encore du chemin avant un driver complètement opensource, mais c'est un grand pas (ne serait ce qu'idéologique).
Avant cette libération nous avons récemment eu droit à un driver Tegra opensource, et le code du driver a déjà fuité cette année. Même si le code ayant fuité n'est pas exploitable en l'état, on pourrait imaginer que les développeurs de nouveau ou d'un autre projet se répartissent la tache en deux équipes. une lisant le code et rédigeant des specs et l'autre implémentant les specifications.
C'est peut être cette fuite qui a forcé la main à Nvidia, mais ce n'est que supputation.
Il me semble aussi avoir vu passer que Nvidia avait libéré des clefs pour ces GPU recents (ne pas avoir ces clefs empeche nouveau d'exploiter correctement les GPU post Fermi si je ne me trompe, en les condamnant à rester à la fréquence idle). Mais je n'arrive pas à retrouver cette info.
Il ne faut sûrement pas s'attendre à un grand changement dans l'immédiat mais la situation de nouveau et des GPU nvidia pourrait bien énormément changer dans le futur !
Hector Martin fait remarquer que leur firmware fait 34MB, ce qui est beaucoup (à pondérer avec le fait qu’un firmware gère plusieurs matériels), avec la supposition qu’il pourrait y avoir un transfert de code vers le firmware. Étant donné qu’Nvidia a fait de sa capacité à segmenter les usages via ses pilotes un argument de vente (par exemple en promettant d’empêcher le minage sur les cartes de jeu en détectant le minage), je ne serai pas surpris qu’un tel déplacement de code stratégique vers le firmware était nécessaire pour rendant le pilote noyau moins critique, et dans cette hypothèse, ça suppose un plan à plus long terme qu’une simple réaction à une fuite.
Par ailleurs je ne pense pas que ce genre de fuite ait ce pouvoir, puisque gérer du code fuité est compliqué (comme tu l’expliques), il n’y a pas besoin de leur favoriser le boulot en mettant sous licence libre, autant les laisser s’emmerder (et puis, qui veut s’interdire à vie de contribuer à nouveau ? pas moi).
Ça fait quelques années que Phoronix nous promet une grosse nouvelle côté Nvidia mais qu’il pouvait pas dire quoi™.
Pour revenir à l’hypothèse du déplacement de code stratégique vers le firmware, il faut bien voire qu’il y a trois niveaux où le code peut contenir de tel “code stratégique”.
Espace utilisateur : bibliothèques spécifiques comme CUDA (marché captif), la plateforme Nvidia : toujours proprio.
Pilote noyau : plus rien de stratégique si déplacé vers le firmware, peut être libéré (et est libéré).
Firmware : toujours plus gros, toujours proprio, toujours signé.
J’ai cru comprendre que seules les cartes actuelles ont de si gros firmwares, bref, que ça a requiert un changement de conception en amont qui ne s’improvise pas et a forcément été pensé il y a déjà longtemps.
Il est donc tout à fait possible d’imaginer qu’ils avaient prévu de repenser leur cartes et leur pilotes et la répartition des fonctionnalités pour permettre de conserver le même contrôle sur la captivité des utilisateurs tout en ayant un pilote libre. En bref ils auraient seulement élargi leur interface entre leur code proprio et Linux.
CUDA est toujours proprio, leur firmware est toujours signé, ils ont seulement agrandi la couche d’interfaçage avec Linux pour simplifier la gestion du code noyau. Ça va clairement simplifier la vie des utilisateurs avec des distributions qui pourront fournir la couche de compatibilité avec le noyau, et même peut-être la possibilité de rétroporter indépendamment les futurs pilotes noyau lorsque les cartes actuelles ne seront plus prises en charge par Nvidia pour toujours bénéficier des nouvelles bibliothèques proprio sans avoir à utiliser de vieux noyaux. Mais concernant l’applicatif, ce sur quoi s’appuient les applications (Vulkan, CUDA, NVENC, NVDEC), tout cela reste proprio.
Nvidia est une plateforme. Un programme qui requiert CUDA ou autre technologie spécifique à Nvidia n’est pas multi-plateforme. Quand un programme requiert CUDA, le choix de Linux ou Windows n’est alors qu’un choix accessoire comme on choisit un bureau GNOME ou KDE, la plateforme c’est Nvidia (Nvidia/NT ou Nvidia/Linux, c’est toujours Nvidia). Nvidia n’a rien changé à cela.
ce commentaire est sous licence cc by 4 et précédentes
# Lien : NVIDIA publie désormais ses pilotes graphiques pour Linux sous licence libre
Posté par Olivier Esver (site web personnel) . Évalué à 2.
https://linuxfr.org/users/jmiven/liens/nvidia-publie-desormais-ses-pilotes-graphiques-pour-linux-sous-licence-libre
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Lien : NVIDIA publie désormais ses pilotes graphiques pour Linux sous licence libre
Posté par Aldebaran (site web personnel) . Évalué à 1.
Mince j'avais pas vu désolé !
# Déjà discuté hier
Posté par Boa Treize (site web personnel) . Évalué à 4.
… mais cet article Phoronix est plutôt pas mal, assez détaillé, avec quelques angles non discutés par ailleurs : depuis combien de temps le boulot était en cours mais gardé secret, quelques mots sur le (non) support FreeBSD, etc.
# En plus long
Posté par Aldebaran (site web personnel) . Évalué à 2.
Ce n'est pas le driver complet qui est libéré, mais la partie s’interfaçant avec le noyau.
Il reste encore du chemin avant un driver complètement opensource, mais c'est un grand pas (ne serait ce qu'idéologique).
Avant cette libération nous avons récemment eu droit à un driver Tegra opensource, et le code du driver a déjà fuité cette année. Même si le code ayant fuité n'est pas exploitable en l'état, on pourrait imaginer que les développeurs de nouveau ou d'un autre projet se répartissent la tache en deux équipes. une lisant le code et rédigeant des specs et l'autre implémentant les specifications.
C'est peut être cette fuite qui a forcé la main à Nvidia, mais ce n'est que supputation.
Il me semble aussi avoir vu passer que Nvidia avait libéré des clefs pour ces GPU recents (ne pas avoir ces clefs empeche nouveau d'exploiter correctement les GPU post Fermi si je ne me trompe, en les condamnant à rester à la fréquence idle). Mais je n'arrive pas à retrouver cette info.
Il ne faut sûrement pas s'attendre à un grand changement dans l'immédiat mais la situation de nouveau et des GPU nvidia pourrait bien énormément changer dans le futur !
[^] # Re: En plus long
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Hector Martin fait remarquer que leur firmware fait 34MB, ce qui est beaucoup (à pondérer avec le fait qu’un firmware gère plusieurs matériels), avec la supposition qu’il pourrait y avoir un transfert de code vers le firmware. Étant donné qu’Nvidia a fait de sa capacité à segmenter les usages via ses pilotes un argument de vente (par exemple en promettant d’empêcher le minage sur les cartes de jeu en détectant le minage), je ne serai pas surpris qu’un tel déplacement de code stratégique vers le firmware était nécessaire pour rendant le pilote noyau moins critique, et dans cette hypothèse, ça suppose un plan à plus long terme qu’une simple réaction à une fuite.
Par ailleurs je ne pense pas que ce genre de fuite ait ce pouvoir, puisque gérer du code fuité est compliqué (comme tu l’expliques), il n’y a pas besoin de leur favoriser le boulot en mettant sous licence libre, autant les laisser s’emmerder (et puis, qui veut s’interdire à vie de contribuer à nouveau ? pas moi).
Ça fait quelques années que Phoronix nous promet une grosse nouvelle côté Nvidia mais qu’il pouvait pas dire quoi™.
Pour revenir à l’hypothèse du déplacement de code stratégique vers le firmware, il faut bien voire qu’il y a trois niveaux où le code peut contenir de tel “code stratégique”.
J’ai cru comprendre que seules les cartes actuelles ont de si gros firmwares, bref, que ça a requiert un changement de conception en amont qui ne s’improvise pas et a forcément été pensé il y a déjà longtemps.
Il est donc tout à fait possible d’imaginer qu’ils avaient prévu de repenser leur cartes et leur pilotes et la répartition des fonctionnalités pour permettre de conserver le même contrôle sur la captivité des utilisateurs tout en ayant un pilote libre. En bref ils auraient seulement élargi leur interface entre leur code proprio et Linux.
CUDA est toujours proprio, leur firmware est toujours signé, ils ont seulement agrandi la couche d’interfaçage avec Linux pour simplifier la gestion du code noyau. Ça va clairement simplifier la vie des utilisateurs avec des distributions qui pourront fournir la couche de compatibilité avec le noyau, et même peut-être la possibilité de rétroporter indépendamment les futurs pilotes noyau lorsque les cartes actuelles ne seront plus prises en charge par Nvidia pour toujours bénéficier des nouvelles bibliothèques proprio sans avoir à utiliser de vieux noyaux. Mais concernant l’applicatif, ce sur quoi s’appuient les applications (Vulkan, CUDA, NVENC, NVDEC), tout cela reste proprio.
Nvidia est une plateforme. Un programme qui requiert CUDA ou autre technologie spécifique à Nvidia n’est pas multi-plateforme. Quand un programme requiert CUDA, le choix de Linux ou Windows n’est alors qu’un choix accessoire comme on choisit un bureau GNOME ou KDE, la plateforme c’est Nvidia (Nvidia/NT ou Nvidia/Linux, c’est toujours Nvidia). Nvidia n’a rien changé à cela.
ce commentaire est sous licence cc by 4 et précédentes
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.