Broadcom libère la pile graphique du Raspberry Pi

36
24
oct.
2012
Linux

La pile graphique du Raspberry Pi est aujourd’hui intégralement libre. C’est ce qu’annonce AlexBradbury sur le blog de la fondation à l’initiative du projet.

Le développeur affirme que le BCM2835 embarqué sur le Raspberry Pi est le premier système sur puce d’architecture ARM à disposer de pilotes libres pleinement fonctionnels fournis par le fabricant.

Mise à jour du 25 octobre : Il semble que l’annonce d’une libération de la pile graphique ne soit en réalité qu’un coup publicitaire de Broadcom et de la fondation Raspberry Pi. Selon Luc Verhaegen et Dave Airlie le code libéré n’est qu’une mince couche qui se contente de faire appel au binaire tournant dans le processeur graphique.

NdM : Le Raspberry Pi est un ordinateur de la taille d’une carte de crédit et dont le prix de vente lors de son lancement était de 25 euros. Vous trouverez quelques retours des lecteurs de LinuxFr.org sur ces pages.

Participants à la rédaction de cette dépêche : weeber, Nÿco et Benoît.

Ceci a été rendu possible grâce à la diffusion sous licence BSD de toutes les bibliothèques permettant d’utiliser la puce de Broadcom. Cette dernière est en charge aussi bien du rendu 3D que des opérations d’encodage et de décodage vidéo.

Architecture logicielle de la Raspberry Pi

Ainsi, la prise en charge d’OpenGL pour le rendu 3D, d’OpenVG pour le vectoriel et d’OpenMax pour le multimédia est maintenant entièrement basée sur du code libre.

Ceci devrait notamment faciliter l’implémentation de Wayland sur le célèbre ordinateur. Cela permettra également de faciliter le développement des pilotes libres tels que Mesa 3D sur d’autres plates‐formes équipées du même processeur graphique. Cependant, certaines parties sont implémentées directement en langage assembleur spécifique au videocore.

