Nouvelles versions des pilotes ATI et NVIDIA pour GNU/Linux

Posté par  . Modéré par rootix.
Étiquettes :
0
6
août
2004
Matériel
Coup sur coup, les deux principaux constructeurs de cartes vidéos grand public ont annoncé la mise à disposition de leurs dernières versions (3.1.11 pour ATI et 1.0-6111 pour Nvidia) de pilotes pour Linux.

Malgré l'opposition de certains envers ces pilotes propriétaires, cela permettra à ceux qui veulent jouer à Doom3 sur leur OS favori de profiter de performances proches de celles sous Microsoft Windows. ATI
ATI a annoncé la sortie de la version 3.11.1 de ses pilotes x86 pour Linux. Au menu, surtout des correctifs :
  • Les modules fglrx sont maintenant corrects pour les noyaux 2.6.6 et suivants.

  • Les RPMS des modules fglrx rentrent en conflits avec les anciens packages pour fglrx-glc22 (ce qui n'était pas le cas avant !!)

  • La palette de couleur est correctement restaurée lors des switchs VT.

  • L'utilisation du Quad-Buffer stéréo avec les FireGL X1/Z1 ne provoque plus de corruption de bureau.

  • Ajout des supports pour les Radeon X800 AGP et FireGL X3-256.



NVIDIA
Nvidia propose la version 1.0-6111 de ses pilotes pour GNU/Linux IA 32 et AMD 64. Beaucoup de correctifs bien que la version précédente date d'à peine 1 mois :
  • Support des processeurs Intel EMT-64, AMD Opteron™, AMD Athlon™64 et AMD Athlon™FX 64 .

  • Correction de la validation de la certification de SoftImage.

  • La validation pour quitter devient optionnel.

  • Correction du problème sur les multiples instances de serveurs X avec les TNT/TNT2.

  • Correction du problème de la sortie TV qui empêchait d'autres résolutions que 640X480 et 800X600.

  • Correction du problème de placement/corruption du curseur avec certaines configurations Twin.

  • Correction du problème d'options ignorées avec certains module AGP.

  • Correction du problème GLSL avec shadow2DProj.

  • Correction des problèmes de console avec les GeForce4 Ti.

Aller plus loin

  • # Complèments

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

    Sans oublier la mises à jour des "optimisations" pour le nouveau Doom3 -_^ (moi ? médisant ?)

    A part ça, la news dit que
    La validation pour quitter devient optionnel.
    Il s'agit de la confirmation pour quitter nvidia-settings, l'utilitaire de configuration graphique de nvidia.

    • [^] # Re: Complèments

      Posté par  . Évalué à 2.

      Tu arrives à faire fonctionner nvidia-settings ? Quand je le lance chez moi, il coupe X et le relance. Je n'ai pas encore cherché d'où venait le problème mais il le faisait déjà avec l'ancien driver et j'ai toujours ce problème avec le nouveau.

      D'autres ont eu le même problème ?

      • [^] # Re: Complèments

        Posté par  . Évalué à 1.

        Non pas de problème(s) chez moi sur une TI 4600.
        Juste à configurer à la mano le support du Fast Writes et de SBA.

        • [^] # Fast write ?

          Posté par  . Évalué à 2.

          Et comment est-ce que tu configures à la main le Fast write ?
          Parce que ma GeForce en est capable, mon BIOS en est capable (et c'est activé) mais le driver (comme indiqué dans la doc) le désactive tout seul.
          Je voudrais essayer de lui forcer la main pour voir... Mais je n'ai pas trouvé.

          • [^] # Re: Fast write ?

            Posté par  . Évalué à 4.

            dans le XF86Config-4:
            Option "AGPFastWrite" "1"

            Je pense que c'est ça que tu cherches

            • [^] # Re: Fast write ?

              Posté par  . Évalué à 2.

              Arg ! Tout simplement !
              J'avais parcouru trop rapidement la doc (en abusant du Ctrl-F/F3 sur l'expression "Fast Write" et non "AGPFastWrite"...) La prochaine fois je RTFMerais plus proprement.

              • [^] # Re: Fast write ?

                Posté par  . Évalué à 2.

                Mhhh...
                Non, en fait, ce n'était pas si simple. Malgré l'option AGPFastWrite à "1" ou à "true", le pilote le désactive...

                • [^] # Re: Fast write ?

                  Posté par  . Évalué à 0.

                  c'est normal, il faut editer le fichier .c du driver, c'est la que tu active certaine option et ensuite du compile

                  • [^] # Re: Fast write ?

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

                    Euh, du temps ou j'ai essayé, il suffisait de passer l'option au module quand tu le chargeais... genre dans le fichier qui va bien:

                    option nvidia NVreg_EnableAGPFW=1 NVreg_EnableAGPSB=1 NVreg_EnableVia4x=1

                    (Respectivement fast write, side banding, et agp4x pour via, comme les noms l'indiquent :)

            • [^] # Re: Fast write ?

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

              ne pas oublier de désactiver le lancement automatique de l'interface X quand tu joue avec ce genre de choses, car moi aussi tout mon matos est compatible avec ces deux options, mais is j'en active une seule : FREEZE du pc et reboot hard obligatoire!!!

              Donc faire très gaffe quand on joue avec ce genre de choses!!!
              ne pas oublier un petit Alt+Impr Scr+s pour syncroniser les dur en cas de plantage!!!

            • [^] # Re: Fast write ?

              Posté par  . Évalué à 6.

              Bon c'est un peu hors sujet, mais j'en profite:

              J'ai une carte ATI Radeon 7000 VE. J'utilise le pilote libre (xlibmesa-dri 4.3.0.dfsg.1-4 Debian sarge) et en rajoutant ces quelques options dans /etc/X11/XF86Config-4 la différence de perfs en 3D est ENORME !

              
	Option          "AGPMode"       "4"
              
	Option 		"AGPFastWrite" 	"1"
              
	Option 		"EnablePageFlip" "on"
              
	Option 		"BackingStore" "on"

              +20% dans glxgears, mais c'est surtout avec les jeux, qui passent de saccadés à super fluide. Il faut vérifier ensuite dans /var/log/XFree86.0.log que ces options sont bien «passées»

              (**) RADEON(0): Using AGP 4x mode
              (**) RADEON(0): Enabling AGP Fast Write
              etc ...

              • [^] # Re: Fast write ?

                Posté par  . Évalué à 1.

                Sous Gentoo, pour activer les options agp d'nvidia il faut editer le fichier config /etc/modules.conf

                • [^] # Re: Fast write ?

                  Posté par  . Évalué à 2.

                  Sûrement pas. Ce fichier est généré par "update-modules" depuis les /etc/modules.d/*. Il faut donc plutôt se rajouter un /etc/modules.d/nvidia (si y'en a pas déjà un) et mettre là ce qu'on a à mettre, puis faire un update-modules.

              • [^] # Re: Fast write ?

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

                > en rajoutant ces quelques options dans /etc/X11/XF86Config-4 la différence de perfs en 3D est ENORME !

                [+] je confirme. En revanche, si je connaissais bien les trois premières, je ne trouve rien sur l'option BackingStore en faisant un man radeon. Ça sert à quoi, ce truc ?

                Envoyé depuis mon PDP 11/70

                • [^] # Re: Fast write ?

                  Posté par  . Évalué à 2.

                  J'avais trouvé ça en «googlant» avec comme commentaire :
                  # Prevents some artifact
                  Mais comme c'est pas dans la page man, c'est peut être une erreur (ou une fonction cachée ?)
                  En tout cas X ne s'en plaint pas dans XFree86.0.log

      • [^] # Re: Complèments

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

        Pareil, mais seulement depuis que je suis passé en dual-head

  • # Utilité des pilotes proprios

    Posté par  . Évalué à 10.

    > cela permettra à ceux qui veulent jouer à Doom3 sur leur OS favori de profiter de performances

    Certaines personnes (moi en l'occurence) sont obligées d'avoir recours à ces pilotes proprio pour le boulot (visualisation en chimie théorique). Pour le moment, les pilotes libres ne font largement pas l'affaire, donc pas moyen de se passer des pilotes proprio.

    Contrairement à ce qu'on entend toujours, il n'y a pas que pour les jeux qu'on a besoin des dernières cartes graphiques hi-tech (et des drivers qui vont avec :)

    (Voilà pour mon mini coup de gueule)

  • # doom3?

    Posté par  . Évalué à 1.

    Salut à tous,

    Je vais peut-être avoir l'air idiot mais, par pure curiosité... je n'ai pas entendu parler d'une version de doom 3 pour linux? Ce serait trop beau. Ou alors est-il question d'un utilisation via Wine?

    Ceci dit, pour ce qui est des pilotes eux-mêmes, on peut en dire ce qu'on veut, ils ont au moins le mérite d'exister!

    Seb.

    • [^] # Re: doom3?

      Posté par  . Évalué à 2.

      Si si, Doom 3 tournera en natif sous linux, comme Quake 3 !

    • [^] # Re: doom3?

      Posté par  (Mastodon) . Évalué à 3.

      Sisi, Doom3 pour Linux puis pour Mac doivent sortir dans peut de temps.

    • [^] # Re: doom3?

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

      Id Software et surtout John Carmack (le développeur vedette) sont des fervents défenseurs d'OpenGL et aussi de Linux.

      C'est le fait que tous les jeux Id Software et leurs dérivé utilisent OpenGL et non l'abominable DirectX qui a fait que les jeux soient facilement portables sur Linux et MacOS X.

      Sans eux, on n'aurait pas eu Quake 3, Return to Castle Wolfenstein, Ennemy Territory et surtout Doom 3.


      Pour la petite histoire, avant l'arrivée de XFree 4 et de DRI, un projet Open Source réalisé un driver OpenGL avec accélération matérielle pour XFree 3. C'était le projet Utah-GLX.

      Les cartes supportées étaient essentiellement les Matrox G200 et G400 ainsi que les ATI Mach 64.

      Le projet a longtemps végété jusqu'au moment ou John Carmack est arrivé et a mis toute son énergie à en faire un driver stable et performant. C'était d'ailleurs très impressionnant de suivre la mailing list du projet.

      C'est depuis ce temps là que je suis beaucoup plus réservé sur les drivers OpenGL open source car je sais que c'est loin d'être à la portée du premier programmeur venu. Il faut être à la fois très compétent en développement, en architecture noyau et en 3D/OpenGL et très rares sont les gens à avoir les 3 compétences à la fois au niveau nécessaire pour faire vraiment avancer le sujet.


      A ma grande surprise, le projet existe toujours et fonctionne pour XFree 4.
      Ils ont même une implémentation Open Source de drivers pour les NVidia TNT et GeForce !!!

      http://utah-glx.sourceforge.net/(...)


      Il reste encore des traces de la participation de John Carmarck dans les docs d'enfer qu'il avait écrit pour le projet à l'époque :

      http://utah-glx.sourceforge.net/docs/overview.txt(...)
      http://utah-glx.sourceforge.net/memory-usage.html(...)
      http://utah-glx.sourceforge.net/docs/X_dma_hack.txt(...)

      • [^] # Re: doom3?

        Posté par  . Évalué à 1.

        Comme quoi, les gens de bonne volonté, ca existe! Et ca fait plaisir de voir ca.

        Seb.

      • [^] # Re: doom3?

        Posté par  . Évalué à 2.

        lorsqu'on regarde la mailing c'est super triste de voir comme ils ont été plus ou moins tuer par le spam :/

      • [^] # Re: doom3?

        Posté par  . Évalué à 1.

        Je ne connais pas trop ce projet mais a première vue, il fait fonctionner l'accélération matériel sur les TNT de Nvidia.

        Question :
        Pourquoi ne pas en faire des pilotes framebuffer / directfb / Y / etc... ?

  • # une occasion manquée?

    Posté par  . Évalué à 2.

    Ne serait il pas l'occasion de rappeller quelques liens d'informations sur les drivers opensources de ces cartes vidéos ou de leurs utilisations.

    Car personnellement j'utilise les drivers proprio d'ATI car je ne connais pas le moyen de faire du DUAL HEAD avec ma seul carte radeon 9500 et ses drivers opensources.

  • # y'a t-il du mieux chez ATI ?

    Posté par  . Évalué à 1.

    je n'ai jamais reussi à faire fonctionner les drivers ATI sous Linux, j'ai toujours des conflits avec mesagl et quand le conflit est resolu impossible d'obtenir l'acceleration 3d :-(
    Et ce qui me chagrine le plus je pense c'est que ATI ne sort que des RPM, et une fois "aliénisés" en .deb ou autres ca marche de traviole.
    Cette nouvelle release de drivers est-elle réellement prometteuse ? ca reste à voir ....

    • [^] # Re: y'a t-il du mieux chez ATI ?

      Posté par  . Évalué à 1.

      AAAHHHH !!!!!!!!

      Je ne suis pas le seul.

      A chaque nouvelle vesrion des pilotes ATI. Sans jamais avoir la 3D.

      Que ce soit avec la Mandrake 9.2 ou la 10..

      Ma carte est une Sapphire 9200 Atlantis - 128 mo.

      Il semblerait qu'avant l'installation du pilote, il soit necessaire d'installer le source du noyau qui va bien..

      Alors je vais à nouveau tenter ma chance.

      • [^] # Re: y'a t-il du mieux chez ATI ?

        Posté par  . Évalué à 2.

        Je ne connais pas les drivers ATI, mais dans le cas des Nvidia effectivement, si ton installation n'est pas exactement celle prévue il regénère un module spécifiquement pour ton noyau et il lui faut donc les sources. C'est peut-être la même chose pour les ATI...

        • [^] # Re: y'a t-il du mieux chez ATI ?

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

          c'est la même chose chez ATI!!!

          conseil :

          Installe les source qui correspondent a la dernière version de kernel et le dernier kernel aussi (tant qu'a faire ça corrigera quelque bugs...)

          urpmi kernel (choisi le plus récent)
          urpmi kernel-source (choisi le plus récent identique à au dessus)

          reboot sur le dernier kernel

          loggue toi en root et fait ceci :
          cd /usr/src/linux
          make mrproper
          cp -f /boot/config ./.config

          édite le fichier Makefile avec : kwrite Makefile
          et change le champ où il y a = -xmdk custom en = -xmdk
          si tu utilise le noyau normal

          make oldconfig
          make prepare-all

          et installe ton rpm normalement, tu sera peut-être obligé d'aler dans /lib/je sais plsuquoi pour aller compiler le module, mais normalement cette maip suffit...

          • [^] # Re: y'a t-il du mieux chez ATI ?

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

            grrr quelle horreur ce clavier dislexique...

          • [^] # Re: y'a t-il du mieux chez ATI ?

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

            euh raphael pas besoin de recompiler le noyau pour autant ? Mandrake l'a déjà fait... (en revanche merci de la manip')

            perso :
            telinit 3 # tue X proprement
            urpmi kernel # si nécessaire
            urpmi kernel-source # obligatoire si étape précédente faite (sinon ne pas le faire) => vérifier qu'il y a concordance des versions : uname -a ; rpm -q kernel-source

            # ici la compil' du driver récupéré chez nVidia (chez moi) / ATI pour les autres

            telinit 5 # revient à X (et pour les démarrages suivants)

            si changement de kernel : boom reboot (pas trop souvent : c'est pour prendre en compte le nouveau kernel

            bon une fois sur deux au changement de kernel j'oublie de recompiler le driver nvidia donc ça donne plutôt :
            urpmi kernel
            urpmi kernel-source # quand je ne l'oublie pas non plus

            boom reboot (pour aller sur le nouveau kernel)
            arg démarrage avec le driver nv au lieu de nvidia (avant c'était arg je suis en console...) enfin bon au fil du temps ça devient gérable et un peu moins destabilisant ;-)

      • [^] # Re: y'a t-il du mieux chez ATI ?

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

        Ma carte est une Sapphire 9200 Atlantis - 128 mo.

        ça marche avec les drivers libres ça...

    • [^] # ATI for Debian

      Posté par  . Évalué à 2.

      http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.h(...)

      pas a jour avec les derniers drivers venant d'ATI mais bien utile pour comprendre comment installer les drivers binaires avec une debian.

  • # Monitorer une carte nVidia...

    Posté par  . Évalué à 6.

    Cela fait quelques temps déjà (1 an et demi) que le ventilateur de ma GeForce 2 Pro est en rade. Elle fonctionne très bien avec le radiateur seul à condition de ne pas jouer à un jeu en 3D durant les fortes chaleurs... Bref, c'est pas l'idéal. J'ai commis un immonde bricolage à base de ventilateurs et de bouts de radiateurs récupérés à droite et à gauche. Cela semble marcher mieux.
    Cependant j'aimerai bien suivre l'augmentation de température du core et de la mémoire de ma carte graphique. La sonde existe, je l'ai vu.
    Je n'ai pas trouvé comment utiliser lm_sensors avec des cartes nVidia (je ne suis d'ailleurs pas sûr que ce soit possible). J'espérais en installant ces nouveaux drivers trouver avec nvidia-settings un outil de monitoring: que-nenni.

    Quelqu'un connaît-il un outil qui me permette de surveiller la température de ma GeForce (que je vérifie si mon bricolage a du succès)...

    • [^] # Re: Monitorer une carte nVidia...

      Posté par  . Évalué à -1.

      Il me semblait que la sonde était détecter par nvidia-settings et à afficher la températur (il me semblait avoir vu des screenshots de ca...)

      • [^] # Re: Monitorer une carte nVidia...

        Posté par  . Évalué à 2.

        Hélas, cela n'apparaît pas chez moi !

        Donc ma carte graphique (en plus d'avoir un ventilateur pourri à un format propriétaire) a aussi une sonde propriétaire... (pour info c'est une Leadtek)
        Dommage...
        Cela dit, lm-sensors prétend supporter les nVidia grâce au kernel-module rivatv, mais je cherchais quelque chose de plus simple que de compiler un module (qui du reste, n'est pas réellement destiné à fonctionner avec ma carte graphique)

    • [^] # Re: Monitorer une carte nVidia...

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

      si si il y a un moniteur de températue dans le nvidia-settings!!!

      Je ne sais pas en revanche si il tourne sur ta carte.
      En tout cas il l'est sur la mienne : ASUS GeForce 5700FX 256DDR
      J'ai changé la pâte thermique à la silicône infâme (y avais même pas une goute de silicône, ASUS me déçois...) en pâte a l'argent je suis passé dans nvidia-settings de 56°C à 44°C!!!

      Avec le même dissipateur et le même ventillo!!!

      • [^] # Re: Monitorer une carte nVidia...

        Posté par  . Évalué à 2.

        «J'ai changé la pâte thermique...»

        Je ne pensais pas qu'elle avait une telle importance.
        J'ai préféré fixer un nouveau ventilateur sur l'ancien radiateur de ma carte avec trois bouts de ficelle (non... ce n'est pas une façon de parler ! :o) J'avais bien dit que c'était un bricolage immonde !). Et puis j'ai rajouté des petits radiateurs sur les chips de mémoire (des deux cotés du PCB :o)).
        Et cela semble suffire... Si j'ai à nouveau des plantages j'irai jeter un œil du coté de la pâte thermique.

    • [^] # Re: Monitorer une carte nVidia...

      Posté par  . Évalué à 1.

      Cela fait quelques temps déjà (1 an et demi) que le ventilateur de ma GeForce 2 Pro est en rade.

      "Content" de savoir que je ne suis pas le seul à avoir ce problème avec cette carte dont le ventilo est d'une solidité et d'une fiabilité .... désastreuse. Pareil que toi, montage d'un autre ventilo avec 2 bouts de ficelles ...

    • [^] # Re: Monitorer une carte nVidia...

      Posté par  . Évalué à 1.

      Je ne connais pas d'outils pour ça, mais je sais que Zalman fait des gros radiateurs pour cartes graphiques afin des les refroidir en silence, ça peut toujours être une solution moins "bricolage" et plus pérenne pour une carte qui ne doit pas chauffer des masses. J'en ai mis un sur ma 9600 Pro et ça marche très bien et ne coute qu'environ 20€ dans les bonnes boutiques. Si ça t'/vous intéresse, il faut juste penser à aller voir sur leur site si c'est compatible avec votre carte vidéo.

    • [^] # Re: Monitorer une carte nVidia...

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

      Je pouvais voir la temperature de ma Leadtek GeForce2 GTS avec le kernel 2.4 lm_sensors et rivatv (http://rivatv.sourceforge.net/(...)). Je n'ai pas réussi avec le kernel 2.6.

      Sinon pour remplacer ton bricolage, je te conseille le Zalman ZM-80. Cela m'a permis de remplacer le ventilrad d'origne hyper-bruyant par du refroidissment passif avec quelques degrés de gagnés au passage.

  • # Ça commence par les pilotes de cartes graphiques...

    Posté par  . Évalué à -1.

    Ça y est, tout le monde se réjouit de la sortie de nouveaux pilotes propriétaires ? Tout le monde est content ? Tout le monde est bien dressé à accepter du code propriétaire dans son noyau ?
    Non, parce que non contents d'être des pilotes propriétaires pour X11, ceux-ci se croient obligés de s'imposer dans le noyau, alors que bien d'autres pilotes X11 s'en passent très bien...

    Évidemment, il y a de bonnes raisons de les accepter (bénéficier sous Linux des performances 3D des dernières cartes sorties), mais il n'y aura pas de retour en arrière (pourquoi fournir les spécs pour des pilotes libres quand 99 % des utilisateurs de Linux se contentent de pilotes propriétaires), et puis bientôt, il y aura de bonnes raisons d'accepter un autre truc non libre, puis un autre... et quand on se réveillera, on s'apercevra qu'on est en train d'utiliser l'équivalent exact de Windows !

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Ça commence par les pilotes de cartes graphiques...

      Posté par  . Évalué à 1.

      Je suis d'accord à 100% Malheureusement le reverse engineering de ces drivers est une chose assez difficile... Cependant si je ne me trompe pas il existe en France une loi qui oblige un constructeur à fournir les spécifications de son matériel dans un but d'interopérabilité. Si une personne veut bien faire un procès à Nvidia et ati pour obtenir les spécifications :) Attention dans la demande il faut dire que vous désirez écrire un drivers pour autre chose que linux(Hurd par exemple) car ils fournissent déjà un driver pour linux... Enfin bon on peut rêver non ^^

    • [^] # Re: Ça commence par les pilotes de cartes graphiques...

      Posté par  . Évalué à 3.

      C'est le genre de reaction que je ne comprends pas. J'adere completement au libre, et j'utilise linux exclusivement depuis quelques annees. Mais pour ce qui est des drivers, j'accepte tout a fait que ceux-ci soient proprio.

      En effet, si ces derniers sont fournit pour linux, avec les memes performances que sous windows, ou est le probleme ?

      Les constructeurs investissent enormement pour creer des processeurs graphiques performants, et ils devraient rendre publique les speficites comme ca ? Juste parce que "c'est mieux si c libre ?". Je ne pense pas.

      Il ne faut pas etre integriste, et le proprietaire peut parfaitement cohabite avec le libre !

      Autant sur les logiciels, en particulier le systeme d'exploitation, le proprio peut entrainer les pb de dependances etc... comme on peut le voir avec microsoft. Mais la il sagit d'un carte graphique ! il n'y pas de compatibilite comme sur un pc "vide", on est dependant des le materiel. Donc le probleme n'est plus du tout le meme, et le proprio ne me derange pas quand il sagit de drivers, et que ceux-ci sont fournit avec la carte bien evidement.

      Voila, j'en ai assez de cet integrisme "il faut que ce soit libre a tout prix, sinon c'est nul". En plus j'ai l'impression en lisant ton message que tu me prends de haut (cf : Ça y est, tout le monde se réjouit de la sortie de nouveaux pilotes propriétaires ? Tout le monde est content ? Tout le monde est bien dressé à accepter du code propriétaire dans son noyau ?), et desole, mais ton point de vu n'est pas forcement le bon.

      Oui je me rejouit, de la sortie de pilotes proprio, vu que ma carte vient d'un fabriquant particulier, et ne doit pas repondre a une norme particuliere. Oui je suis tres content. Et non je n'ai pas ete dresse, etant donne que le probleme est tout a fait different que pour le systeme d'exploitation.

      Ce n'est pas parce qu'on accepte qqchs de non libre qu'on tombe dans le systeme "a la windows". Au risque de me repeter : il faut savoir remettre les choses dans leurs contextes !

      • [^] # Re: Ça commence par les pilotes de cartes graphiques...

        Posté par  . Évalué à 7.


        En effet, si ces derniers sont fournit pour linux, avec les memes performances que sous windows, ou est le probleme ?

        Autant sur les logiciels, en particulier le systeme d'exploitation, le proprio peut entrainer les pb de dependances etc... comme on peut le voir avec microsoft. Mais la il sagit d'un carte graphique ! il n'y pas de compatibilite comme sur un pc "vide", on est dependant des le materiel. Donc le probleme n'est plus du tout le meme, et le proprio ne me derange pas quand il sagit de drivers, et que ceux-ci sont fournit avec la carte bien evidement.


        C'est sur c'est mieux d'avoir des pilotes foireux et mal teste (y a qu'a voir le changelog) dans le noyau qui font te pourrir le systeme de basse, que d'avoir une pauvre appli proprio qui ne touchera a rien au systeme de base. Pour moi le pb de dependance ce trouve dans l'autre sens etant donné que GNU/linux, X, ... depande de ta carte...

        Et puis c'est bien avec des drivers proprio si on veut se faire une divx box, ou quelque chose du meme genre qui utilise directfb (oui X n'est pas si leger que ca), ou meme faire des drivers a vidix ben tu peux toujours courrir pour avoir un truc 100% fonctionnel...

        Idem si tu veut utiliser un autre OS non supporte (hurd,...)


        Ce n'est pas parce qu'on accepte qqchs de non libre qu'on tombe dans le systeme "a la windows". Au risque de me repeter : il faut savoir remettre les choses dans leurs contextes !

        oui, mais tu perd tout l'aspet libre, personellement je trouve deja que certains drivers sans spec (par exemple driver wifi intel, pilote eagle) ou encore ceux qui depande d'un firmware proprio (par exemple carte dvb-s ) c'est tres limite. Dans les deux cas tu n'est pas libre de faire evoluer ton driver pour pouvoir profiter au maximun du materiel comme tu l'entend (par exemple pour les carte dvb-s tu prefere avoir un osd avec 256 couleurs dispo sur toute l'image, plutot que d'utiliser la memoire interne pour la bufferisation,...). Y a un bug dans le firmware ou dans la partie d'acces au materiel, sans les spec t'iras pas loin...

        Par exemple routeurs wifi comme le linksys qui grace au fait qu'il utilise linux comme OS, on les sources du systeme disponible (enfin y a certaines partie propio) ce qui te permets de rajouter sur ton routeur du vpn, un ssh,...(bref tu est libre d'en faire ce que tu veux et non pas etre depandant du constructeur, t'as bien acheter le materiel, t'es bien senser pouvoir en faire ce que t'en veux)

        [mode reve]
        Finalement ce qui serait bien c'est qu'une companie (ou des) ce fasse a faire du materie compatible avec le libre : ie du bon materiel avec de vrai spec et un driver/systeme initial libre...
        [/mode reve]

      • [^] # Re: Ça commence par les pilotes de cartes graphiques...

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

        > si [les pilotes] sont fournit pour linux, avec les memes performances que sous windows, ou est le probleme ?

        Le problème, il est dans le fait que tu ne sais pas ce qu'ils font, que tu ne peux pas les déboguer, les améliorer, etc.

        > Les constructeurs investissent enormement pour creer des processeurs graphiques performants, et ils devraient rendre publique les speficites comme ca ? Juste parce que "c'est mieux si c libre ?". Je ne pense pas.

        Laisse-moi juste réécrire ta phrase, pour voir si ça passe : « les éditeurs investissent énormement pour créer des logiciels applicatifs performants, et ils devraient rendre publiques les sources comme ça ? Juste parce que “ c'est mieux si c'est Libre ” ? Je ne pense pas ». Ah bah oui, ça passe bien. Sauf qu'il y en a qui les rendent libres quand même. Pour ce qui est des adaptateurs graphiques, la question est même encore plus simple, vu qu'ils ne font pas leur pognon sur les pilotes, mais sur le matos. Donc oui, ils devraient (nVIDIA l'a même fait à l'époque de GLX et des TNT. Désormais, ils affirment avoir du code tierce partie qu'ils ne peuvent révéler. Bah moi, je peux pas acheter leur matos tant qu'ils l'enlèvent pas. Point final).

        > Il ne faut pas etre integriste, et le proprietaire peut parfaitement cohabite avec le libre !

        Oui, bien sûr. Tant que c'est un choix. Là, faute de spécifications publiques, il n'y a guère de choix possible pour les possesseurs de ces cartes. C'est soit des pilotes ne faisant pas de 3D, soit du proprio. Merci bien…

        > Mais la il sagit d'un carte graphique ! il n'y pas de compatibilite comme sur un pc "vide", on est dependant des le materiel.

        Je comprends pas bien, là. En quoi le pilote de ta carte graphique est-il moins important que, mettons, ton kernel, ton shell ou ton traitement de texte ? Perso, je me fiche un peu d'installer (par exemple) le plugin proprio pour Flash (après tout, je peux m'en débarrasser sans réduire horriblement les fonctionnalités de mon système), en revanche je suis dépendant de ma carte graphique pour beaucoup de choses, je ne veux donc pas dépendre d'un morceau de code opaque que je ne contrôle pas.

        > Oui je me rejouit, de la sortie de pilotes proprio, vu que ma carte vient d'un fabriquant particulier, et ne doit pas repondre a une norme particuliere.

        <sarcasme mode="gentil">Ah ? Toutes les normes édictées jusque-là ont disparu ? VESA, OpenGL, tout ça, ça n'existe plus ? On en apprend tous les jours, dites donc !</sarcasme>

        > Ce n'est pas parce qu'on accepte qqchs de non libre qu'on tombe dans le systeme "a la windows".

        Aujourd'hui, tu vas accepter un pilote non libre. Demain, tu accepteras une bibliothèque non libre (c'est déjà arrivé, le cas le plus célèbre est KDE avec Qt), puis des outils de développement non libres (*couf* BitKeeper *couf*), puis petit à petit, tu te retrouveras avec plein de soft proprios dont tu ne pourras pas te passer, et tout sera à refaire. Mieux vaut dire stop dès maintenant, et faire avancer les softs libres plutôt que d'aller chercher un soft proprio pour remplir une tâche (et d'autant plus que la tâche est critique, puisque ça rendra ledit soft plus indispensable). Ce n'est pas de l'intégrisme, là (on ne peut guère m'accuser d'être un fan de RMS), c'est tout bonnement de l'instinct de conservation !

        Envoyé depuis mon PDP 11/70

      • [^] # Pourquoi il faut des piotes libres

        Posté par  . Évalué à 1.

        En effet, si ces derniers sont fournit pour linux, avec les memes performances que sous windows, ou est le probleme ?

        Voyons, par où commencer ?
        - Il n'y a pas de raison d'avoir beaucoup plus confiance en un système dont une partie du noyau est fermée que dans système entièrement fermé.
        - En cas de bug sévère compromettant le fonctionnement du système, tu es totalement dépendant du constructeur pour sa correction.
        - Les constructeurs de matériel ont un grand passé de programmation avec les pieds : à l'époque de Windows 95, il y a des machines, comme ça, qui plantaient très souvent et qui, comme par miracle, pouvaient devenir beaucoup plus stables en changeant un pilote, ou carrément un composant. Quand Microsoft en a eu marre que les plantages dûs à la médiocrité des drivers soient attribués (aussi) à Windows, ils ont mis en place un programme de certification. Sous Linux, il n'y en a pas, les constructeurs peuvent donc à nouveau "se lâcher". Et pour avoir eu le cas d'une machine sur laquelle le driver nVidia propriétaire cause un gel du système en cas de mise en veille de l'écran, je n'ai aucun doute sur le fait qu'ils aient tout de suite retrouvé les bonnes vieilles habitudes...
        - Tu es totalement dépendant du contructeur quant au support du matériel pour d'autres systèmes (BSD, Hurd...), d'autres architectures (IA64...), ou même des versions ultérieures de ton système. S'il décide qu'il n'y a pas de raison que les gens qui ont acheté leur matériel il y a trois ans puissent l'utiliser avec des sytèmes récents plutôt que de leur en racheter du neuf, il leur suffit d'arrêter de fournir de nouveaux pilotes pour ce matériel.

        Qu'il existe des pilotes propriétaires pour ceux qui préfèrent que leur système tourne vite (dans le domaine des cartes graphiques en particulier, le but des constructeurs est de faire un pilote qui donne l'impression que leur matériel est plus performant que celui de leurs concurrents, au détriment de toute autre considération) et mal, ça ne me dérange pas, mais que ce soit prétexte à ne pas diffuser les spécifications du matériel pour permettre le développement éventuel de pilotes libres, c'est extrêmement génant...

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Ça commence par les pilotes de cartes graphiques...

      Posté par  . Évalué à 3.

      ATI pilotes propriétaires 20% du marché
      NVIDIA pilotes propriétaires 20%
      Intel pilotes propriétaires 40%
      VIA visiblement libre
      Matrox visiblement mort (dernières modifs y a un an)

      Donc a part VIA je vois pas trops chez qui te fournir (via ne fait que du matos embarqué il me semble).

      Pour les spec tu peux te battre, te fouetter, implorer la justice des hommes, de dieu, de qui tu veux jamais ils te les filerons.

      (Les pilotes DRI ont une partie DRM qui s'incruste dans le noyau).

    • [^] # Re: Ça commence par les pilotes de cartes graphiques...

      Posté par  . Évalué à 2.

      Quand on voit la complexité actuelle des cartes graphiques, et les compétences requises pour écrire un driver de bonne qualité, on comprend qu'il est trop tôt pour esperer une divulgation complète des specification et des sources des drivers. D'autant plus que la main d'oeuvre capable de coder de telles choses est peu nombreuse et déja occupée sur d'autre projet. Rien que pour metre catalyst au niveau des drivers de nvidia pour doom3, ils doivent déjas bien se prendre la tête, et encore en travaillant sur une architecture qu'il connaissent depuis belle lurette. Le problème n'est pas aussi simple que: "faire des pilotes libres pour SUPPORTER une carte graphique sous linux". Il faut prendre en compte toute la problématique des performances. Et sur ce point il est vrai que les drivers libres sont moins performant que ceux de ati sous linux qui le sont moins que ceux de ati sous win. Dans le contexte actuel c'est tout à fait logique.

      • [^] # Re: Ça commence par les pilotes de cartes graphiques...

        Posté par  . Évalué à 1.

        Euh, tu confonds visiblement "faire des drivers libres et les filer à tout le monde" et "filer les specs à la communauté et les laisser se demerder avec", comme beaucoup de monde. En plus traduit ton discours avec KDE, GNOME ou OOo et j'en déduis qu'on ne devrait pas avoir les sources parce que c'est compliqué ? Pis de toute manière moins de 1% de la population est capable de modifier du LL, dois-je en déduire que ca n'a aucun interet.

        Je ne vois pas pourquoi le souhait que les drivers soient libres entrainerait forcement des drivers non développés par les constructeurs. Après c'est bien entendu une question de choix pour eux (et de sombres histoire de "c'est pas nous qui l'avons codé, on a pas le droit de vous le filer" ce qui ne me rassure guère quand à la qualité des drivers (et m'empeche d'en acheter jusqu'à présent ; je ne peux pas me permettre de pourrir mon noyeau)).

        Il y aurait des repercussions quasi "immédiates" à ce que les drivers soient libres : support de Linux sur architecture PPC par exemple (pas besoin d'être un expert dans 30 domaines différents pour faire un port correct) ! Support d'autre OS aussi. Débuggage des trucs triviaux par des gens exterieurs au constructeurs aussi surrement (regler un problème de palette lors de commutation de VT doit prendre 1H à tout casser, ou alors l'architecture de la carte est désastreuse si c'est plus compliqué)

    • [^] # Re: Ça commence par les pilotes de cartes graphiques...

      Posté par  . Évalué à 2.

      Tu as raison Link, autant rester sous Windows, hein? ou mieux utiliser linux en mode console 80x25?
      ce genre de comportement intégriste nuit gravement à la santé :)

      Je suis content que des pilotes sortent, que ma carte pour laquelle j'ai déboursée des biftons, marche impec, si il y a l'équivalent en libre, alors je passe aux pilotes libres.
      Mais faut arrêter un moment.

      Utiliser les pilotes fermés, n'est pas un mal, mais il ne faut pas baisser les bras quant à la demande incessante (j'éspère) des specs.
      Car je ne comprend tjrs pas pourquoi ils ne les filent pas ces specs, tout ce que ça peut faire, c'est encourager l'achat de ce genre de cartes.

      Le problème c'est qu'Nvidia tiens bon le monopole, qu'il a enterré 3Dfx qui -sans nul doute - nous aurrait fait eviter à tous cette situation de m****.

      parlons pas des bleus d'Ati...


      +

    • [^] # Re: Ça commence par les pilotes de cartes graphiques...

      Posté par  . Évalué à 3.

      Et le microcode de ton processeur il est libre ?

      Et ton BIOS ?

      Et le code du contrôleur de ton disque dur ?

      Et celui de ton CDROM ?

      Et celui de ton graveur ?

      Du code il y en a une floppée dans une machine, il n'y a pas que ce qu'on charge quand on l'allume, il y a beaucoup de trucs embarqués aussi. Là curieusement personne ne râle. "Ouin, le BIOS de ma carte SCSI il est pas libre, je peux pas le patcher, elle envoie peut-être les photos de ma copine à Bill Gates dans mon dos".

      Le matériel actuel est devenu complexe, le temps de l'AppleII livré avec un schéma de montage complet est passé. Il n'y a probablement plus personne qui puisse prétendre maîtriser l'ensemble des aspects d'un ordinateur, logiciel et matériel.

      Les cartes graphiques sont des petits systèmes embarqués particulièrement pointus, qui représentent des investissements d'autant plus lourds que leur durée de vie n'est pas très longue. Les fabricants ont beau essayer de déporter les coûts en ne vendant que les chips et en laissant des revendeurs genre Hercules faire les incvestissements de packaging, de comm, d'assemblage, etc, il reste la R&D, le développement, le suivi des gammes, la rémunération des fondeurs (je ne pense pas que nVidia ou ATI soient fondeurs, etc.), tout ça coûte quand même très très chèr (voir le taux de mortalité élevé dans le secteur).

      Bref c'est bien joli de couiner du "ouin c'est pas libre" mais il faut être un minimum cohérent. Soit tu râles pour tout le code qui n'est pas libre sur ton système et tu fais tourner un R3000 (je crois que le design a été libéré) avec du matos d'il y a 20 ans qui est parfaitement connu, documenté et libéré en collant un VT100 au cul du bouzin, soit tu fais comme tout le monde, tu regrettes qu'on ne puisse pas faire mieux, tu espères que des progrès seront faits et tu profites des jolies images.

      • [^] # Re: Ça commence par les pilotes de cartes graphiques...

        Posté par  . Évalué à 6.

        Je vais un peu jouer les agitateurs ... ou peut-être pas.

        Il y a un argument en faveur des drivers libres que j'aimerais avancer.

        Le fait, pour un périphérique, de posseder un driver libre permet à l'utilisateur
        d'avoir la liberté de déterminer la fin de vie de son matériel sans dépendre de son fabriquant pour disposer d'un driver sur le système sous lequel il veut tourner.
        Cette mésaventure m'est déja arrivé avec une carte tuner radio (type guillemot). Passage sous windows XP impossible ( pas de driver à l'époque prévue pour ce système chez le fabriquant et visiblement pas envie d'en faire un).
        A titre de référence, se driver existait du temps du 2.2, du 2.4 et existe pour le 2.6 sous linux.
        Les drivers libres plus que par leur valeur technique valent par la pérénité qu'ils donnent au matériel que l'on achète. C'est cette liberté que nous perdons en partie si nous considérons le driver propriétaire comme une fin en soit.

        Cependant, je pense qu'un drivers propriétaire n'est pas une mauvaise idée dans un premier temps. Elle permet en effet de garantir une mise à disposition et une qualité technique minimale ( en général :-)). Cependant, il devrait être acquis dans une société ou le développement durable va devenir une obligation pour notre survie à tous, que la fin de vie d'un matériel vienne de son épuisement, pas du caprice d'une société commerciale quelconque qui veut faire renouveler son matériel. Dans cette optique, un driver, lorsque la société signe l'arret de commercialisation de son matériel, devrait automatiquement devenir ouvert dans un but d'interopérabilité pour le futur. La loi est dans ce sens et cette première phase en tant que driver fermé permettrait aussi de protéger la R&D de la société commerciale en lui permettant de garder 3-5 ans (durée de commercialisation d'un matos) d'avance sur des copieurs potentiels.

        Voila mon avis... il n'engage que moi mais à le mérite de tenter de concilier les deux positions.

        • [^] # Re: Ça commence par les pilotes de cartes graphiques...

          Posté par  . Évalué à 1.

          L'argument de la pérénité est très pertinent, c'est effectivement un aspect auquel je n'avais pas pensé.

          Un pilote avec un code fermé oblige à maintenir une API compatible ou une couche d'émulation. Ou comme le fait XP à abandonner le matériel...

          Pour l'instant dans le cas des adaptateurs graphiques ça semble se libérer au fur et à mesure que les cartes deviennent obsolètes. Mais il n'est pas du tout certain que la tendance va se poursuivre avec les modèles actuels qui sont autrement plus complexes que ceux d'il y a cinq ou dix ans...

          Forcer la divulgation lorsqu'un produit est abandonné serait une bonne solution mais la législation actuelle me semble plutôt aller en sens inverse avec des lois de plus en plus contraignantes sur la protection intelectuelle et notamment les données numériques et le reverse engineering.

          On verra.

          • [^] # Re: Ça commence par les pilotes de cartes graphiques...

            Posté par  . Évalué à 2.

            Un pilote avec un code fermé oblige à maintenir une API compatible ou une couche d'émulation. Ou comme le fait XP à abandonner le matériel...

            Note que la situation n'est pas aussi mauvaise que ça dans le cas de NVidia et ATI, puisqu'ils utilisent une couche de compatibilité qui, elle, est open-source (je sais pas sous quelle license).

            C'est ce qui avait permis d'avoir le driver NVidia dispo pour le 2.6 alors qu'ils ne le supportaient pas encore officiellement, et j'utilise toujours cette ancienne version car les nouvelles me posent problème dans les consoles texte (même cette dernière version).

            Si d'autres constructeurs faisaient déjà ça ce serait un bon début. Je pense au cas d'un modem ADSL USB dont le constructeur fournit une archive avec un modile pré-compilé pour le noyau standard de la mdk9.1, et rien d'autre. Inutilisable.

            • [^] # Re: Ça commence par les pilotes de cartes graphiques...

              Posté par  . Évalué à 1.

              < Note que la situation n'est pas aussi mauvaise que ça dans le cas de NVidia et ATI, puisqu'ils utilisent une couche de compatibilité qui, elle, est open-source (je sais pas sous quelle license).

              il n'y a aucune couche de compatibilité: ils ont simplement ecrit un peu de glue pour avoir accces aux fonctions du noyau.

              cette glue est regulierement cassee par les changements upstream du noyau

      • [^] # Re: Ça commence par les pilotes de cartes graphiques...

        Posté par  . Évalué à 3.

        Et le microcode de ton processeur il est libre ?
        Et ton BIOS ?
        Et le code du contrôleur de ton disque dur ?
        Et celui de ton CDROM ?
        Et celui de ton graveur ?

        Du code il y en a une floppée dans une machine, il n'y a pas que ce qu'on charge quand on l'allume, il y a beaucoup de trucs embarqués aussi. Là curieusement personne ne râle. "Ouin, le BIOS de ma carte SCSI il est pas libre, je peux pas le patcher, elle envoie peut-être les photos de ma copine à Bill Gates dans mon dos".

        Tes exemples sont dérisoires : tu ne parles que de code soit ne tournant pas sur le processeur central, soit ne tournant pas en meme temps que linux sur le processeur central. Aucun de tes exemples ne pourri le noyeau...

        Beaucoup de personne accepterait que le code embarqué de la carte graphique soit fournis sans les sources, tant qu'on ait avec ce code les spécifications pour utiliser ainsi la carte (et des drivers proprio uniquement pour Linux sur x86 pour te faire plaisir)

        tu profites des jolies images.
        Le gas qui a un Mac sous linux il va avoir du mal (il doit emuler le proc ?)

        • [^] # Re: Ça commence par les pilotes de cartes graphiques...

          Posté par  . Évalué à 1.

          Qu'est-ce que ça change que le code tourne en même temps que le noyau ? C'est du code qui est suceptible d'interférer avec tes données et la liberté que tu as de les utiliser comme bon te semble. Et dans la mesure où tu ne le contrôle pas, tu perds une partie de ton contrôle sur les libertés en question.

          Le noyau n'a rien à voir là dedans. Le jour où le BIOS refusera de démarrer un OS qui ne sera pas signé, tu seras quand même bien avancé avec ton noyau "pur".

          Quand au problème du peu de plateformes supportées par les pilotes propriétaires, c'est un autre problème auquel je suis parfaitement sensibilisé, n'utilisant pas que du x86 (et même là, voir le bordel des qu'on sort des sentiers battus, sur AMD64 par exemple).

          C'est aussi un problème pour les petites applications gratuites un peu incontournables comme acroread, flash, la jvm, etc. Dans ces cas là, pour beaucoup il ne reste malheureusement souvent que l'émulation. C'est l'inconvénient de sortir du lot...

  • # Effet Siggraph

    Posté par  . Évalué à 1.

    J'imagine qu'une sortie de pilotes quelques jours avant le début de la conférence ACM Siggraph (la plus grosse conf de l'année sur la synthèse d'image) n'est pas une coïncidence...

    http://www.siggraph.org/s2004(...)

  • # Problème de stabilité : quelque un a le même ?

    Posté par  . Évalué à 1.

    Bonjour,

    j'avais téléchargé de driver juste avant cette version. J'utilise un noyau 2.4.24 sur une distribution SuSE 9.0 avec Xfree 4.2.99-XXXX

    En installant les drivers Nvidia, tout va bien. Au niveau performance c'est le top (d'ailleurs Nvidia sont trres fort sur Linux à ce jeu là)

    Cependant j'ai des freezes systèmes mais dans des conditions particulieres :
    - Quand j'utilise Netscape 7.1
    - Quand j'utilise amsn


    Sinon pas de freeze ! Je me dis que ces applications doivent faire appels à des routines particulieres sur Xfree pour provoquer ces plantages.

    Quelqu'un a t-il eu le même problème ?

    • [^] # Re: Problème de stabilité : quelque un a le même ?

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

      À une époque, j'avais eu ce problème (plus étrange encore encore : certains javascripts faisaient planter X avec Konqueror) et c'était lié à l'accélération de Render, en général considérée comme buggée. Essaie peut être de mettre "RenderAccel" à 0 dans ton XF86Config ?
      Sinon, je rapelle juste qu'il ne faut pas utiliser le framebuffer nvidia avec le driver propriètaire.

      Ce que tu peut faire, c'est essayer avec le driver libre par aquis de conscience et si ça plante qu'avec le driver propriétaire, faire un rapport de bugs chez nvidia.

  • # support chez ATI.COM

    Posté par  . Évalué à 0.

    ils risquent pas d'avoir beaucoup de retour d'utilisateurs avec un message pareil

    Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

    [Microsoft][ODBC SQL Server Driver][SQL Server]INSERT statement conflicted with COLUMN FOREIGN KEY constraint 'FK_Customer_Processor'. The conflict occurred in database 'linuxDriver', table 'Processor', column 'kprocessor'.

    /linuxDfeedback/datasource.asp, line 75


    Surtout après avoir gentiment rempli tout leur formulaire....

  • # Pas que pour la 3D

    Posté par  . Évalué à 1.

    Ben moi non plus je n'aime pas les pilotes proprio mais je n'ai jamais pu faire fonctionner le twinview sans ces pilotes !

Suivre le flux des commentaires

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