Journal AMD et plus d'open source

Posté par  . Licence CC By‑SA.
47
24
mar.
2014

Cher bookmark,

AMD serait en train de réfléchir à utiliser le pilote noyau du projet de pilote opensource radeon. Cela voudrait dire que le pilote propriétaire Catalyst ne serait plus qu'un blob en espace utilisateur et qu'AMD contribuerait sans doute plus pour la partie noyau pour y développer la compatibilité avec ses nouveaux produit.

Rien n'est encore sûr mais je trouvais la nouvelle intéressante. Et pur la nimage, je suis sur mon téléphone, du coup, il faudra s'en passer, vous n'avez qu'à imaginer ce qui vous plait, c'est bon pour votre cerveau ramolli par les troll de la faire travailler de temps en temps.

http://www.phoronix.com/scan.php?page=article&item=amd_catalyst_kernel&num=1http://www.phoronix.com/scan.php?page=article&item=amd_catalyst_kernel&num=1

  • # ca a l'air plutot interessant

    Posté par  . Évalué à 8.

    D'apres ce que j'ai compris, AMD va decouper en deux son driver catalyst: un open source en mode kernel et une autre partie qui ne contiendra que le code closed-source en espace utilisateur. Donc en gros AMD sera plsu que partie prenante dans la partie noyau car elle sera absolument necessaire a leur driver.

    Si cela arrive a maturite ca peut etre super car le blob binaire pourrait probablement etre utilise que quand il y en a besoin.

    • [^] # Re: ca a l'air plutot interessant

      Posté par  . Évalué à 7. Dernière modification le 24 mars 2014 à 13:03.

      Si AMD contribue au driver du noyau, et si le driver binaire devient compatible avec celui-ci, cela obligera la partie binaire à être compatible avec le KMS, ce qui est une bonne nouvelle.

  • # Pareil chez NVIDIA Tegra

    Posté par  . Évalué à 5.

    Tout en sachant que cette stratégie pourrait être la même que celle utilisée par NVIDIA pour le Tegra, étant donné les contributions DRM à nouveau qu’on a vu récemment. Si le système fonctionne, il y a fort à parier que d’autres fabricants de GPU (surtout ARM) suivent dans la même voie.

    Concernant les cartes desktop NVIDIA, je ne pense pas qu’ils adoptent cette approche étant donné que leur driver desktop fonctionne plutôt bien (par rapport à fglrx).

    • [^] # Re: Pareil chez NVIDIA Tegra

      Posté par  . Évalué à 4.

      il y a fort à parier que d’autres fabricants de GPU (surtout ARM) s

      Sur arm le driver kernel est déjà opensource :
      http://malideveloper.arm.com/develop-for-mali/drivers/open-source-mali-gpus-linux-kernel-device-drivers/

      • [^] # Re: Pareil chez NVIDIA Tegra

        Posté par  . Évalué à 8.

        Opensource, mais la situation n’est pas vraiment comparable:
        - il n’est pas upstream
        - ça n’utilise pas les infrastructures du kernel (ttm/gem, dma-buf, drm core, etc.)
        - c’est juste la partie gpu donc pas de display, modesetting in-kernel, etc.
        - il n’y a(vait) pas d’implémentation libre de la partie userspace. Lima n’est pas encore prêt ou intégré aux distributions (ni même à mesa, mais pour d’autres raisons).

        C’est pour ça que je n’en ai pas parlé. D’autres drivers ARM sont dans la même situation, mais on ne peut pas comparer avec NVIDIA qui pourrait venir à utiliser nouveau pour le Tegra ou AMD qui pourrait utiliser radeon pour catalyst.

    • [^] # Re: Pareil chez NVIDIA Tegra

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

      J'imagine que ce repositionnement stratégique arrive à point nommé avec le développement de SteamOS et son futur avènement…

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

  • # Ca me rappelle

    Posté par  . Évalué à 6.

    Qu'une contribution similaire avait été rejeté par le mainteneur Linux (pour une autre carte vidéo) car la partie kernel n'était utilisable que par le blob propriétaire.
    Y a t'il le même risque ici?

    • [^] # Re: Ca me rappelle

      Posté par  . Évalué à 9.

      Il y a le driver radeon dans mesa qui utilise ce pilote. Par contre, s'ils veulent introduire des interfaces qui ne sont utilisées que par le pilote propriétaire, ça peut coincer. Mais, à mon avis, les interfaces utiles pour le driver propriétaires seront utiles pour le driver opensource.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # c'est lourd de renseigner le titre ...

    Posté par  . Évalué à 4. Dernière modification le 25 mars 2014 à 14:56.

    mais comme j'ai une radeon, je trouve ce contenu extrêmement pertinent, merci :D

    Par contre radeon ça rime vraiment avec piège à ***, vu que cela ne concerne que les nouveaux produits. En fait ils développent des parts de marchés.

    bref, quoi .. un jour peut être des lois responsabiliseront les grands constructeurs.

    • [^] # Re: c'est lourd de renseigner le titre ...

      Posté par  . Évalué à 2. Dernière modification le 03 avril 2014 à 17:23.

      Par contre radeon ça rime vraiment avec piège à ***, vu que cela ne concerne que les nouveaux produits. En fait ils développent des parts de marchés.

      Pas du tout !

      Regarde ce tableau : http://xorg.freedesktop.org/wiki/RadeonFeature/

      Il montre l'avancement du pilote "radeon" pour chacun des chipsets des cartes graphiques ATI/AMD.

      On voit que le pilote prend en charge les chipsets depuis le "R100" jusqu'aux cartes les plus récentes, autrement dit toutes les cartes depuis l'an 2000 !

      Tu confonds avec le pilote "fglrx" qui lui ne prend effectivement en charge que les cartes récentes, puisque ce pilote n'est rien d'autre que le pilote "Catalyst" version Linux.

      En résumé :
      - pilote "radeon" = pilote libre maintenu pour toutes les cartes depuis l'an 2000 ;
      - pilote "fglrx" = les pilotes "Catalyst" = pilote propriétaire fermé maintenu que pour les cartes récentes (environ 2-3 ans) ;
      - pilote "radeonhd" = pilote libre obsolète qui était destiné à prendre en charge les chipsets "R500" à "R700" mais qui a été intégré dans le pilote "radeon" (étant donné que "radeon" est destiné à prendre en charge toutes les cartes graphiques), il ne sert donc plus à rien mais sera maintenu le temps que certaines personnes le trouveront utile (donc normalement personne…).

      EDIT : je rappelle que le pilote "radeon" est non seulement libre mais développé par les équipes d'AMD, ce qui permet d'avoir les pilotes les plus stables possibles et le plus en avance possible. En effet, on voit maintenant les pilotes intégrés dans le noyau Linux quelques mois avant la sortie des nouvelles cartes sur le marché ! Autrement dit, aujourd'hui lorsqu'on achète une carte graphique AMD, on est sûr qu'elle sera supportée par Linux sans avoir à installer quoique ce soit :-)

      • [^] # Re: c'est lourd de renseigner le titre ...

        Posté par  . Évalué à 2.

        En effet, on voit maintenant les pilotes intégrés dans le noyau Linux quelques mois avant la sortie des nouvelles cartes sur le marché !

        Tu as des des exemples ? Je n'en ai pas encore vu.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: c'est lourd de renseigner le titre ...

          Posté par  . Évalué à 2.

          Oui :

          Ce noyau apporte aussi la prise en charge des futurs processeurs à puce graphique intégrée (APU) Berlin, qui devraient sortir début 2014.

          Source : http://linuxfr.org/news/sortie-de-linux-3-12#atiamd-pilote-radeon

          Bon OK c'est vrai que c'est pour un APU, mais tout de même, on parle bien de la partie graphique. J'avais surtout retenu que AMD avait réussi à sortir un pilote en avance pour gérer du matériel graphique. Ca laisse présager de bonnes choses.

          • [^] # Re: c'est lourd de renseigner le titre ...

            Posté par  . Évalué à 4.

            Pour les APU Berlin, c'est un cœur graphique qui est déjà sorti dans d'autres APU, du coup, ce n'est pas vraiment un support avant la sortie du matériel. Sauf si j'ai loupé un truc.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: c'est lourd de renseigner le titre ...

        Posté par  . Évalué à 1.

        Il est plus que probable que je me trompes.

        Mais au fond, je ne veux pas savoir.
        J'ai engraissé ces grosses boîtes parce que le 'marché' ne me laisse pas de choix, ou difficilement.
        Et aujourd'hui mon laptop équipé d'une radeon ne fonctionne pas pleinement.
        Je suis obligé de rester sur le contrôleur intel sandybridge /tout moche/ aurais je envie de dire..

        Ma réflexion s'arrête là quand à ces constructeurs.
        Les cartes graphiques ne me font pas bander, je veux juste que ça fonctionne.
        Et dans cette histoire mon doigt est pointé sur 'ceux qui en font du fric' et le restera tant que ce ne sera pas résolut.

        Tout de façon, j'ai pas le choix.

        Indice nikei en hausse, business as usual.

        • [^] # Re: c'est lourd de renseigner le titre ...

          Posté par  . Évalué à 1. Dernière modification le 05 avril 2014 à 20:15.

          rapport de bug.

          Désolé mais ça fonctionne sur la majorité des machines leur pilote libre.

          Donc si il y a un problème bah faut le rapporter.

          Pour Intel le problème c'est qu'ils sont pas bons pour faire des pilotes.

          Je vois bien plus souvent des personnes qui se plaignent de bugs avec le pilote Intel qu'AMD.

          La situation n'est pas différente sous Windows.

          à l'heure actuelle au niveau des moyens nVidia et Intel en ont bien plus qu'AMD.

          • [^] # Re: c'est lourd de renseigner le titre ...

            Posté par  . Évalué à 1.

            bah je vais faire le super boulay /désolay/… Ne connaîtrais tu pas une initiative qui me permettrait moyennant peu d'effort intellectuel de produire le dit rapport de bug que je puisse poster /quelque part/ ?

            La vérité vraie c'est que déjà pour trouver mon modèle de CG via ma ligne de commande je suis obligé de chercher trois plombes sur G, alors si par dessus cela je dois me farcir gdb + la boot sequence + je ne sais trop quoi d'autre…… je sens que je vais abandonner bien vite comme bien souvent sur ces sujets là.

            • [^] # Re: c'est lourd de renseigner le titre ...

              Posté par  . Évalué à 2.

              [deasy@lactee ~]$ lspci |grep VGA
              01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450/6350]

              Je me demande d'où sort ce "nee"… soit c'est pas important.

              ça donne quoi ça chez toi ?
              Tu n'as toujours pas décrit ton problème(ce qu'il se passe).

              Et aussi une copie du journal de xorg serait bienvenue ainsi que du noyau. Histoire de voir si moi ou une autre personne du coin sait de quoi ça peut venir.

              Tu devrais aussi tester avec des logiciels assez récent pour voir si le bug n'a pas déjà été corrigé entre temps.

              Est-ce que tu sais aussi si tu as les petits blobs d'AMD ? les firmwares.

              http://www.x.org/wiki/RadeonFeature/#index9h2
              https://bugs.freedesktop.org/

              Je suivrai les notifications de linuxfr pour continuer ce fil.

              Il est tard donc je vais pas trop en faire.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.