Après avoir annoncé que son ordinateur serait fabriqué au Royaume‐Uni et non plus en Chine, la fondation continue de soigner son image de marque. En évoquant plusieurs systèmes d’exploitation qui pourraient bénéficier de cette avancée (FreeBSD, NetBSD, Plan9, RISC OS et Haiku), elle se positionne comme un contributeur important au logiciel libre.

  • # Et les sources du gros firmware qui gère le GPU?

    Posté par (page perso) . Évalué à  9 .

    Et les sources du gros firmware qui gère le GPU, elles sont ou?

    • [^] # Re: Et les sources du gros firmware qui gère le GPU?

      Posté par (page perso) . Évalué à  9 .

      Voir sur LWN http://lwn.net/Articles/520930/

      C'est clair que cette annonce semble un peu pipeau car bien bridée par une API.

      • [^] # Re: Et les sources du gros firmware qui gère le GPU?

        Posté par . Évalué à  4 .

        Je ne suis pas d'accords: ils ont annoncé qu'ils ont libéré leur pilote. C'est ce qu'ils ont fait, POINT, donc ce n'est pas du pipeau (ne pas confondre pilote et firmware).

        Corollaire: tout le code tournant sur l'ARM peut maintenant être open-source, et conséquence positive OpenBSD devrait pouvoir être porté sur Raspberry Pi.

        Après leur pilote est pour des accéder des interfaces "haut niveau" fournie par le GPU (qui a un compilateur embarqué) et non pas des interfaces "bad niveau":
        1) ça rends ces pilotes beaucoup plus figés et plus fragile, ce que tu appelle (correctement) "bridé".
        2) c'est moins intéressante pour ceux qui aiment bien "mettre les mains dans le cambouis"

        • [^] # Re: Et les sources du gros firmware qui gère le GPU?

          Posté par . Évalué à  9 .

          La nouvelle a d'ailleurs été très chaleureusement accueillie par le leader charismatique d'OpenBSD.

          http://marc.info/?l=openbsd-misc&m=135109499020826&w=2

          • [^] # Re: Et les sources du gros firmware qui gère le GPU?

            Posté par . Évalué à  0 .

            Mouai sauf que la "closed source backend" tourne sur un autre processeur.
            Mais j'aurai du m'en douter: Téo est plus sensible à l'esprit qu'à la lettre..

            • [^] # Re: Et les sources du gros firmware qui gère le GPU?

              Posté par . Évalué à  0 .

              Mouai sauf que la "closed source backend" tourne sur un autre processeur.

              Non, le "firmware" qui est enfaîte un driver complet, et non pas un "firmware" au sens conventionnel du terme (blob qu'on charge et qui sera exécuté dans la mémoire d'une puce séparée) ne tourne pas sur le GPU mais bien sur le CPU. Il est néanmoins probable que le firmware charge lui aussi un vrai firmware dans le GPU pour réaliser certaines fonctions.

              • [^] # Re: Et les sources du gros firmware qui gère le GPU?

                Posté par . Évalué à  1 .

                C'est faux. Le firmware (blob propriétaire) tourne sur le GPU et ne touche pas le CPU à part pour le démarrer. Quand tu allumes to Raspberry Pi, c'est le GPU qui s'occupe de tout initialiser avant de booter et de donner la main au CPU.

                • [^] # Re: Et les sources du gros firmware qui gère le GPU?

                  Posté par . Évalué à  0 .

                  Un GPU n’exécute pas de code, il n'a aucun moyen de magiquement charger un blob. On envoie des commandes à un GPU par l'intermédiaire du kernel, commandes qui dérivent des fonctions d'une API (opengl et compagnie) et c'est le driver qui traduit les appels opengl en commandes que le GPU comprends.
                  Même les shaders sont compilés (translation glsl / hlsl / gc >> un unique langage spécifique à un GPU) par le driver (qui s’exécute encore une fois dans le CPU) avant d'envoyer le tout au GPU.

                  Se référer à comment fonctionne mesa et autres piles de drivers sur un PC "classique".

                  • [^] # Re: Et les sources du gros firmware qui gère le GPU?

                    Posté par . Évalué à  3 .

                    Je m'auto-réponds par ce que j'ai dit une connerie, Reno avait bien raison, il y a enfaite un CPU dans le videocore (qui n'est pas le GPU) et qui sert (juste ?) à exécuter le "vrai" driver.
                    Donc le "faux" driver (user space et kernel) publié par broadcom ne fait que forwarder les appels opengl et autres au CPU du videocore par l'intermédiaire du CPU principal. Le CPU du videocore commande à son tour le GPU.

                    Enfaite toute les infos sont la dedans, mais il faut faire le tri : http://www.raspberrypi.org/archives/2221
                    Les specs du soc BCM2835 ne sont même pas accessible, c'est triste…

  • # Source du noyau

    Posté par (page perso) . Évalué à  8 .

    Ce qui m'intéresse c'est les sources du noyau libre, et l'intégration dans la branche principale. Histoire d'avoir un noyau à jour.

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

  • # Pétard mouillé

    Posté par . Évalué à  10 . Dernière modification : le 24/10/12 à 23:21

    Comme dit sur les commentaires du blog par Luc Verhaegen, sur LWN par Swetland/Glisse/Clark/Bergmann, ou sur son blog par Dave Airlie, ceci est un pétard mouillé. Ce n’est pas un driver OpenGL complet car celui-ci se trouve sur autre cœur, et le code libéré n’a accès qu’à une interface RPC pour appeler le code original.
    La grosse différence avec un firmware "classique" de GPU, c’est qu’ici on ne peut par exemple pas ajouter de nouvelles extensions GLES ou améliorer le compilateur de shaders. On ne peut pas faire grand chose en fait tant l’interface est haut niveau.

    • [^] # Re: Pétard mouillé

      Posté par (page perso) . Évalué à  3 .

      Faudrait mettre à jour la dépêche, la fondation rpi a un peu annoncé n'importe quoi au final…

      • [^] # Re: Pétard mouillé

        Posté par . Évalué à  4 .

        Oui et non car au final tout ce qui tourne sur le cœur Linux est bien libre, non ?

        • [^] # Re: Pétard mouillé

          Posté par . Évalué à  5 .

          Pour certains oui. Ce n’est en tous cas pas le cas de tous les développeurs impliqués dans la pile graphique libre.

          Ce GPU est particulier, et différent de tous les autres dans la mesure où sont "firmware" tourne sur un processeur qui a plus de charge que ce qui se fait habituellement. Habituellement, le firmware s’occupe de taches annexes comme la gestion de l’énergie, ou décharger le CPU de quelques opérations lourdes. Ici, l’intégralité du driver est sur un autre processeur, dans ce qu’on appelle "firmware". Firmware qui contient l’implémentation OpenGLES ou encore le compilateur de shaders (!). Ce dernier est l’un des composant les plus secrets des GPU.

          Et il m’est d’avis que ce n’est pas dû au hasard. Broadcom est un des derniers entrants dans le domaine des SoC, aussi ça ne m’étonnerai pas qu’au moment du design du GPU, ils aient fait ce choix en pensant aux drivers "libres" sous Linux. Ou alors ils voulaient vraiment que le CPU fasse un minimum de choses pour minimiser la consommation, mais j’en doute fort.

          Donc sans accès aux basses couches du GPU, ce driver est fort peu utile vu qu’on ne peut écrire de driver Mesa. Ça veut dire qu’on est tributaire du bon vouloir de Broadcom pour corriger les bugs de l’implémentation, améliorer les performances, rajouter des extensions OpenGL(ES), ou s’assurer que la mémoire mappée par le GPU ne vas écraser notre bon vieux sudo (raisons de sécurité).

          • [^] # Re: Pétard mouillé

            Posté par . Évalué à  5 .

            Vu comment le CPU est sous-dimensionné et que le Rasberry Pi est censé consommer peu (c'était quoi déjà le buzz dessus ? Un ordi qui consomme que 2W ?), l'explication reposant sur l'économie d'énergie me semble plus que plausible.

          • [^] # Re: Pétard mouillé

            Posté par (page perso) . Évalué à  9 .

            Je comprends les arguments et le fait que l'annonce de rpi fait buzz commercial.
            Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
            Oui, il reste un "firmware" fermé et visiblement incontournable, mais c'est déjà le cas pour beaucoup de matériels.

            Je me souviens de l'époque des modems USB Fast800 ADSL : Baud123 avait fait un bon lobbing sur Sagem pour obtenir les source et libérer la partie driver du modem. Ca m'avait changé la vie : certes le firmware chargé sur le modem était toujours fermé et l'API en plus opaque (Baud123 a pesté pas mal dessus), mais sur la partie driver, cela avait permis de corriger beaucoup de choses (notamment des fuites mémoire) et d'obtenir au final un périphérique très utilisable (même très stable chez moi) sous linux… Et le kernel linux restait "propre".

            Pour une carte graphique d'un PC, si je prends l'exemple de mon chipset avec une radeon HD4200, certes il y a un pilote complétement libre (encore que, il y a tout de même un bout de firmware, je ne connais pas sa licence), avec la possibilité pour qui voudrait d'améliorer ce qu'il souhaite… mais au final, les performances de ce pilote libre sont toujours très loin derrière celles du pilote proprio. Il faudrait que cela soit ce dernier qui soit libéré pour être 100% gagnant pour l'utilisateur finale. Donc je ne considère pas que amd fait mieux que broadcom par exemple.
            Je ne lancerais pas de troll avec NVIDIA.

            Le raspberry me semble donc être un des matériels les plus libres qui existent : je ne vous dis pas d'en être un fanatique extrémiste incapable d'aucun esprit critique. Mais avoir constamment l'esprit chagrin et dénigrer les bonnes volontés qui font avancer le shmilblik, ça n'est pas top non plus.

            • [^] # Re: Pétard mouillé

              Posté par (page perso) . Évalué à  3 . Dernière modification : le 25/10/12 à 11:32

              Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
              Oui, il reste un "firmware" fermé et visiblement incontournable, mais c'est déjà le cas pour beaucoup de matériels.

              Tant qu'à faire, au lieu d'écrire que Broadcom avait libéré le pilote, ils auraient pu écrire qu'ils libéraient toute l'informatique.
              Reconnais que ça aurait été un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.

            • [^] # Re: Pétard mouillé

              Posté par (page perso) . Évalué à  3 .

              Le raspberry me semble donc être un des matériels les plus libres qui existent

              Je te conseille d'aller voir le Allwinner A10, qui propulse pas mal d'objets, dont la cle MK802 : Ce A10 m'a tout l'air d’être un bon candidat pour aller loin dans l'open source (C'est la volonté du fabricant, si j'ai bien compris)

              Ya meme une carte qui a un nom sympa.

              • [^] # Re: Pétard mouillé

                Posté par (page perso) . Évalué à  1 .

                Cette plate-forme est attrayante car sensiblement plus puissante que le Raspberry, mais aussi plus cher (tout en restant, je te l'accorde, très abordable).
                Mais en ce qui concerne l'open source, de ce que j'en lis, je crois qu'elle a encore pas mal à prouver.
                (Aucun support du GPU Mali pour Linux, semble plus orientée Android, sans pour autant être officiellement supporté par CyanogenMod…).

                Aller, je ne vais pas voir le verre à moitié vide, mais pour l'instant : à suivre !

                • [^] # Re: Pétard mouillé

                  Posté par . Évalué à  2 .

                  Aucun support du GPU Mali pour Linux

                  Ce n'est pas tout à fait exact. Il y a des drivers officiels ainsi qu'un projet de pilote libre. Enfin, actuellement je suis incapable d'utiliser l'un ou l'autre malheureusement.

              • [^] # Re: Pétard mouillé

                Posté par . Évalué à  2 .

            • [^] # Re: Pétard mouillé

              Posté par (page perso) . Évalué à  4 . Dernière modification : le 27/10/12 à 02:53

              Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.

              c'est ce genre d'attitude qui est déprimante :/

              Je me souviens de l'époque des modems USB Fast800 ADSL : Baud123 avait fait un bon lobbying sur Sagem pour obtenir les source et libérer la partie driver du modem. Ca m'avait changé la vie : certes le firmware chargé sur le modem était toujours fermé et l'API en plus opaque (Baud123 a pesté pas mal dessus), mais sur la partie driver, cela avait permis de corriger beaucoup de choses (notamment des fuites mémoire) et d'obtenir au final un périphérique très utilisable (même très stable chez moi) sous linux… Et le kernel linux restait "propre".

              le souci principal était que le pilote était hors-kernel et le firmware non distribuable (en plus).

              Nous avons finalement résolu le souci de l'inclusion du module (pilote) au kernel une fois réécrit par Damien Bergamini (un dév' BSD) puis repris par Matthieu (oui, 2 t…) pour avoir l'opiniâtreté de l'inclure au noyau, avec l'aval de GKH.
              Je n'ai géré que deux choses entretemps :

              • la continuité du support sur notre forum et la transition vers un module inclus au noyau Linux, gérant un firmware non distribuable à l'époque (du fait de sa licence)
              • des demandes de pouvoir distribuer le firmware sous licence libre et l'obtention de docs sous licence libre (pouvant servir à tout le monde, dont nos amis côté BSD, cela semble légitime d'utiliser son matériel quel que soit son OS pourtant non ?)

              Pour autant, qu'ai-je obtenu ?

              • quelques docs via notre ML, encore disponibles, sans licence claire ("nous souhaitons que tout le monde puisse les utiliser, le domaine public vous conviendrait ?" et en même temps "no redistribution" au bas de chacune… la distinction travail commun entre techniciens qui publient ce qu'ils ont et des juristes qui ont ajouté des bas-de-page restrictifs partout… qui arbitre ?)
              • seulement une distribution claire du firmware de la version 4 sous équivalent BSD http://atm.eagle-usb.org/wakka.php?wiki=NewsFr200611IkanosProvidesEagle4FirmwaresForFree (j'avais demandé au mini une BSD-2 clause sans la licence de publicité, j'avais promu une GPL-2+ pour avoir le code et tenter de corriger le firmware, nous avons aussi regardé un peu de rétro-ingénierie, mais sur 1 Mo de blob, vala quoi… faudrait avoir eu du temps pour le faire, sur notre ML 2 à 3 personnes auraient été en mesure de le faire, sans bug majeur àmha cela ne s'est pas fait… nous avions les outils de décompilation)
              • forcément, les juristes ne sont pas revenus sur les clauses de distribution des firmwares précédents et n'ont géré que la version 4 (mais bon, je peux faire comme ceux de CyanogenMod "nous avons 3 M d'utilisateurs, pourquoi nous attaqueraient-ils ?" cela me dérange pour autant, n'étant pas explicitement libre ni sans risque a posteriori (oui, il y a peu de risque, mais ce n'est pas à moi de l'assumer, cela aurait plutôt été à eux de l'entériner…).

              Pour autant, j'ai une satisfaction, cela date de 2006 mais Red Hat est revenu vers nous ensuite (ou moi en tout cas) pour pérenniser la situation au travers des firmwares non libres hébergés sur kernel.org (heureusement que debian avait promu kernel-firmware comme module permettant de charger du non-libre, tant qu'il est au bon emplacement, pour un module permettant d'accéder au net et demandant un firmware dispo par internet vu que non distribué, le problème de la poule et de l'œuf m'est souvent apparu… bah suffit d'une clé USB :p ou prendre le risque de le mettre à dispo, forcément c'est dur d'assumer la position des fabricants et des distributeurs que ce n'est pas que de leur faute, si un peu quand même).

              Parce que bon concrètement :

              • fast 800, fast 800 E1, E2, E3 : pas de firmware distribuable (je le fais quand même, faut pas déconner, faut bien qu'il soit disponible quelque part, d'ailleurs je ne sais pas si sagem continue…)
              • fast 800 E4 (uniquement utilisé par wanadoo, même free avait déjà commencé à distribuer sa box à cette époque) avec un firmware non-libre distribué sous BSD (sans le source, la BSD ne l'imposant pas, ce pourquoi je préfère la BSD pour de l'interprété ou du code source déjà distribué ; pour un binaire vala quoi, la BSD n'impose pas de fournir la source préférée d'édition utilisée pour générer le code indispensable/utile… ça peut suffire à certains)
              • depuis les modems usb sont morts et heureusement, remplacés par de l'ethernet, je ne sais pas si nous y avons gagné avec les box (considérées comme faisant partie du réseau interne par Free, moui, je ne suis pas convaincu, elle est tout de même chez moi, comment s'applique HADOPI ? à raison, je considère Free^WIlliad responsable par défaut dans ce cas… pour non fourniture des moyens me permettant de sécuriser ma connexion, ah bah oui, autrement c'est la FSF-France qui gagne son procès de non distribution du code de la Freebox dans les 3 ans impartis, à eux de choisir…). Je vous laisse relire 4 ou 5 fois les lignes précédentes (le niveau d'information est un peu dense, je puis répondre aux questions précises, ayant tout l'historique de l'époque même si je n'ai pas tout le contexte).

                Bref, oui, j'aime promouvoir le openhardware mais pour autant ai-je envie de le supporter au vu de l'hypocrisie criante du monde android même cyanogenmod ? Ils ne respectent pas le libre, en font fi (nous avons 3M d'utilisateurs pourquoi cela serait un problème de distribuer du non-libre ?). Si personne ne s'en inquiète, bin ce n'est pas mon problème, moi non plus je n'ai pas envie de m'impliquer (je pourrais pourtant faire deux-trois choses, mais là je n'ai pas envie, ce n'est pas mon combat si tout le monde s'en fout et que ça n'intéresse personne, pour autant ça me semble dommageable et ça me désespère, mais je ne ferai rien seul et vu que je ne vois pas les choses changer… malgré l'espoir que m'avait donné Open Silicium, qui pourrait renaître àmha).

              bref
              Quand je te vois écrire

              Le raspberry me semble donc être un des matériels les plus libres qui existent

              c'est une négation de la démarche que j'ai pu avoir, à quoi servait elle ? à qui aurait-elle pu servir ?

              ok, à personne, j'ai perdu mon temps, dommage tant pour toi, que pour moi et ça ça fait chier. Surtout pour toi, moi j'y ai appris 2-3 choses au passage (mais c'est justement cette partie que j'aurai du mal à faire comprendre dans la durée et qui m'embête le plus finalement :/ Je sais par les échanges IRL que j'ai que c'est intéressant, mais qui est en mesure de le comprendre effectivement dans d'autres domaines ?).

            • [^] # Re: Pétard mouillé

              Posté par (page perso) . Évalué à  3 .

              (encore que, il y a tout de même un bout de firmware, je ne connais pas sa licence)

              Le plus simple pour savoir ça, c'est d'installer une distro blob-free, et de regarder si tout fonctionne aussi bien. Moi j'installe debian, et je regarde la différence avant et après avoir installé firmware-linux-nonfree.

              Pour info, la quasi-totalité (et peut-être même la totalité ?) des firmwares AMD sont non-libres. Il suffit d'un aptitude show firmware-linux-nonfree | grep radeon pour s'en rendre compte (ou de regarder sur git.kernel.org).

              Mais visiblement, ce ne sont que les cartes graphiques qui sont listées. J'ai vu des IGP qui nécessitaient un firmware proprio pour fonctionner (c'est le cas du 740G/Radeon 2100, je suppose que c'est pareil pour tous ceux pour lesquels il est écrit "Public documentation is not available yet" ici.), d'autres qui pouvaient fonctionner sans firmware (c'est le cas du 880G/Radeon HD 4250).

              Et d'après ce que je lis, des Radeon HD 4200 il y en a deux. Un qui est basé sur 785G et un qui est basé sur 785E. Notons que le 785G a le même nom de code que 880G (RS880), est-ce qu'on peut en déduire quelque chose concernant le firmware ou ça n'a aucun rapport ?

              En passant si quelqu'un connaît un site listant tous les GPU AMD connus, en précisant si ceux-ci nécessitent un firmware pour fonctionner, si le firmware est proprio ou non, et si les specs sont dispos ou non, qu'il n'hésite pas à partager l'info.

              • [^] # Re: Pétard mouillé

                Posté par (page perso) . Évalué à  3 . Dernière modification : le 28/10/12 à 16:08

                La doc est souvent ancienne sur le wiki freedesktop/gallium
                Ici celle fournie par AMD http://www.x.org/docs/AMD/ (rien depuis le 11-Jun-2010)
                Et puis ils ont tendance à cacher ce qui est pas supporté
                par ex ici tu remarqueras que les radeon gèrent très bien la fréquence et le ventilo, et il est bien connu qu'elles ne chauffent pas avec le pilote libre http://www.x.org/wiki/RadeonFeature (Power Saving)
                Là les softs qui marchent ou pas http://www.x.org/wiki/RadeonProgram
                Aucune mention des firmwares vu que pour les devs du pilote libre radeon ce n'est pas un pb (ça a été dit plusieurs fois en commentaire dans le forum de phoronix)

                Pitet que tu trouveras des infos ici http://en.gentoo-wiki.com/wiki/Radeon http://wiki.debian.org/AtiHowTo http://www.x.org/wiki/radeonBuildHowTo (All radeon gfxcards r600+ (r600 and higher) require extra firmware (ucode) files to work properly with acceleration)

              • [^] # Re: Pétard mouillé

                Posté par (page perso) . Évalué à  0 .

                Sinon j'ai regardé le paquet firmware-linux-nonfree fourni par Debian :
                /lib/firmware/r128
                /lib/firmware/r128/r128_cce.bin
                /lib/firmware/radeon
                /lib/firmware/radeon/BARTS_mc.bin
                /lib/firmware/radeon/BARTS_me.bin
                /lib/firmware/radeon/BARTS_pfp.bin
                /lib/firmware/radeon/BTC_rlc.bin
                /lib/firmware/radeon/CAICOS_mc.bin
                /lib/firmware/radeon/CAICOS_me.bin
                /lib/firmware/radeon/CAICOS_pfp.bin
                /lib/firmware/radeon/CAYMAN_mc.bin
                /lib/firmware/radeon/CAYMAN_me.bin
                /lib/firmware/radeon/CAYMAN_pfp.bin
                /lib/firmware/radeon/CAYMAN_rlc.bin
                /lib/firmware/radeon/CEDAR_me.bin
                /lib/firmware/radeon/CEDAR_pfp.bin
                /lib/firmware/radeon/CEDAR_rlc.bin
                /lib/firmware/radeon/CYPRESS_me.bin
                /lib/firmware/radeon/CYPRESS_pfp.bin
                /lib/firmware/radeon/CYPRESS_rlc.bin
                /lib/firmware/radeon/JUNIPER_me.bin
                /lib/firmware/radeon/JUNIPER_pfp.bin
                /lib/firmware/radeon/JUNIPER_rlc.bin
                /lib/firmware/radeon/PALM_me.bin
                /lib/firmware/radeon/PALM_pfp.bin
                /lib/firmware/radeon/R100_cp.bin
                /lib/firmware/radeon/R200_cp.bin
                /lib/firmware/radeon/R300_cp.bin
                /lib/firmware/radeon/R420_cp.bin
                /lib/firmware/radeon/R520_cp.bin
                /lib/firmware/radeon/R600_me.bin
                /lib/firmware/radeon/R600_pfp.bin
                /lib/firmware/radeon/R600_rlc.bin
                /lib/firmware/radeon/R700_rlc.bin
                /lib/firmware/radeon/REDWOOD_me.bin
                /lib/firmware/radeon/REDWOOD_pfp.bin
                /lib/firmware/radeon/REDWOOD_rlc.bin
                /lib/firmware/radeon/RS600_cp.bin
                /lib/firmware/radeon/RS690_cp.bin
                /lib/firmware/radeon/RS780_me.bin
                /lib/firmware/radeon/RS780_pfp.bin
                /lib/firmware/radeon/RV610_me.bin
                /lib/firmware/radeon/RV610_pfp.bin
                /lib/firmware/radeon/RV620_me.bin
                /lib/firmware/radeon/RV620_pfp.bin
                /lib/firmware/radeon/RV630_me.bin
                /lib/firmware/radeon/RV630_pfp.bin
                /lib/firmware/radeon/RV635_me.bin
                /lib/firmware/radeon/RV635_pfp.bin
                /lib/firmware/radeon/RV670_me.bin
                /lib/firmware/radeon/RV670_pfp.bin
                /lib/firmware/radeon/RV710_me.bin
                /lib/firmware/radeon/RV710_pfp.bin
                /lib/firmware/radeon/RV730_me.bin
                /lib/firmware/radeon/RV730_pfp.bin
                /lib/firmware/radeon/RV770_me.bin
                /lib/firmware/radeon/RV770_pfp.bin
                /lib/firmware/radeon/SUMO2_me.bin
                /lib/firmware/radeon/SUMO2_pfp.bin
                /lib/firmware/radeon/SUMO_me.bin
                /lib/firmware/radeon/SUMO_pfp.bin
                /lib/firmware/radeon/SUMO_rlc.bin
                /lib/firmware/radeon/TURKS_mc.bin
                /lib/firmware/radeon/TURKS_me.bin
                /lib/firmware/radeon/TURKS_pfp.bin

      • [^] # Re: Pétard mouillé

        Posté par (page perso) . Évalué à  5 .

        Fait.

        • [^] # Re: Pétard mouillé

          Posté par (page perso) . Évalué à  10 .

          Oh my god, le fou rire que j'ai eu en lisant l'article de Phoronix ! J'en ai recraché mon ricoré sur l'écran du portable.
          Franchement il n'a pas honte Michael Larabel. Il copie/colle un paragraphe du post de Dave Airlie mais il prend bien soin de s'arrêter à un endroit stratégique.
          Version originale (je graisse le passage):

          So really Rasberry Pi and Broadcom - get a big FAIL for even bothering to make a press release for this, if they'd just stuck the code out there and gone on with things it would have been fine, nobody would have been any happier, but some idiot thought this crappy shim layer deserved a press release, pointless. (and really phoronix, you suck even more than usual at journalism).

          Version copiée/collée sur Phoronix :

          So really Rasberry Pi and Broadcom - get a big FAIL for even bothering to make a press release for this, if they'd just stuck the code out there and gone on with things it would have been fine, nobody would have been any happier, but some idiot thought this crappy shim layer deserved a press release, pointless.

          • [^] # Re: Pétard mouillé

            Posté par (page perso) . Évalué à  6 .

            Il y a un certain nombre de développeurs dans la pile X.org qui détestent Phoronix et le font savoir. Dave Airlie fait partie d'eux. C'est loin d'être la personne la plus objective à propos de Phoronix.
            Phoronix est un des seuls sites "grand public" à communiquer sur ce qui se passe dans le monde de X, parfois avec des approximations et souvent avec des titres racoleurs, mais je considère que c'est plutôt un bien (et d'autres développeurs de la pile sont d'accord, ils sont juste moins bruyants).

            Attention à ne pas taper sur Phoronix bêtement.

            • [^] # Re: Pétard mouillé

              Posté par (page perso) . Évalué à  3 .

              Moi je suis assidûment Phoronix, le site n'a pas vraiment d'équivalent pour savoir ce qui se passe en cuisine

            • [^] # Re: Pétard mouillé

              Posté par (page perso) . Évalué à  9 .

              Je lis LWN et je suis abonné aux posts d'un paquet de devs Linux dans Google+.
              Chaque fois que j'ai vu Phoronix mentionné c'était pour critiquer la qualité des articles. Je n'ai jamais vu une louange de la part d'un dev Linux.

              Si on ajoute :
              - Le saucissonage démentiel des articles (pour avoir plus de clics)
              - L'ajout effréné de liens internes au détriment des liens externes pertinents (toujours pour avoir plus de clics)
              - La quantité de pubs invasives
              - Les benchmarks absurdes qui ne mesurent rien
              - L'embargo sur certains bugs "afin de maximiser les profits"

              Je crois qu'on peut dire que Phoronix est un site déplorable.

              • [^] # Re: Pétard mouillé

                Posté par (page perso) . Évalué à  2 .

                L'embargo sur certains bugs "afin de maximiser les profits"

                Je n'ai pas compris ?

                • [^] # Re: Pétard mouillé

                  Posté par (page perso) . Évalué à  6 . Dernière modification : le 25/10/12 à 14:58

                  A un moment il y a eu une régression du noyau sur la consommation d'énergie. Une nouvelle version consommait plus de courant que les précédentes.
                  Phoronix a publié des tonnes d'articles en exploitant l'affaire jusqu'au trognon. Il annonçait qu'il allait bissecter le problème. Puis il annonçait que c'était en cours. Puis un autre article pour dire que le problème était en bonne voie de compréhension grâce à son super produit Phoronix Bench suite. Etc etc.

                  Et enfin un article avec la phrase suivante : "I think I may have tracked down and will announce then in a couple of days. So, yes, I'll just put out the findings when it's to my maximum ad-revenue advantage."

              • [^] # Re: Pétard mouillé

                Posté par . Évalué à  1 .

                Je suis d'accord avec ton constat, mais sans suivre la LWN, existe t'il une autre alternative plus "fiable" ?

                ArsTechnica est tombé de le panneau les deux pieds en avant.

                H-Online attire le lecteur avec un titre racoleur, ensuite l'article est de meilleur qualité et nous parle du firmware "closed source", mais bon.

                Je suis toujours à la recherche d'un site dans la veine de Phoronix, mais sans les saucisses, existe-t'il ?

              • [^] # Re: Pétard mouillé

                Posté par (page perso) . Évalué à  2 .

                Tu as tort. C'est le seul site à faire des benchmarks, et certains sont pertinents. Pas tous, mais au moins ils ont le mérite d'exister.
                De plus, tu vois effectivement certains développeurs (pas les moins connus, et précisément parce qu'ils ont une grande gueule) se plaindre de Phoronix. Ce n'est pas le cas de tous. Aujourd'hui si on a des enregistrements de à peu près 100% des conférences relatives à X.org, c'est grâce à Phoronix, nonobstant la qualité des enregistrements ils ont le mérite d'exister.

                C'est un peu facile de taper sur Phoronix, surtout qu'ils rendent des services que d'autres ne rendent pas. Ce sur quoi les gens comme Airlie tapent, c'est le simple fait de communiquer et de vulgariser. (Tu remarqueras qu'Airlie déteste le monde entier à part son propre employeur.)

                Pour avoir porté à bouts de bras le "TiNDC" (nouvelles du développement sur Nouveau) pendant un long moment, je peux te dire que la communication n'est pas dans la culture des développeurs de X. Toi plus que d'autres devrait comprendre que c'est dommage.

              • [^] # Re: Pétard mouillé

                Posté par . Évalué à  3 .

                Je crois qu'on peut dire que Phoronix est un site déplorable.

                Déplorable tu exagères..
                Tout ce que tu dis est vrai mais il a quand même parfois des infos que d'autres non pas (par exemple des liens a des blogs que je ne connaissais).
                Et parfois dans le forum il y a des développeurs qui interviennent (ça en fait un des forums les plus bizarre que je connaisse: rempli de trolleur qui n'y connaissent rien et critiquent tout mais avec de temps en temps des développeurs qui interviennent!).

                Il y a plein de site avec des bizarrerie, des biais, il faut le savoir et filtrer, mais de la a déplorer qu'ils existent, non.

              • [^] # Re: Pétard mouillé

                Posté par (page perso) . Évalué à  2 .

                Je crois qu'on peut dire que Phoronix est un site déplorable.

                En tout cas ils ont leur job en l'espèce :

                • Un article pour relayer l'info du blogue du RPi
                • Un autre article pour relayer les critiques.

                Information complète, donc.

        • [^] # Re: Pétard mouillé

          Posté par (page perso) . Évalué à  3 .

          Tu peux même reprendre l'affirmation de Dave Airlie : ça ne permet pas l'écriture d'un pilote Mesa/Gallium.
          (contrairement à ce qui est écrit dans la dépêche)

  • # UTF-8

    Posté par . Évalué à  4 .

    Bien joué le petit caractère UTF-8 (✓) dans le lien de la recherche. Je n'avais encore jamais remarqué…

  • # Ils feraient mieux de libérer les commandes ...

    Posté par (page perso) . Évalué à  1 .

    car 3 mois que j'ai reçu le mail de confirmation comme quoi ma commande serait traitée et je n'ai toujours pas reçu le produit … sympa.
    Quelqu'un est-il dans le même cas ?

    • [^] # Re: Ils feraient mieux de libérer les commandes ...

      Posté par . Évalué à  4 .

      Ca dépend du fournisseur chez qui tu as commandé il semblerait, chez Farnell ça va assez vite, mais chez RS Components c'est beaucoup plus lent (peut-être la faute aux accessoires qu'ils vendent avec?)

Suivre le flux des commentaires

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