Journal Ayé, de nouveaux pilotes pour carte ATI sont sortis !!! \o/

Posté par  (site web personnel) .
Étiquettes :
18
6
avr.
2010
La version 6.13 vient donc de sortir.

Pour connaître la liste des changements, vous pouvez lire l'annonce ici : http://lists.freedesktop.org/archives/xorg-announce/2010-Apr(...)

En gros, il y a l'ajout du support KMS(kernel mode-setting) pour tous les chips radeon, du r1xx(ati 7500) aux derniers evergreen(R800) des dernières radeon HD 5xxx.
Le contraste, la luminosité, la teinte et autres bonnes choses sont inclus directement dans Xv en mode textured video (mode que j'utilise pour avoir les vidéos même lorsque je tourne mon cube compiz)
Un support initial pour les chip evergreen en UMS (user-space mode-setting, le mode classique quoi comparé au nouveau KMS qui arrive avec les nouveaux noyaux)
De nouvelles options d'économie d'énergie ainsi que l'utilisation du DisplayPort toujours en UMS.
Des corrections sur le mode Zaphod (pour l'affichage sur plusieurs écrans)
Ainsi que les classiques corrections de bug comme la sortie TV en PAL pour les anciennes cartes qui avait aussi été reportée sur la branche 6.12 il y a un mois.


Comme d'hab un petit rappel de la page des fonctionnalités de ces pilotes :
http://www.x.org/wiki/RadeonFeature
La page pour les télécharger si vous ne pouvez attendre la sortie dans votre distribution :
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati
Pour tirer partie de toutes ces nouveautés il faudra surement le dernier noyau (2.6.33 voir le 2.6.34-rc3) et Mesa (7.8.1)

Merci AMD, Red-Hat et toute la communauté de développeurs pour cette nouvelle monture, mes ati x300 et 9200 vous remercient !!! C'est ça que j'adore avec le libre, le support des anciens matériels se fait toujours et j'ai de plus en plus de fonctionnalités sur mes carte (que je n'avais à l'époque avec les pilotes proprios)

  • # Ooops j'ai oublié ma source.

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

    http://www.phoronix.com/scan.php?page=news_item&px=ODEyN(...)

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

  • # Déjà dans Debian !

    Posté par  . Évalué à 1.

    C'est marrant je regardais justement où ils en étaient sur cette page : http://www.x.org/wiki/radeon (pas encore mise à jour d'ailleurs).

    Et comme le dit le titre, c'est dans Debian... Experimental !
    Je pense que je vais rapidement tester tout ça :)

    Merci aux devs, ça fait plaisir d'être de moins en moins dépendant de pilotes proprios !

    • [^] # Re: Déjà dans Debian !

      Posté par  . Évalué à 1.

      La feature matrix est à jour, au moins pour les r600,r700 et r800. Je en suis que de très loin les développement pour les r100-500.

      Si ce qui te fais dire qu'elle n'est pas à jour, ce sont le nombreuses cases MOSTLY, c'est juste que tant qu'une fonctionnalité n'est pas considérée comme complétement stable (ie non sujette à un changement dans un avenir plus ou moins proche) elle n'est pas marqué comme DONE.

  • # Evergreen

    Posté par  . Évalué à 3.

    Quelqu'un a déjà testé ces drivers sur une HD 5xxx ?
    Aujourd'hui sur ma 4850 la 3d marche bien (au moins pour les effets de kwin), et ça m'embêterait de me retrouver avec un affichage plus lent si je passais sur une 5850.

    • [^] # r600

      Posté par  . Évalué à 1.

      Les devs s'efforçent de faire marcher tout le bouzin pour un chip antérieur mais fonctionnel avec ta 4850 ... s itu passes sous evergreen attends toi encore à moins de support.

      envoyé depuis mon clavier bépo

    • [^] # Re: Evergreen

      Posté par  . Évalué à 2.

      Oui moi j'ai teste
      C'est aussi lent qu'avec le driver vesa sauf que la resolution de l'ecran est correctement detectee.
      Bon le driver n'a que quelques mois, laissons le murir un peul, avec un peu de chance il pourra remplacer fglrx pour une utilisation bureautique dans 6 mois.

      • [^] # Re: Evergreen

        Posté par  . Évalué à 1.

        Merci du retour.
        Même si j'ai pas encore l'intention de changer de CG, le plus simple pour moi serait encore une CM avec deux ports PCIe :)

  • # radeon VS radeonhd

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

    De mémoire, radeon (évoqué dans ce journal) est le driver libre historique basé sur du reverse.
    De son coté radeonHD est le résultat de la libération de certaines spec par ATI qui ont permis à Novell/Suse de développer un driver libre pour les cartes récentes.

    Par contre j'ai du mal à trouver des infos sur un merge possible des 2 drivers. Sont ils trop différents pour espérer un mix ?
    Se cantonnent ils chacun à leur gammes de cartes (vieilles / nouvelles) ?

    • [^] # Re: radeon VS radeonhd

      Posté par  . Évalué à 4.

      De mémoire, RadeonHD avait notamment été créé pour prendre en charge des cartes récentes, ce que ne faisait pas le pilote Radeon à l'époque. Radeon aussi a profité des spécifications d'AMD. Or, aujourd'hui, Radeon a largement rattrapé son retard sur ce point puisque la 3D, certes expérimentale, semble active jusqu'aux HD4xxx et que la HD5xxxx fonctionne sans accélération.

      De fait, on peut se demander l'intérêt actuel du pilote RadeonHD, qui semble évoluer moins vite, notamment, il me semble, parce qu'ils ne voulaient pas utiliser l'AtomBIOS [voir http://www.phoronix.com/scan.php?page=article&item=radeo(...)], ce qui n'est plus le cas aujourd'hui. Si quelqu'un pouvait éclairer ce point :)

    • [^] # Re: radeon VS radeonhd

      Posté par  . Évalué à 3.

      L'origine du "désaccord" entre les 2 équipe était plutôt au niveau du firmware de la carte. radeon utilisatait un blob binaire, ce qui permettait de supporter (au moins de manière basique) les nouvelles cartes dès leur sortie (à condition bien sûr d'ajouter les ID dans la base mais ça n'a jamais été long) alors que les partisans de radeonhd cherchaient à avoir aussi le firmware libre ce qui impliquait un délai plus important pour le support des nouvelles cartes.

      Ajourd'hui, ces différents ont été effacés et les nouvelles fritures sont développées en une seule fois comme on peut le lire sur le wiki du pilote radeon.
      The reasons for two different drivers are historical, and starting to be a thing of the past as all the new DRM (direct rendering manager), 3D and KMS (kernel mode setting) work is done in a single place. radeonhd driver will be continued to be developed as long as it is useful.

      • [^] # Re: radeon VS radeonhd

        Posté par  . Évalué à 9.

        Petite precision c'est n'est pas vraiment un firmware c'est un language de script simplifie (atombios) dont ont connait le format. On peut donc regarder les sources et ca nous arrive de le faire. Par ailleurs le driver windows utilise aussi l'atombios ce qui fait qu'on est sur que c'est un code teste et qui marche. Le code de modesetting de l'atombios n'est pas tres interessants (rien de bien nouveau dans ces parties du gpu) mais c'est un code particulierement sensible car il doit prendre en compte plein de parametres comme le type de memoire utilise par le constructeur, leur vitesse, et une tripote d'autre trucs propre a chaque constructeurs. Il est donc plus simple d'utiliser atombios qui est customise par les constructeurs pour coller a leur materiel.

        • [^] # Re: radeon VS radeonhd

          Posté par  . Évalué à 2.

          Merci Jérôme pour ces précisions.

          Je pensais effectivement à AtomBIOS mais, visiblement, je me fourvoyais sur les détails techniques de l'élément en question.

          On en apprend tous les jours.

          (Et accessoirement, ma signature vient d'exploser en vol.)

    • [^] # Re: radeon VS radeonhd

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

      De mémoire, radeonHD était développé par novel, mais le développeur principal de ce pilote a été licencié par Novel (crise cf mon vieux journal http://linuxfr.org/~esver/27986.html )

      Et le pilote radeon a comme principaux contributeurs des employés d'AMD et de RedHat.

      Donc si t'as une radeon HD tu peux tester les 2 pilotes mais je penses que maintenant le pilote radeon a rattrapé, voir dépassé le pilote radeonHD en terme de support et de fonctionnalités. si tu regardes ici : http://www.x.org/wiki/radeonhd%3Afeature tu verras que les dernières cartes evergreen ne sont pas supportées par le pilote radeonHD.

      S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

  • # pas seulement DDX

    Posté par  . Évalué à 8.

    Je pense que c'est davantage le trio drm/xf86-ati/mesa qui correspond à l'avènement des pilotes libres ati.
    La véritable release KMS correspond en effet à la partie DDX en 6.13 (l'objet de ce journal), drm (ou dri2) livré avec le noyau 2.6.32 mais pleinement fonctionnel ds la release 2.6.33 (apparition du teardropping et gestion IRQ correcte), les 2.6.34-rc* incluent une gestion de l'énergie du GPU ati qui est au poil (fini les cycles trop longs de ventilation sur mon laptop).
    Intimement lié à ce projet, mesa 7.7.1 (voir 7.8) pour une accélération 3D naissante mais loin d'être opérationnel pour les jeux ... au moins pour mon chip relativement récent, puisqu'il s'agit d'un RV710 (radeon 4300 series, géré par le pilote r600, carte carrément low-end néanmoins capable de faire tourner street fighter 4 sous l'OS de redmond)
    Depuis mesa 7.7 openGL est livré en version 2.0 et permet entre autre d'exploiter les shaders sous Xonotic (dernière fonctionnalité notable que j'ai pu constater), le compositing (qui fait appel à mesa) marche à merveille, la stabilité est exceptionnelle sur ma debian testing avec Xorg 1.7.5 et ce trio gagnant.
    Faute d'optimisation les performances 3D sont cependant en retrait par rapport à l'user mode setting et fglrx reste le passage obligé si vous désirez jouer (cf ce bench : http://www.phoronix.com/scan.php?page=article&item=ubunt(...)

    Il faut c'est vrai applaudir l'initiative, les GPU ATI ont tellement plus de potentiel que ceux d'intel.
    Je serai prêt à pardonner à certain jeux d'être non libres si mon GPU est gérée pleinement par du code GPL.
    On me sussure à l'oreille que la gestion openGL 2.1 apparaîtrait avec un gallium, ce dernier est embryonnaire pour les matériels r600, r700, r800 (mais existe bel et bien pour les cartes ati plus anciennes).
    Un certain jérome Glisse a déja commité un peu de code et son blog laisse présager de bonne chose.
    A noter que ce dev, présent au fosdem 2010 nous fait part de ces slides http://people.freedesktop.org/~glisse/glisse-fosdem2010.pdf
    Une communauté prolifique, prosélyte ainsi que des developpeurs sont sur le canal #radeon sur irc.freenode.net

    envoyé depuis mon clavier bépo

    • [^] # Re: pas seulement DDX

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

      A noter que ce dev, présent au fosdem 2010 nous fait part de ces slides http://people.freedesktop.org/~glisse/glisse-fosdem2010.pdf

      oui c'était dans la salle X.Org qui était pleine à craquer
      http://fosdem.org/2010/schedule/events/xorg_gpu_userspace

      Si quelqu'un a un peu plus d'explications, j'ai trouvé cette présentation dense et j'ai eu assez de mal à suivre (ou c'était la chaleur je ne sais pas). En tout cas, cela explique les mécanismes de bas niveau, je devais m'attendre à quelque chose de niveau userland :-)

    • [^] # Re: pas seulement DDX

      Posté par  . Évalué à 5.

      Pour améliorer de beaucoup les performances avec le pilote libre, si tu es en Europe ou tout autre pays qui ne reconnaît pas les brevets logiciels, tu peux activer les dépôts debian-multimedia et ajouter le paquet libtxc-dxtn0 qui permet d'utiliser des textures compressées (décompression en hard par la puce graphique, donc extrèmement rapide, compression assez rapide par le CPU (algo simple), mais surtout gain énorme d'entrées/sorties vers la puce graphique ! )

      Chez moi avec un chipset intégré Radeon HD3300 ça m'a permis de passer d'un supertux (bleeding edge) très lent à un jeu tout juste jouable, tout le reste de la configuration étant identique par ailleurs. Notons que j'utilise le kernel modesetting.

Suivre le flux des commentaires

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