Journal ATI 1, nVidia 0...

Posté par  .
Étiquettes : aucune
0
28
juil.
2006
Salut les gens

C'est rare, donc faut le noter. Les pilotes ATI viennent de doubler les pilotes nVidia sur un point : le support de X.org 7.1.
En effet, aujourd'hui sont sortis les pilotes ATI 8.27.10 :
- support de X.org 7.1
- possibilité de générer des paquets Fedora
Et bien entendu les corrections de bug habituelles.
Plus d'informations :
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/(...)

Téléchargement : https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/(...)

On attend la réaction de nVidia...

  • # paquets Fedora...

    Posté par  . Évalué à -10.

    ... qui ne seront pas intégrés à la distribution.

    C'est bien gentil, mais j'aimerais avoir une distrib qui tourne out-of-the-box sans devoir activer et installer le mp3, le DVD, le driver video, le flash, le PDF , java, etc...

    • [^] # Re: paquets Fedora...

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

      PDF est supporté nativement.

      Ensuite je ne connais aucun OS proposant nativement flash/dvd/java/etc.

      • [^] # Re: paquets Fedora...

        Posté par  . Évalué à -10.

        C'est une excellente raison pour continuer de ne pas respecter l'objectif que tout système est censé se fixer : être au service de l'utilisateur de la meilleure façon possible.

        Puisque personne ne le fait, ne le faisons pas!

      • [^] # Re: paquets Fedora...

        Posté par  . Évalué à 3.

        je ne connais aucun OS proposant nativement /../java /.../


        opensolaris peut-être ? ;)


        ------------------->[ ] (à la vitesse des rayons solaires)

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: paquets Fedora...

        Posté par  . Évalué à 3.

        Ensuite je ne connais aucun OS proposant nativement flash/dvd/java/etc.

        Mac OS X, peut-être? Bon, autant pour java et DVD, je suis certain, j'ai quelques doutes pour Flash. Mais aucun souvenir de l'avoir installé moi-même non plus.

        Bon, après, c'est pas ce qui se fait de libre. Mais au moins, c'est inclus.

    • [^] # Re: paquets Fedora...

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

      bah, question de licence : Les distributerus (Linux) n'ont simplement pas le droit.
      Exception: RedHat (pas Fedora) qui a des accords avec SUN et adobe rien que pour toi (sont gentil hein..), mais du coup faut payer RedHat pour avoir up2date.

      Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie

    • [^] # Re: paquets Fedora...

      Posté par  . Évalué à 3.

      Linspire, peut-etre ?

    • [^] # Re: paquets Fedora...

      Posté par  . Évalué à -2.

      Utilise la distribution WINDOWS XP.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: paquets Fedora...

        Posté par  . Évalué à 3.

        tu veux dire que slack , lors d'une install normal t'installe le sdk de sun et le plugin flash?

        Pour les pdf c'est surtout acroread dont il voulait parler.
        Sinon y a xpdf qui marche tres bien

      • [^] # Re: paquets Fedora...

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

        Une distrib qui bourre le flash par défaut ?? mon dieu quelle horreur. Pas pour moi merci...

      • [^] # Re: paquets Fedora...

        Posté par  . Évalué à 4.

        Effectivement sous Slack on peut lire les MP3 et les PDF out of the box (les PDF avec xpdf ou le fabuleux kpdf, hein, pas cette bouse d'Acrobat Reader®), il y a le JRE de base et le JDK dans extra/, mais je n'ai jamais eu le plugin Flash préinstallé.

        D'ailleurs j'en suis bien aise, ça m'évite d'avoir à filtrer les immondes réclames en flash qui défigurent certaines pages web.

        • [^] # Re: paquets Fedora...

          Posté par  . Évalué à 2.

          perdu il y a acroread aussi :)

          • [^] # Re: paquets Fedora...

            Posté par  . Évalué à 2.

            Et c'est le seul qui puisse lire les documents en ligne fournis par les Addedics (confirmation de situation mensuelle, liste des versements effectués, ...).
            J'ai bien sur envoyé un mail pour leur signaler et tout ce que j'ai reçu c'est une réponse automatique me proposant de télécharger Acrobat Reader sous Windows :-(

  • # Lien bizarre

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

    Ton lien fait un peu penser à du spam, pourquoi ne pas avoir mis simplement http://www2.ati.com/drivers/linux/linux_8.27.10.html (et idem pour le 2eme) ?

    WeeChat, the extensible chat client

    • [^] # Re: Lien bizarre

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

      En quoi ca fait penser à du spam ?
      Akamai ca doit être l'un des plus gros groupes de proxys cache, tu risques de les vexer en disant ça

      • [^] # Re: Lien bizarre

        Posté par  (site web personnel, Mastodon) . Évalué à 8.

        Etre un gros groupe ne veut rien dire du tout ;-)
        Tant que je ne sais pas ce qu'ils font des infos récoltées par les clics sur ces liens, je ne peux pas dire que c'est un "bon lien" ou pas.

        Le lien en lui même ressemble fort à ceux que je reçois dans mes spams, ceux qui sont là pour voir si tu as effectivement reçu/lu le mail.

        WeeChat, the extensible chat client

    • [^] # Re: Lien bizarre

      Posté par  . Évalué à 6.

      Ha... Ben désolé, c'est le flux RSS d'ATI qui m'a pondu ça.
      Et le deuxième lien, c'est le site d'ATI qui me l'a sorti.

  • # Rachat ?

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

    Histoire d'apporter une information connexe, j'ai entendu il y a une paire de jours à la radio que le fondeur AMD lorgne sur ATI et a lancé une O.P.A. ( Sources : http://www.google.fr/search?q=amd+opa+ati ).

    Peut-on espérer un changement du status des sources des pilotes vidéo ? On se prend à réver que l'implication d'AMD dans le developpement noyau Linux amène l'entreprise à libérer son code... L'avantage concurentiel sur Nvidia serait non négligeable, et pousserait peut-être ce dernier à suivre son concurrent, qu'en pensez-vous ?

    Une des sources : http://permanent.nouvelobs.com/multimedia/20060724.OBS6136.h(...)

  • # re

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

    Pourquoi il marche pas les pilotes Nvidia sous xorg 7.1 ?

    • [^] # Re: re

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

      Parce que l'API a changée (faut pas chercher compliquer hein)

    • [^] # Re: re

      Posté par  . Évalué à 4.

      L'ABI a changé, et les pilotes nVidia actuels utilisent encore l'ancienne ABI. Il est donc nécessaire d'ajouter un flag au lancement de X pour ignorer ce problème.
      De plus, pour fonctionner correctement sur X.org 7.1, il faut désactiver l'accélération de XRender dans les pilotes nVidia, sinon plus de polices... Pratique non ?

      • [^] # Re: re

        Posté par  . Évalué à 4.

        API, ABI ? et pourquoi pas ALI ?
        Vous êtes à côté de la plaque, ici on parle d'ATI.

        --->[] vous ne m'avez même pas vu

      • [^] # Re: re

        Posté par  . Évalué à 2.

        Tiens donc, et quel est ce flag ?

        premiere fois que j'en entend parler, et ca m'interesse grandement :)

        • [^] # Re: re

          Posté par  . Évalué à 2.

          Facile, c'est -ignoreABI...

      • [^] # Re: re Question

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

        Comment on fait pour désactiver l'accélération XRender et qu'elles en sont les conséquences à l'utilisation ?

        • [^] # Re: re Question

          Posté par  . Évalué à 2.

          Dans la section device correspondant à ta carte nVidia dans le xorg.conf :
          Option "RenderAccel" "off"

          Les conséquences dépendent de ton environnement. Si tu utilises des applis abusant de XRender (exemple : un composite manager dérivé de xcompmgr, comme kompmgr, fourni avec KDE) elles seront très lentes (ces applis sont tout de même rares).
          Par contre, un truc plus fréquent c'est pour le rendu des polices et l'anti aliasing. Tu risques de perdre en vitesse de rendu, de manière plus ou moins importante.

          Mais ça reste du cas par cas, ça dépend des réglages...

  • # Et la stabilité ?

    Posté par  . Évalué à 3.

    Il ne faut pas se leurrer, il faudra encore un certain temps à nos Linux avant d'intégrer les nouvelles versions de X, alors quid des améliorations en stabilité ? Parce que chez moi, j'ai la salle impression qu'un peu trop de 3D finit lamentablement par un gel complet de la machine, ce qui n'est quand même pas très pratique pour des drivers supposés justement apporter l'accélération 3D. C'était en tous cas valable pour les précédents drivers même si j'ai l'impression qu'Ati fait de plus en plus d'efforts sur ses drivers Linux.

  • # Projet Nouveau

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

    Je veux pas faire mon intégriste, mais moi j'espère de tout c½ur que le projet Nouveau aboutisse un jour ! C'est un projet qui vise à développer des pilotes libres complets (support de la 3D potable) pour les cartes Nvidia (depuis GeForce jusqu'aux toutes dernières).
    http://nouveau.sourceforge.net/

    Haypo

  • # Et les performances

    Posté par  . Évalué à 4.

    Ona longtemps dit que les cartes ATI sous Linux ne reflétaient pas du tout leur perfomances sous windows (parfois seulement 50% des perfs 3D) au contraire de NVIDIA.

    Qu'en est il aujourd'hui?

  • # C'etait trop beau pour être vrai...

    Posté par  . Évalué à 2.

    (II) fglrx(0): driver needs X.org 7.1.x.y with x.y >= 0.0
    (II) fglrx(0): detected X.org 7.1.1.0
    (WW) fglrx(0): ***********************************************
    (WW) fglrx(0): * DRI initialization failed! *
    (WW) fglrx(0): * (maybe driver kernel module missing or bad) *
    (WW) fglrx(0): * 2D acceleraton available (MMIO) *
    (WW) fglrx(0): * no 3D acceleration available *
    (WW) fglrx(0): ********************************************* *

  • # Je n'ai plus qu'à crever…

    Posté par  . Évalué à 4.

    Je n'ai rien trouvé concernant le support du ppc, uniquement du x86 64bits. Si ce n'est pas pour aujourd'hui, ce sera pour jamais, vu que les macs passent à Intel…

    Pour moi, ce serait plutôt ATI 0 - nVidia 0, et cela dans un match des moins palpitants :¬(…

    • [^] # Re: Je n'ai plus qu'à crever…

      Posté par  . Évalué à 5.

      T'as toujours le driver libre qui marche pas mal, aussi, faut pas l'oublier !

    • [^] # Re: Je n'ai plus qu'à crever…

      Posté par  . Évalué à 3.

      Vu les proportions respectives des architectures PPC et x86 sur les ordinateurs de bureaux couplées à celles des gens tournant sous autre chose que MacOS X avec un PPC, je crois que pour être franc, c'est dans tes rèves.

      • [^] # Re: Je n'ai plus qu'à crever…

        Posté par  . Évalué à 5.

        Oui et surtout c'est représentatif des limites des drivers propriétaires...

        Si au moins les specs étaient fournies...comme avant visiblement...le problème serait bien moins épineux...

        • [^] # Re: Je n'ai plus qu'à crever…

          Posté par  . Évalué à 0.

          Il faudrait encore trouver du monde pour faire ces drivers et surtout les maintenir, mais effectivement, cela permettrait d'avoir des drivers gérant la 3D quand même. On verra bien si les dernières emplettes d'AMD changeront ou pas la donne. Mais je pense que c'est quand même loin d'être trivial et que du point de vue financier et tout, c'est déjà bien qu'ils nous fassent des drivers pour Linux hein.

          • [^] # Re: Je n'ai plus qu'à crever…

            Posté par  . Évalué à 6.

            Figure que toi que les meilleurs developeurs de drivers 3D n'aspire qu'a faire du libre... Bcp des developpeurs d'xorg, mesa, dri travaille pour intel ou ati ... De plus la preuve que les developpeurs de drivers libre sont tres bon c'est le driver open source pour r200 qui est plus rapide que fglrx sur ces cartes.

            Donc l'excuse qu'il n'y pas les competences dans la communaute est completement fausse. Soulignons au passage l'engagement exemplaire d'intel qui continura a fournir des drivers libre pour ces prochaines cartes graphiques (c'est deja le cas pour les actuels).

          • [^] # Re: Je n'ai plus qu'à crever?

            Posté par  . Évalué à 2.

            Le truc c'est que quand un driver est "bien" codé, le porter pour une autre architecture est plutôt aisé. Alors quand il s'agit en plus du même OS, et que cet OS cache même les détails des différentes archis, c'est du gateau ! Et le driver x86 pour les cartes ATI sous linux est le même que pour toutes les autres archis. Une petite recompilation, et hop c'est parti...

  • # Argh

    Posté par  . Évalué à -8.

    Et dire que je viens de recevoir ma carte nvidia pour remplacer mon ati à cause des problèmes de drivers :(

  • # KGI

    Posté par  . Évalué à 1.

    Super, avec ça, on est pas prêt d'imposer KGI
    http://kgi.sourceforge.net

    Magnifique :(

    • [^] # Re: KGI

      Posté par  . Évalué à 2.

      Je ne crois pas que KGI soit une alternative fiable. Le projet a voulu faire table rase du passe et tout changer du jour au lendemain. Or dans tout l'univers du libre si tu observe tu verra qu'aucun projet ne procede comme cela. Le noyau linux avance par "petit a petit", de meme pour xorg, gcc, ... il y a parfois des grands changement mais ils sont anticipes et reste compatible avec ce qui se faisait avant.

      De plus la situation des drivers graphiques ne fait que s'ameliorer sur linux, bsd, solaris. D'ici peu tous ces OS auront un module noyau type DRM ce que voulait faire KGI plus ou moins. Ils partagerons dc la meme architecture pour mettre en place l'acceleration graphique.

      • [^] # Re: KGI

        Posté par  . Évalué à 1.

        Et quand est-il du fameux problème de droits surpêmes dont dispose Xorg sur le noyau?

        Ça sert à rien d'avoir un noyau si X peut faire ce qu'il veut.

        • [^] # Re: KGI

          Posté par  . Évalué à 2.

          vraiment ?

          dans une architecture où le GPU a une place presque aussi grosse que le CPU, c'est peut-être pas si ridicule

          • [^] # Re: KGI

            Posté par  . Évalué à 0.

            quand le GPU peut charger des mini firmware, généralement propriétaires, si je pense que ça peut ne pas plaire.

            • [^] # Re: KGI

              Posté par  . Évalué à 2.

              et ?

              *le CPU peut déjà le faire, si on lui demande. en gros actuellement on ne lui demande pas
              *ça implique en gros que ton code tournant sur le GPU ne sera pas libre (ou pas sous ton contrôle), comme d'hab, il faut savoir ce qu'on veut.

        • [^] # Re: KGI

          Posté par  . Évalué à 0.

          Justement le mise en place de l'architecture DRM permettra d'ameliorer la securite de ce cote et petit a petit (avec les autres changement majeurs libpci, ...) Xorg n'aura plus besoin de disposer des droits root.

          • [^] # Re: KGI

            Posté par  . Évalué à 2.

            En même temps, grâce à DADVSI, Xorg, il a plus le droit de rien faire, alors en userland ou en root...

            Hein ? Quoi ? La sortie ? C'est par là, je vais vous montrer...

            • [^] # Re: KGI

              Posté par  . Évalué à -2.

              Oué euh Skabo, ça c'est chez vous que ça se passe :)

              A croire que le gouvernement français fait en sorte d'oeuvrer aux max pour les USA <-- gros troll

              Blague à part, merci de votre éclaircissement, je ne comprend pas pourquoi tout le monde gueulait à propos de Xorg et ça, si les Direct Rendering Management est là, y a pas d'quoi flipper.

              bye

              ps: franchement, chosir DRM comme nom, ça nous facilite pas la tâche. :)

          • [^] # Re: KGI

            Posté par  . Évalué à 0.

            Hein ?! Un DRM pour améliorer la sécurité ? Relis tes classiques, le but des DRMs ce n'est pas d'apporter la sécurité du système, mais empêcher la libre manipulation des données. Après, ton système avec DRM peut être criblé de backdoors, cheveaux de troie, bugs, etc...

            • [^] # Re: KGI

              Posté par  . Évalué à 1.

              DRM est l'acronyme de Direct Rendering Manager (http://dri.sourceforge.net/doc/drm_low_level.html) est ca existait bien avant que les DRM (Digital Right Management) deviennent a la mode.

              C'est deux choses n'ont donc rien a voir. Pour comprendre l'architecture DRI/DRM(): http://dri.sourceforge.net/doc/design_low_level.html.

              • [^] # Re: KGI

                Posté par  . Évalué à -1.

                Dire qu'on a moinssé mon message qui contenait l'info dont Benoer manquait...

                bye

              • [^] # Re: KGI

                Posté par  . Évalué à 1.

                Argh, désolé du malentendu, ces derniers temps je suis un peu stressé dès que je vois DRM d'écrit quelque part... Oui effectivement alors, ça permet une meilleure sécurité en séparant la partie utilisateur de la partie noyau. Le pire c'est que je connaissais déjà l'archi DRI/DRM. Méa culpa.

Suivre le flux des commentaires

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