Journal Pilotes graphiques libres Intel : et les performances?

Posté par  .
Étiquettes : aucune
0
13
oct.
2006
Bon, j'ai eu l'occasion d'approfondir mon état des lieux des pilotes pour nos chères cartes graphiques 3D : j'ai eu entre les mains un portable à base d'Intel I915GM. J'ai donc voulu voir l'amélioration de performances par rapport au I810 que j'ai essayé quelques temps plus tot : http://linuxfr.org/~Zezinho/21904.html .

Et bien ça empire : en réglage graphique par défaut : 38,7 fps sous Linux Mandriva 2007, 141,8 pour Windows XP! En qualité maximale, 1024x768 : 15 fps pour linux, 52 fps pour windows.

Bref, oui, Intel fournit des pilotes libres, mais fournissant 30% des performances des pilotes pour windows. Et de très mauvaise qualité : j'ai eu plein de blocages de X pendant mes tests, à chaque changement de résolution dans Quake. D'après les infos glanées sur le net, les pilotes Intel sont libres, mais il manquerait certaines spécifications pour le matériel. Et surtout des développeurs compétents qui s'intéressent au sujet.

PS: je mets ça en première page car ça relativise pas mal le mythe "Intel travaille bien dans le libre".

  • # ATI 7500

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

    J'avais lu qq part que le meilleur support 3d libre était pour l'ATI 7500.

    Si tu as une machine comme ça, je serais curieux de voir la différence entre linux et windows.

    "La première sécurité est la liberté"

    • [^] # Re: ATI 7500

      Posté par  . Évalué à 10.

      Bah putain, une carte disparue depuis 4 ou 5 ans maintenant, elle est belle la 3D sous linusque.


      (je pense en fait que le site ou tu as lu ça est très pas à jour)

    • [^] # Re: ATI 7500

      Posté par  . Évalué à 4.

      J'ai une 7500 sur mon portable et ça dépend des applis. Quake (et tous les jeux basés sur les moteurs des Quake) est aussi rapide que sous Windows. Mais UT ou Google Earth par exemple sont plus lent sous Linux et ont tendance à avoir des textures bizarroïdes du plus mauvais goût. Je crois que ça vient d'un problème de brevets sur une technique de compression de textures qui du coup n'est pas supportée par les drivers libres sauf en appliquant un patch particulier.

  • # Question d'interprétation

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

    Bref, oui, Intel fournit des pilotes libres, mais fournissant 30% des performances des pilotes pour windows. Et de très mauvaise qualité

    Est-ce que c'est ça qu'il faut déduire de tes mesures, ou bien faut-il s'interroger plutôt sur les performances intrinsèques de Linux en matière graphique ? Parce que, libres ou pas, et venant des constructeurs ou pas, j'ai bien l'impression que c'est toujours la même histoire avec les pilotes graphiques. Alors, on peut toujours crier au complot anti-linux mais cette hypothèse implique quand même malveillance ou mauvaise foi des constructeurs et/ou incompétence des développeurs généralisées. Ca fait beaucoup. Une explication plus simple serait que développer des drivers pour Windows est bien moins compliqué et que l'OS offre plus de performance au niveau de sa couche graphique.
    Enfin je dis ça, je ne dis rien.

    • [^] # Re: Question d'interprétation

      Posté par  . Évalué à 9.

      C'est peut-être aussi que pour 2 devs de pilotes sous X, on n'en trouve 200 sous Windows?

      • [^] # Re: Question d'interprétation

        Posté par  . Évalué à 10.

        ça c'est directXement lié au fait que pour 2 utilisateurs linux, on en trouve 200 sous windows...

        • [^] # Re: Question d'interprétation

          Posté par  . Évalué à 3.

          En fait rien n'est moins sûr car il serait légitime de penser que la proportion de programmeurs est bien plus importante sur Linux que sur Windows.

          • [^] # Re: Question d'interprétation

            Posté par  . Évalué à 2.

            Je ne vais pas languedeputifier et dire que question proportion, c'est aussi peut-être pour ça que Linux a du mal à s'imposer au grand public.

    • [^] # Re: Question d'interprétation

      Posté par  . Évalué à 10.

      Est-ce que c'est ça qu'il faut déduire de tes mesures, ou bien faut-il s'interroger plutôt sur les performances intrinsèques de Linux en matière graphique ?

      En l'occurence pour ce qui est de l'acceleration 3D, on se moque un peu de savoir ce que vaut l'OS sous jacent. Pour faire de l'accceleration 3D il faut
      a) Créer un buffer (Un contenu de fenetre noir) et chopper le pointeur du début du buffer (et enventuellement les dimension de la fenetre dans laquelle il se trouve)
      b) Ne plus jamais toucher au buffer jusqu'à fermeture de la fenetre
      c) Envoyer l'adresse du buffer suivie des commandes OpenGL à la puce 3D

      C'est assez proche des techniques d'overlay (la couleur de référence en moins). Bref une fois qu'on a réussi à ouvrir un display OpenGL (la fenetre noire), tout le reste au niveau graphique c'est du ressort de la carte 3D. On lui balance les instructions OpenGL et elle se débrouille.

      Bon c'est pas complètement vrai car il y a toujours des fonctions qui obligent à faire des aller-retours avec le processeur, mais pas d'interaction (ou le moins possible) de l'OS ou du serveur X avec le display OpenGL. Donc l'influence de la qualité des apis graphiques sur l'affichage 3D en OpenGL est très réduit.

      • [^] # Re: Question d'interprétation

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

        Pourquoi alors sur ma nvidia avec les drivers proprios nvidia, mon CPU est-il utilisé à 100% quand je fais un glxgears ? (question sincère ?)

        PS : j'ai une GeForce4MX de merde, mais vraiment de merde.

        Mes livres CC By-SA : https://ploum.net/livres.html

        • [^] # Re: Question d'interprétation

          Posté par  . Évalué à 10.

          La GeForce4MX est une carte qui s'appuie ennormément sur le CPU pour pouvoir avoir accès aux fonction "haut niveau" en OpenGL.
          Seulement sur les cartes modernes (les cartes avec shaders) il est nettement plus rentable de transformer toutes les fonctions, même les fonctions de base en fonctions shaders ou T&L haut niveau.
          Le problème est que comme les drivers nvidia sont "unifiés" sur cette carte, et pour la geforce 4MX le driver se comporte comme si il avait à faire à une geforce 4 donc il transforme les fonctions basique en commandes T&L haut niveau vu que la geforce 4MX indique qu'elle les supporte. Et paf.

          Comme glxgears tourne le plus vite possible et qu'il ne demande ni des textures monstrueuses ni une puissance en vertex faramineuse (euphemisme quand tu nous tiens) c'ets le CPU qui se trouve à convertir les instructions simples en T&L avant d'en refaire des instructions simples derrière.

          C'est aussi pour ce genre de choses que j'aime bien les dirvers proprios

          • [^] # Re: Question d'interprétation

            Posté par  . Évalué à 6.

            Le problème est que comme les drivers nvidia sont "unifiés" sur cette carte, et pour la geforce 4MX le driver se comporte comme si il avait à faire à une geforce 4 donc il transforme les fonctions basique en commandes T&L haut niveau vu que la geforce 4MX indique qu'elle les supporte. Et paf.

            Heu, si tu regardes les taces qui ont été faites pour le projet nouveau, tu veras que les geforce 4MX se comporte comme des geforce 1 améliorée. Après tout G4 MX = NV17 et G1 = NV10, elles font toutes les 2 parties de la famille NV1x.

            Par contre effectivement les Geforce 4 MX sont loin d'implementer tout OpenGL et une emulation par le CPU est necessaire.


            PS : pour le post du dessus sur le fonctionnement de la 3D.
            C'est un peu plus compliqué que ça quand il y a plusieurs applis qui veullent faire de la 3D en même temps. Il y a tout un système de lock sauf pour les cartes comme nvidia qui permette d'avoir plusieurs queues (et qui comme un OS font des 'contect switch' entre ces queues).
            Donc les performances peuvent dependre fortement du driver. Sans compter qu'aucune carte grand publique n'implemente totalement opengl et il faut soit emuler les commandes sur le CPU soit les convertir en sous commandes supportées par la carte.

            • [^] # Re: Question d'interprétation

              Posté par  . Évalué à 5.

              Non pas tout à fait. Les GeForce 4 MX sont des versions améliorés des GeForce 2 MX qui étaient les versions spéciales pauvres des GeForce 2 dont le nom de code était nv15. Après, on peut effectivement concèder que les nv15 étaient des versions très améliorées des GeForce 1, c'est à dire sans changement fondamental d'architecture mais tout de même largement plus rapide. Et l'abbréviation pour les GeForce, c'est GF et pas G plus un nombre sans quoi on pourrait confondre avec le nom commercial des PowerPC chez Apple.

            • [^] # Re: Question d'interprétation

              Posté par  . Évalué à 2.

              Heu, si tu regardes les taces qui ont été faites pour le projet nouveau, tu veras que les geforce 4MX se comporte comme des geforce 1 améliorée. Après tout G4 MX = NV17 et G1 = NV10, elles font toutes les 2 parties de la famille NV1x.

              Ca c'est du point de vue du hardware, et nous sommes tout à fait d'accord. Les Geforce 4MX sont des Geforce de base avec deux trois wrappers sur les fonctions T&L. Dans 90% des cas elles se font plier par les Geforce 2MX.

              Cependant le pilote NVidia lui voit une révision "machintruc" et se comporte comme si il avait affaire à une vrai Geforce4....

              C'est un peu plus compliqué que ça quand il y a plusieurs applis qui veullent faire de la 3D en même temps. Il y a tout un système de lock sauf pour les cartes comme nvidia qui permette d'avoir plusieurs queues (et qui comme un OS font des 'contect switch' entre ces queues).

              Ca c'est la théorie, c'est ce qui se passe sur les cartes un peu péchue (wildcats, quadro, firegl etc.) mais sur une geforce de base (même une 7800XT pro platinum turbo) ce qui va se passer est simplissime : la deuxième appli a vouloir faire de l'OpenGL sera bonne pour se contenter d'un rendu software.Les pipelines de rendus T&L et les shaders ne sont pas assez indépendants pour que l'on puisse faire 'moitié - moitié' donc une fois un display accéléré 3D déclaré, c'est mort pour les autres. C'est d'ailleurs la raison pour laquelle Vista n'aura aucun support OpenGL, comme tout windows est en DirectX10 il est éventuellement possible d'insérer une fenêtre avec un rendu DirectX dans le bureau, mais pour l'OpenGL c'est mort. A l'heure actuel les brutes d'OpenGL.org essayent de voir si il sera possible de faire un pilote OpenGL quand même, mais ca sera du full-screen uniquement....

              • [^] # Re: Question d'interprétation

                Posté par  . Évalué à 2.

                Tu m'étonnes !

                Sous un OS propriétaire avec un bureau accéléré 3D, je peux jouer à des jeux en 3D en mode fenêtré ET avoir mon joli bureau accéléré en 3D.

                Pourtant je n'ai qu'une carte graphique relativement bas de gamme (Radeon 9200).

                BeOS le faisait il y a 20 ans !

              • [^] # Re: Question d'interprétation

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

                Bon je veux pas dire mais t'es légerement à côté de la plaque :)
                Déjà:
                Les quadro ne sont que des GeForce normal, avec un peu plus de connectique, et des drivers qui s'arrant pour paraitre plus mieux que les GeForce :)
                Après il y a de nombreux contexte de disponible (32 de mémoire, mais je sais plus si c'est une limitation de la carte, ou des drivers),
                la carte graphique de ce que j'ai compris a un context switcher (par défaut automatique mais qu'on peut personnaliser).
                Sinon le problème de DirectX10/OpenGL, doit être au niveau de DirectX10 qui doit demander toutes les ressources à la carte graphique (vu qu'on y arrive tres bien avec beryl + n'importe quel jeu 3D, et que (à ce que je sache) on peut lancer une appli DirectX (pas 10) et une appli OpenGL en même temps)

                PS:Suivre l'évolution de nouveau est TRÈS intéressante (voir http://nouveau.freedesktop.org/wiki/IrcChatLogs si ca vous intéresse)

          • [^] # Re: Question d'interprétation

            Posté par  . Évalué à 2.

            J'ai aussi 100% de CPU utilisé par glxgears avec ma nVidia Corporation NV41.9 [GeForce Go 6800 Ultra] (rev a2). D'après ton post je crois deviner que ca ne devrait peut-être pas être le cas sur une carte aussi récente (drivers proprio 8762, 1920x1200, 32bits) ?

        • [^] # Re: Question d'interprétation

          Posté par  . Évalué à 4.

          glxgears s'amuse peut être à utiliser au maximum le CPU pour faire tourner le plus de fois par seconde la petite roue. Dans la plupart des applications 3D, on bloque le nombre d'images par seconde à 30, 60, 80, 100, etc. Le processeur est libre le reste du temps (pas d'appels aux fonctions opengl).

          • [^] # Re: Question d'interprétation

            Posté par  . Évalué à 2.

            Si le parallélisme est bien exploité et vu que le nombre de polygone est tellement bas que la CG risque pas de limiter, ça a du sens et en fait on peut pas en déduire quoique ce soit sur la conception du driver, bien ou mal fait...

        • [^] # Re: Question d'interprétation

          Posté par  . Évalué à 2.

          Le problème vient de toi ou, peut-être, des drivers proprio Nvidia.
          J'ai un chipset intégré intel sur mon portable qui est moins puissant qu'une gf4mx, glxgears me pompe 30% d'un Celeron M 1ghz4.

          Sinon, les perfs 3d de mon desktop nvidia me laissent penser que linux ne pose pas de problème particulier, en tout cas pas comparé à windows.

        • [^] # Re: Question d'interprétation

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

          Ben ça doit venir du while(1) dans la fonction event_loop() [1].

          Le programme n'arrête pas de bosser ; dès qu'il a fini de traiter une frame (rendu, gestion de l'input, calculs logiques), il recommence aussitôt, et ce jusqu'à la fin de son exécution... Comme dit plus haut, on ne limite pas le nombre de frames par seconde.

          Essaie un « while(1) ; » dans un petit main() vide (rien d'autre à part le while), tu verra ça fera la même chose.

          [1]: http://cvsweb.xfree86.org/cvsweb/xc/programs/glxgears/glxgea(...)

  • # Gros avantage de Linux : la réactivité....

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

    C'est pour cela que je suis coincé depuis le 23 Septembre, et que je suis obligé de travailler en mode dégradé, car la dernière mise à jour du driver a tout cassé...

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391494

    • [^] # Re: Gros avantage de Linux : la réactivité....

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

      dur, ça. Tu es obligé de rester avec un OS qui date du 23 septembre 2006.
      Mais pense à tous ces pauvres gens qui sont obligé de rester sous un OS qui date de 2001, et qui en plus est proprio.

      • [^] # Re: Gros avantage de Linux : la réactivité....

        Posté par  . Évalué à 7.

        Tu veux parler des personnes ayant acheté des Mac hors de prix et qui ne peuvent plus les mettre à jour avec les derniers OS-X ?

        • [^] # Re: Gros avantage de Linux : la réactivité....

          Posté par  . Évalué à 3.

          Les plus malins auront fait un alienswitch que Steve y peut même pas comprendre vers un OS qui les affranchit de ce type de problème : un système libre...

          Minute défouloir : pour les autres : qu'ils crèvent :-)
          Merci.

      • [^] # Re: Gros avantage de Linux : la réactivité....

        Posté par  . Évalué à 4.

        Si tu parles de Windows, c'est un argument spécieux, car dans ta logique, l'OS date de sa dernière mise à jour et la dernière mise à jour de Windows, c'était mardi dernier...

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

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

          • [^] # Re: Gros avantage de Linux : la réactivité....

            Posté par  . Évalué à 2.

            Les pilotes ATI dispo sur leur site n'ont pas les fichiers inf nécessaires pour s'installer sur les portables IBM.

            Récupère les pilotes Omega => http://www.omegadrivers.net

          • [^] # Re: Gros avantage de Linux : la réactivité....

            Posté par  . Évalué à 3.

            J'ai aussi une version OEM de Windows et cela ne m'empêche nullement de mettre à jours Windows via le Windows ou le Microsoft Update fourni avec. C'est un problème de driver, pas de mise à jour de Windows à proprement parler. A noter que les fabricants de processeurs graphiques commencent à prendre conscience du problème et à penser à faire des drivers prenant en charge les portables.
            Quand à l'absence de véritable support physique pour l'OS, c'est une mesquinerie sans nom que je réprouve autant que quiconque et qui fera un facteur particulièrement discriminant si jamais je venais à me payer un portable.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

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

              • [^] # Re: Gros avantage de Linux : la réactivité....

                Posté par  . Évalué à 2.

                Pour clarifier les choses, quand je parlais de mises à jour, je parlais des mises à jours de Microsoft pour son OS, par exemple celles qui apparaissent tous les seconds mardi du mois sur le site de Windows Update, pas des drivers des différents périphériques. Enfin moi je ne vois pas pourquoi le constructeur s'emmerderait à fournir son propre Windows Update alors que Microsoft le fait très bien.
                De toutes façons, pour ces drivers là, il vaut mieux aller chez le constructeur, au moins pour la carte graphique.

  • # Pas d'accord

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

    Salut !

    Alors, je pense que c'est TRES dépendant du programme, et comment sont utilisé les fonctions 3D:

    - Avec un Xorg 6, avec une installation Ubuntu 5 j'avais un glxgears qui montait à plus de 1000 fps.
    - ensuite, avec le temps ca s'est effectivement dégradé, jusqu'a descendre à pratiquement 30fps sur Xorg 7/Dapper.
    Mais c'est pas pour autant que les jeux étaient impactés, Q3 ou Nexuiz marchais toujours comme avant (c'est a dire pas très vite)
    - J'ai installé XGL, c'etait une catastophe avec certaines options, mais utilisable avec d'autres (ne PAS mettre de Blur, par exemple)
    - Par contre, j'ai installé AIGLX, et ca marche très bien, l'outil qui viens avec me donne + de 100fps en permanence. Sur cette config en revanche glxgears rame à 12fps et plante le serveur X en 10 secondes.

    Donc, je pense vraiment que il y a énormément d'options de configuration et de compilation qui jouent sur ces drivers, étant donné que la partie noyau (DRI) a très peu changé en 1 an (je ne sais pas trop pour la partie drivers X, j'utilise toujours la version du serveur des repository).
    si ca se trouve, la libGL n'ayant pas évoluée, c'est elle qui est en retard.

    Il est possible qu'il devienne a terme nécéssaire de devoir bien bricoler la library libGL pour utiliser a fond le serveur X.
    mais ca me partait encore un peu tot.

    Voila !
    my 2cents

    • [^] # Re: Pas d'accord

      Posté par  . Évalué à 9.

      Ca vient aussi peut être du fait que glxgear est tres tres loin d'etre un bench pour carte graphique , c'est tout au plus un soft qui permet de voir si opengl fonctionne en hard ( ou en soft d'ailleurs ) , specviewperf est lui , un vrai bench OpenGL , ca me fait bien rire les concours de bi** a coup de glxgears...

      • [^] # Re: Pas d'accord

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

        apt-get install specviewperf :
        E: Impossible de trouver le paquet specviewperf

        Effectivement c'etait plutot une idée globale que je voulais, pas un test complet.
        C'est plutot l'utilisation au quotidien et le "feeling" plutot que les performances chiffrées qui m'interessent. En ce sens, glxgears me parait bien.

        On teste avec les outils qu'on a...

        (maj: en fait, c'est le Windows Manager Beryl qui met la foire.
        Dès qu'on reviens a Metacity, glxgears marche mieux)

        ob

  • # Es-tu certain de tester le bon pilote ?

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

    Je ne suis pas certain que le pilote d'intel du i915 soit intégré à la dernière version de X11R7.1 ? En tout cas je ne le vois pas dans les notes de diffusion de X11R7.1 ( http://ftp.x.org/pub/X11R7.1/doc/RELNOTES3.html#6 ) et ni dans les souces http://ftp.x.org/pub/X11R7.1/src/driver/ ?

    D'un autre côté X11R7.1 a été diffusé le 22 mai 2006 et l'annonce de Keith Packard sur la liste de diffusion de freedesktop date du 9 août 2006.

  • # Oui intel travail avec le libre

    Posté par  . Évalué à 7.

    Intel non seulement fournis les specifications aux developpeurs mais en plus elle les paye. Apres intel n'est pas tout rose, notament sur ses chipset wifi.

    Pour la performance des drivers sous linux j'y vois plusieurs explications. Ces derniers temps les developpeurs s'occupe du 'gestionnaire de memoire" car aussi etonnant que cela puissa paraitre actuellement la memoire video est gere de maniere ad-hoc et ca ressemble a un bricolage. Donc 90% des commits sur les drivers 3d et pour intel s'effectuent sur cette branch.

    Autre explications possible, il me semble que sous linux une des fonctionnalitee de la carte n'est pas utilise (impossible de me souvenir du nom mais ca a rapport avec la memoire et la possibilite de faire des trucs "intelligent" avec, seulement ca semble pas exploitable avec sans le gestionnaire dont je parle plus haut).

    Dernier point, la configuration par defaut sous linux est tres conservative et aura surement tendance a brider les performances. Je te conseil donc d'augmenter la taille de memoire allouer a ta carte graphique, notament la memoire agp. Regarde aussi ce que propose driconf comme option pour ta carte.

    Au passage le chipset intel X3000 (dans les chipset 965) a l'air d'avoir des performances plus qu'honorable et semble capable de rivaliser avec les derniers chipset moyen de gamme de la concurence.

    http://www.oakcourt.dyndns.org/~andrew/x3000_benchmark.html

    • [^] # Re: Oui intel travail avec le libre

      Posté par  . Évalué à 1.

      L'ennui, c'est que sans les chiffres des autres chipsets et surtout des véritables cartes graphiques, on ne peut pas trop se faire une idée. D'autant plus que le jeu testé a environ deux ans et demi largement tapés et que l'on ne peut pas dire que techniquement il soit le plus demandeur de ressources à l'heure actuelle. Et que le moteur n'est d'ailleurs même pas de génération DirectX 9, mais 8, ce qui enlève encore quelques rafinnements graphiques divers et variés mais qu'il convient désormais de mesurer puisque c'est que la majorité des jeux vont demander à l'avenir.

Suivre le flux des commentaires

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