NVIDIA contribue la gestion du GPU ARM Tegra K1 dans Nouveau

Posté par  (site web personnel) . Édité par Davy Defaud, yalla, Xavier Teyssier, Nÿco, ZeroHeure, Benoît Sibaud et palm123. Modéré par ZeroHeure. Licence CC By‑SA.
71
7
fév.
2014
Noyau

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

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

  • # Splendide!

    Posté par  . Évalué à 10.

    Finalement, les 3 acteurs du marché des puces graphiques contribuent au libre…

    • Intel ne propose que le pilote libre, et se débrouille pour que le pilote existe avant que le matériel soit au magasin
    • AMD propose un pilote propriétaire pour le matériel récent, mais le libre lui permet de simplifier celui-ci en ne gardant que très peu de temps le support (les Radeon 4xxx ne sont plus supportés en propriétaire)
    • Nvidia ne propose qu'un pilote propriétaire, mais commence à améliorer le pilote libre, après avoir abandonné le libre obfusqué.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Splendide!

      Posté par  (site web personnel) . Évalué à 9.

      AMD propose un pilote propriétaire pour le matériel récent, mais le libre lui permet de simplifier celui-ci en ne gardant que très peu de temps le support (les Radeon 4xxx ne sont plus supportés en propriétaire)

      Le travail sur le pilote libre radeon est fait par une équipe payée par AMD. AMD produit donc deux pilotes :)

      Nvidia ne propose qu'un pilote propriétaire, mais commence à améliorer le pilote libre, après avoir abandonné le libre obfusqué.

      C'est une bonne façon de résumer, oui.

      • [^] # Re: Splendide!

        Posté par  (site web personnel) . Évalué à 2.

        Le travail sur le pilote libre radeon est fait par une équipe payée par AMD. AMD produit donc deux pilotes :)

        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  (site web personnel) . Évalué à 10.

          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 ?

          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:

          • Pilote proprio: Course pour avoir le device le plus rapidement possible sur le marché. Performance maximale, duplication de code, peu maintenable;
          • Pilote libre: Pilote plus simple, plus facilement portable et qui préfère prendre son temps pour bien faire les choses. Développé par une équipe réduite ce qui veut dire que l'équipe connait mieux le matériel dans son ensemble.
          • [^] # Re: Splendide!

            Posté par  . É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  (site web personnel) . Évalué à 4.

            Pour les pilotes propriétaires c'est tout simplement de pouvoir supporter leur matériel sous Linux de manière satisfaisante pour leurs clients professionnels. Cela nécessite un driver qui supporte toutes les fonctionnalités OpenGL mais aussi qui est certifié avec les gros logiciels (CATIA, Maya …). Si AMD voulait faire cela avec les drivers libres il leur faudrait embaucher plusieurs centaines de personnes pour travailler sur le driver libre (on ne peut pas partager les équipes entre le driver propriétaire et le driver libre). Il faudrait donc un investissement considérable pour AMD pour un retour nul ou presque. Leurs clients professionnels ne s'intéressent pas de savoir si le driver est libre ou pas, ils veulent juste une solution rapide et à un prix raisonnable.

            https://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-graphiques-radeon-pour-red-hat

        • [^] # Re: Splendide!

          Posté par  . Évalué à 7.

          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 ?

          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  (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  . É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  . Évalué à 10. Dernière modification le 07 février 2014 à 11:28.

      Qu'ils donnent les specs précises de leur matos et la communauté se chargera de faire des drivers libres corrects !

      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  (site web personnel) . Évalué à 5.

        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.

        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  . É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…

      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  (site web personnel) . É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…

      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!

      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…).

      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?

      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 !!!

      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.

      Qu'ils donnent les specs précises de leur matos et la communauté se chargera de faire des drivers libres corrects !

      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  . Évalué à 6.

      On est vendredi :

      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…

      Personne ne libère leur matériel (ni AMD, ni intel, ni nVIDIA).

      En effet, si c'était vraiment le cas, ils auraient libéré le source de leurs drivers CATALYST proprios…

      CATALYST c'est AMD/ATI et oui ça reste propriétaire.

      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…).

      Je pense que les utilisateurs de tegra s'en rendraient vite compte.

      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 !

      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.

      Qu'ils donnent les specs précises de leur matos et la communauté se chargera de faire des drivers libres corrects !

      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  (site web personnel) . Évalué à 3.

      ceux d'NVIDIA ils plantent à peu près une fois par jour, Nouveau, c'est toutes les heures…

      Ça ressemble plus à un problème matériel ça.

  • # Titre

    Posté par  . Évalué à 4.

    s/contribue/contribue à/

    • [^] # Re: Titre

      Posté par  (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  . É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  (site web personnel) . Évalué à 1.

          Visiblement, c'est un verbe intransitif

          Curieux, avec comme quatrième exemple :

          Contribuer à la fortune

          Ce n'est pas ce que j'appelle intransitif ça. Plutôt intransitif ou transitif indirect selon les cas.

          • [^] # Re: Titre

            Posté par  . Évalué à 5.

            Ce n'est pas ce que j'appelle intransitif ça. Plutôt intransitif ou transitif indirect selon les cas.

            La fameuse transitivité du verbe d'Heisenberg ?

      • [^] # Re: Titre

        Posté par  . É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 "à"?

        J'écris ce message juste dire que je vois très clairement quoi tu parles :D

      • [^] # Re: Titre

        Posté par  (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  (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  (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)

  • # Précisions ?

    Posté par  (site web personnel) . Évalué à 3.

    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à.

    Je ne pige pas : Nouveau et Android, ça fait bien deux pilote pour le même matos ?!

    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.

    Je vois pas le rapport entre les stratégies de NVIDIA et de Google ?

    • [^] # Re: Précisions ?

      Posté par  (site web personnel) . Évalué à 5.

      Je ne pige pas : Nouveau et Android, ça fait bien deux pilote pour le même matos ?!

      Oui.

      Je vois pas le rapport entre les stratégies de NVIDIA et de Google ?

      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  (site web personnel) . Évalué à 1. Dernière modification le 08 février 2014 à 13:27.

        Oui.

        C'est pas contradictoire avec ce que tu écris ?

        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.

        Ç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  (site web personnel) . Évalué à 3.

          Ç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.

          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  . É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  (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  (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.