Le titre est accrocheur, mais les faits sont encore plus incroyables. Juste avant le FOSDEM 2014, Alexandre Courbot, un développeur de chez NVIDIA, a envoyé une suite de 16 correctifs pour ajouter la gestion des Tegra K1 dans Nouveau, le pilote libre communautaire pour les cartes graphiques NVIDIA.
NdM : Pour la bonne compréhension du ton enthousiaste de cette dépêche, précisons que son auteur est un des principaux développeurs de Nouveau.
Sommaire
- Petit historique du projet Nouveau
- Quand Tegra devient basé sur les GPU Keplers
- Conclusion
- La suite ?
Petit historique du projet Nouveau
Historiquement, Nouveau a toujours été un pilote basé sur la rétro‐ingénierie, et les gens de chez NVIDIA avait toujours dit qu’ils ne comptaient ni aider ni empêcher le développement de ce pilote. Pour mémoire, Nouveau apporte l’accélération 2D, 3D et vidéo pour les cartes TNT2, jusqu’aux toutes dernières cartes de la famille Kepler. Pour un historique complet du projet, vous pouvez consulter la présentation donnée au XDC 2011 sur l’état de Nouveau.
Il y a bientôt 6 mois, NVIDIA avait défrayé la chronique en fournissant de la documentation, ainsi qu’une adresse de courriel à laquelle les développeurs du projet Nouveau peuvent poser leurs questions sur le matériel. Ce changement de direction est dû à une volonté d’améliorer la prise en charge des processeurs graphiques NVIDIA sous Linux, même quand les pilotes propriétaires ne sont pas installés. Cette nouvelle avait fait l’objet d’un journal dans lequel l’auteur avait prédit que je ne tarderai pas à vous faire savoir de quoi il en retournait vraiment. Cette présentation donnée au FOSDEM ce week‐end devrait y répondre (la vidéo devrait arriver bientôt).
Quand Tegra devient basé sur les GPU Keplers
Ce travail de NVIDIA vient d’une idée simple : les Tegra K1 étant basés sur des cœurs graphiques Kepler, qui sont déjà pris en charge par Nouveau, leur ajout devrait être assez simple. De plus, Linus n’autorisant généralement pas deux pilotes concurrents pour le même matériel, il est assez intéressant de voir que NVIDIA a décidé de réaliser la prise en charge totalement en amont, et de ne pas se limiter à l’arbre Android pour lequel un pilote existe déjà. Nous pouvons spéculer que ce travail est le fruit de la volonté de Google de rendre le noyau Linux pour Android aussi proche que possible du noyau Linux original.
L’affichage n’étant pas géré par le processeur graphique (Tegra), mais par Host1x, la gestion des modes d’affichage (mode setting) n’est pas nécessaire dans les contributions apportées à Nouveau. Le processeur graphique sera donc exposé comme un nœud de rendu (render node) et il sera nécessaire d’utiliser l’infrastructure PRIME (utilisée pour la prise en charge d’Optimus) de façon à autoriser les applications à utiliser le processeur graphique pour le rendu et Host1x pour l’affichage. Bien que l’architecture PRIME ne prenne pas en charge pas la synchronisation logicielle entre processeurs graphiques, cela ne devrait pas poser de problèmes, car Host1x a la possibilité de se synchroniser en matériel. Des discussions sont en cours afin de faire fonctionner ces cartes de la façon la plus fiable et facile possible.
Comme les systèmes monopuces — SoC — Tegra n’ont pas de mémoire vidéo (la mémoire est partagée avec le processeur central), une bidouille a été réalisée dans cette première version afin de mieux coller au modèle mémoire actuellement mis en place par Nouveau. Cette bidouille consiste à allouer un bloc de mémoire et laisser Nouveau gérer la sous‐allocation via TTM. Ce problème est à l’étude par la partie de l’équipe responsable de la gestion de la mémoire.
Cette suite de correctifs apporte majoritairement les fonctionnalités suivantes :
- prise en charge des processeurs graphiques non‐PCI/AGP/PCIe ;
- prise en charge sous‐optimale de l’allocation mémoire ;
- prise en charge de l’envoi de commandes aux processeurs graphiques GK20a ;
- corrections de multiples assomptions dans le code de Nouveau ;
- prise en charge de la détection des processeurs graphiques GK20a.
Conclusion
Bienvenue dans la communauté Nouveau, NVIDIA!
Je n’aurais jamais cru pouvoir dire ça il y a un an, mais ces six derniers mois ont montré un effort considérable d’ouverture, non pas uniquement en temps ingénieur disponible et en documentation, mais aussi en code ! Cela a aussi permis à Linus Torvalds de changer de doigt du majeur au pouce, quand il parle de NVIDIA. Encore toute mes félicitations à tous ceux qui sont impliqués dans ces projets, aussi bien côté libre que du côté de NVIDIA, et qui ont rendu cela possible.
La suite ?
Finir la prise en charge des GK20a
Il aurait fallu environ deux semaines de travail à Alexandre pour effectuer ce travail de portage, un temps très faible pour un récent contributeur au projet Nouveau. Ben Skeggs, mainteneur de la partie noyau du projet Nouveau, a trouvé les correctifs globalement bons pour une demande d’inclusion. Quelques modifications mineures sont cependant nécessaires.
Le travail est cependant loin d’être terminé. Il va falloir trouver une meilleure solution pour la gestion de la mémoire, mais aussi résoudre le problème de l’affichage depuis l’espace utilisateur. Pour finir, certaines modifications légères dans libdrm et le pilote Mesa nvc0 seront nécessaires. Un petit aperçu des discussions relatives à l’espace utilisateur est disponible.
Contribution unique ou début d’une nouvelle ère ?
J’ai eu l’occasion de discuter au FOSDEM 2014 avec Thierry Reding, développeur Tegra hobbyiste ayant été embauché par NVIDIA afin d’améliorer la prise en charge de Tegra dans le noyau Linux. Il est difficile de prévoir le futur, mais il semblerait que ce ne soit pas une contribution unique. Le temps nous le dira.
Aller plus loin
- Wiki du projet Nouveau (142 clics)
- Le lien vers la suite de correctifs proposés par NVIDIA (87 clics)
# Splendide!
Posté par ʭ ☯ . Évalué à 10.
Finalement, les 3 acteurs du marché des puces graphiques contribuent au libre…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Splendide!
Posté par Martin Peres (site web personnel) . Évalué à 9.
Le travail sur le pilote libre radeon est fait par une équipe payée par AMD. AMD produit donc deux pilotes :)
C'est une bonne façon de résumer, oui.
[^] # Re: Splendide!
Posté par azmeuk (site web personnel) . Évalué à 2.
Quel est leur intérêt ? Là aussi d'avoir un support partiel des cartes AMD lorsque le pilote propriétaire n'est pas installé ?
Aussi, qu'est-ce qui retiens les constructeurs de publier des pilotes libres ? Y a-t-il un vrai risque que les pilotes révèlent des « secrets de fabrication » qu'ils voudraient cacher à la concurrence ?
[^] # Re: Splendide!
Posté par Martin Peres (site web personnel) . Évalué à 10.
Oui, je me suis posé la question aussi mais voilà mon analyse. Jérôme Glisse pourra l'améliorer si il nous lit.
Les pilotes propriétaires sont écrits pour Windows et doivent être disponibles et faciles à installer dès la sortie du matériel, avec le maximum de performance pour faire beau dans les benchmarks. Du coté du libre, le but est d'avoir le support mais surtout de pouvoir le maintenir dans le futur. Le pilote est plus simple, moins orienté performance (moins de hacks et de complexité pour améliorer les perfs dans tel ou tel jeu) et il est donc plus petit. D'ailleurs, il me semble me souvenir qu'AMD a embauché des développeurs pour porter le driver libre à Windows mobile, pour les tablettes AMD, car le pilote était plus petit et plus facile à porter.
Pour résumer:
[^] # Re: Splendide!
Posté par djano . Évalué à 7.
Il me semblait surtout que la pricipale difference etait que les pilotes libres partagent du code entre materiel de differents marques (AMD, NVidia ou Intel) grace a des frameworks existant exclusivement sous Linux tels que TTM (ou GEM? je ne sais plus).
Alors que les pilotes proprietaires sont destines a s'executer sur Windows, Linux et tous les OS qu'ils veulent alors ils ne peuvent pas vraiment utiliser des frameworks specifiques a un seul systeme.
[^] # Re: Splendide!
Posté par Martin Peres (site web personnel) . Évalué à 4.
C'est vrai, mais c'est un détail d'implémentation, pas une stratégie d'entreprise ;)
[^] # Re: Splendide!
Posté par antistress (site web personnel) . Évalué à 4.
https://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-graphiques-radeon-pour-red-hat
[^] # Re: Splendide!
Posté par barmic . Évalué à 7.
On dit souvent que tout le code des pilotes n'appartient pas au constructeurs et qu'ils n'ont pas donc les mains libres pour le libérer. De plus la concurrence AMD/nVIDIA est très forte et si tu t'intéresse un peu au jeux vidéos sous windows, tu verra que la simple mise à jour du driver peut permettre à l'un de dépasser l'autre sur les benchmarks. Je présume qu'ils n'ont pas d'intérêt à refiler leurs optimisations à leur concurrents direct.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Splendide!
Posté par Martin Peres (site web personnel) . Évalué à 7.
Ces optimisations sont généralement très dépendentes de l'architecture matérielle et logicielle.
Et ce qui fait peur, en général, c'est d'exposer trop de comment ça marche et que quelqu'un se rende compte qu'un brevet avait été déposé sur une technique utilisée. C'est pour ça qu'AMD a une procédure aussi longue de vérification du code avant publication.
# À mitiger...
Posté par gyom gyom . Évalué à -10.
Oui, c'est bien de s'enthousiasmer et c'est pas mal si c'est le signe que NVIDIA va ENFIN se mettre à libérer ses puces… Mais je n'y crois pas trop… En effet, si c'était vraiment le cas, ils auraient libéré le source de leurs drivers CATALYST proprios…
Pour le moment, ne nous réjouissons pas trop vite, ce ne sont que 16 petits patches pour /1 processeurs spécifique/ pour /1 plateforme spécifique/… Et en plus dans Nouveau, qui est encore plus pourri que les drivers proprios d'NVIDIA (ceux d'NVIDIA ils plantent à peu près une fois par jour, Nouveau, c'est toutes les heures…).
La vrai raison parce qu'ils ne voudraient pas louper des marchés dans le mobile (d'où ARM), parce leurs concurrents, Intel et AMD, intègrent et libèrent (presque) tout !
On est TRÈS LOIN avec ces gentils petits patches de ce que font ATI/AMD ou Intel !!!
Qu'ils donnent les specs précises de leur matos et la communauté se chargera de faire des drivers libres corrects !
[^] # Re: À mitiger...
Posté par flagos . Évalué à 10. Dernière modification le 07 février 2014 à 11:28.
Bon alors ca, c'est un mythe qui a vécu, va falloir arreter avec ca. Développer un driver décent, c'est un travail énorme. Pour bosser dans l’électronique, un driver c'est pas loin d'etre 25% des ressources alloués a un SoC. Les specs, je t'assure que ca fait pas des miracles. Bien souvent, les blocs fonctionnels sont mal spécifiés. Les drivers en interne sont en général codés avec un petit bout de code faisant office de driver léger pour le test fourni en tant que template.
Et quand bien même, les specs sont belles, a jour, compréhensibles et non buggés, ben derrière il faut lever une armée pour que ca suive. Regarde ATI par exemple, il a fallu un temps dingue pour avoir la gestion de l'énergie. D'ailleurs, au final, ca marche vraiment bien maintenant ?
La réalité, c'est que le seul moyen d'avoir un support linux libre décent, c'est de faire participer le constructeur. Répondre a des questions, fournir des specs pourquoi pas, fournir des bouts de code qui marche… mais surtout, contribuer directement sur le kernel.
Au final, on peut vraiment etre content que NVidia ait eu ce déclic après l'avoir refusé pendant des années. Globalement, j'ai l'impression que l'industrie de la micro elec dans son ensemble a de plus en plus envie de contribuer directement sur le kernel en mode upstream, et on ne peut que s'en féliciter. L'effet Android certainement.
[^] # Re: À mitiger...
Posté par Firwen (site web personnel) . Évalué à 5.
Tout à fait d'accord, Mais j'ai envie de te dire les specs c'est déja mieux que le néant.
Car la seul solution pour tenter d'avoir un driver sans les specs est d'avoir 20 barbus qui te pondent un driver en dé-compilant des binaires le week end.
Les specs sont certes pas le saint graal, tout personne ayant déja fait du de l'embarqué sait qu'il y a une distance terre-lune entre le comportement spécifié et le comportement réel. Mais elles permettent aux moins un développement un peu prés "humain", voir même de déléguer le development aux interessés, comme dans le cas de Radeon avec les gens de Silicon graphics et VMWare.
[^] # Re: À mitiger...
Posté par Ambroise . Évalué à 10.
Je penses que tu as fais une boulette entre AMD/ATI et NVIDIA.
D'ailleurs, AMD n'a absolument pas libéré les drivers Catalyst donc bon…
[^] # Re: À mitiger...
Posté par Martin Peres (site web personnel) . Évalué à 10.
Oh, faut pas réver, ils libèrent en effet pas grand chose. Mais en a t'on vraiment besoin? On peut tracer le pilote priopriétaire rapidement et maintenant, on peut poser des questions sur notre code ou sur une partie qu'on a pas bien comprise. Que demander de plus à part qu'ils nous envoient le matériel en avance sur la sortie officielle et qu'ils payent des ingénieurs pour améliorer Nouveau? Oh, c'est exactement ce qu'ils viennent de faire!
Je suis navré de savoir que ta carte plante autant, mais c'est une exception plutôt que la norme. Le bug est connu ou pas? Tu es certain que c'est pas ton matériel qui a un problème?
Oui, c'est exactement ce qui est dit dans l'article. Tu sais, les entreprises vont pas dépenser d'argent si ça n'apporte rien en retour (en image de marque ou en cash). Documenter un chipset wifi, c'est une chose. Documenter un GPU NVidia, c'est VRAIMENT autre chose. C'est plus complexe que tout le reste de ton pc réuni et ça change dans chaque famille.
Les specs sont rarement exactes et bonne chance pour en écrire une de qualité. On essaye de le faire et c'est pas trivial.
[^] # Re: À mitiger...
Posté par barmic . Évalué à 6.
On est vendredi :
Personne ne libère leur matériel (ni AMD, ni intel, ni nVIDIA).
CATALYST c'est AMD/ATI et oui ça reste propriétaire.
Je pense que les utilisateurs de tegra s'en rendraient vite compte.
Ils se foutent d'intel qui n'est pas dans la course, leur puces étant assez faibles fasse à kepler. Pour AMD, ben AMD ne libère rien, ils contribuent à un driver libre, mais catalyst reste propriétaire.
Mais t'inquiète pas nVIDIA est devant intel et AMD réunis dans le marché mobile. Intel n'arrive pas à percer face à ARM (pourtant ils mettent le paquet là dessus). nVIDIA vend des chipsets Tegra avec ARM depuis longtemps maintenant.
Non. AMD a commencé comme ça et on s'est rendu compte que ce n'est pas si simple. Ce n'est pas qu'un problème de spécification, c'est aussi très complexe à développer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: À mitiger...
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Ça ressemble plus à un problème matériel ça.
[^] # Re: À mitiger...
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Il serait bon de suivre la température du processeur graphique pour voir si le problème est lié au refroidissement de la carte.
# Titre
Posté par Clément BRUGUERA . Évalué à 4.
s/contribue/contribue à/
[^] # Re: Titre
Posté par Martin Peres (site web personnel) . Évalué à 2.
Si on rajoute le "à", ça veut potentiellement dire qu'il y avait déjà quelque chose avant. Sans le "à", plus d'ambiguïté possible. C'est pas Français de ne pas mettre le "à"?
[^] # Re: Titre
Posté par anaseto . Évalué à 3.
Visiblement, c'est un verbe intransitif, donc pas d'objet, mais c'est vrai que vu qu'on peut parler de contribution, on devrait pouvoir contribuer une contribution, peut-être qu'une réforme arrangera ça dans cinquante ans, et tu devras bien sûr en compter cinquante autres avant que ça soit accepté en pratique ;)
[^] # Re: Titre
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Curieux, avec comme quatrième exemple :
Ce n'est pas ce que j'appelle intransitif ça. Plutôt intransitif ou transitif indirect selon les cas.
[^] # Re: Titre
Posté par Marotte ⛧ . Évalué à 5.
La fameuse transitivité du verbe d'Heisenberg ?
[^] # Re: Titre
Posté par j_m . Évalué à 2.
J'écris ce message juste dire que je vois très clairement quoi tu parles :D
[^] # Re: Titre
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6. Dernière modification le 07 février 2014 à 20:23.
Non, ce n'est pas français. L'équivalent de ce titre en français pourrait être : « NVIDIA contribue à Nouveau en y ajoutant la gestion du GPU… » (ou « participe à Nouveau » si on préfère, et il vaut sans doute la peine de préciser « contribue au pilote Nouveau » pour éviter la confusion avec l'adverbe « à nouveau »). Ou plus simplement : « NVIDIA ajoute la gestion du GPU machin à Nouveau ».
[^] # Re: Titre
Posté par Martin Peres (site web personnel) . Évalué à 3.
Merci Tanguy. Ça doit vraiment être un anglicisme, mais je trouvais que ça sonnait bien le "contribuer quelquechose".
# Remerciement
Posté par bubar🦥 (Mastodon) . Évalué à 7. Dernière modification le 07 février 2014 à 22:27.
Encore mes remerciements à tous ceux qui sont impliqués dans ces projets !!! ;-) (bn, ok la paraphrase saynul, mais le coeur y est)
[^] # Re: Remerciement
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
« Merci encore », ça sonne bien et c'est plus simple à mon avis. Bon, le grammairien va aller se coucher hein…
# Précisions ?
Posté par antistress (site web personnel) . Évalué à 3.
Je ne pige pas : Nouveau et Android, ça fait bien deux pilote pour le même matos ?!
Je vois pas le rapport entre les stratégies de NVIDIA et de Google ?
[^] # Re: Précisions ?
Posté par Martin Peres (site web personnel) . Évalué à 5.
Oui.
NVIDIA fourni un driver codé vite fait pour Android, faut que ça marche. Ensuite Google demande à NVIDIA de faire un effort et de rendre ce support disponible upstream pour diminuer les différences entre Linux et le noyau Android. L'avantage de diminuer les différences, c'est de diminuer les risques de problèmes lorsque android se re-base sur un nouveau noyau. Google doit vraiment pas vouloir trop diverger et c'est très bien!
Comme Google a de l'argent et doit probablement être prêt à payer, NVIDIA est prêt à dépenser cet argent pour faire le travail demandé. Tout simplement.
[^] # Re: Précisions ?
Posté par antistress (site web personnel) . Évalué à 1. Dernière modification le 08 février 2014 à 13:27.
C'est pas contradictoire avec ce que tu écris ?
Ça ne colle pas pour moi avec le fait que les autres fabricants de cœurs graphiques pour l'embarqué en ont rien à battre des pilotes du noyau si Google avait vraiment du pouvoir à ce niveau… Non, je pense que le fait que NVIDIA soit challenger sur ce marché les pousse à se différencier tout simplement, bref que c'est une stratégie NVIDIA pure
[^] # Re: Précisions ?
Posté par Martin Peres (site web personnel) . Évalué à 3.
Possible que ce soit un mélange des deux. Je sais de source sûre que c'est quelque chose que Google voulait aussi. La spéculation était sur Google payant pour ce développement.
[^] # Re: Précisions ?
Posté par Maclag . Évalué à 4.
Je pense qu'on part ici de l'hypothèse que nVidia est bien plus intéressée par un pilote qui marche bien sous Android que sur xorg.
Donc si nVidia met des ressources sur le pilote xorg, c'est que beaucoup de choses seront réutilisables sur Android, donc que Google va/est en train de faire évoluer son noyau de sorte que l'écriture des pilotes converge.
Pure spéculation de ma part, hein!
[^] # Re: Précisions ?
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 08 février 2014 à 13:57.
Intéressant, mais c'est possible même avec une bibliothèque C différente (j'imagine que oui et que c'est à la compilation que les changement s'opèrent), un serveur d'affichage différent (SurfaceFlinger) et surtout les API propres à Android qui ne suivent pas nécessairement la norme POSIX ?
En même temps tu dis toi même que c'est 16 correctifs / 15 j de travail "seulement"
[^] # Re: Précisions ?
Posté par Martin Peres (site web personnel) . Évalué à 2.
Je ne pense pas que le userspace ait un grand intérêt pour Google. Ils peuvent fournir un binaire facilement pour avoir la libgles. Le reste est vraiment pas nécessaire pour Android.
Cela dit, je pense qu'ils vont essayer de faire marcher notre userspace avec le Tegra K1 car Dave Airlie a déjà refusé des drivers en espace noyau open source si le userspace ne l'était pas. Avoir un embryon de truc qui marche en userspace, ça suffirait à Dave Airlie et NVIDIA peut avoir son driver proprio à lui.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.