MesaMatrix pour suivre les progrès de Mesa

Posté par  . Édité par ZeroHeure, Davy Defaud, Xavier Teyssier, NeoX, tuiu pol et palm123. Modéré par tuiu pol. Licence CC By‑SA.
57
3
sept.
2014
Noyau

À chaque fois que je lis les dépêches LinuxFr.org sur le nouveau noyau ou bien les nouvelles de Phoronix, je m’empresse de regarder les avancées des pilotes graphique libres. Et souvent, je vais sur la page Mesa traçant les évolutions de l’implémentation d’OpenGL. Mais je trouve difficile de suivre où en est réellement la progression de cette adaptation dans Mesa et de ses différents pilotes graphiques qui en dépendent. C’est pourquoi j’ai décidé de faire un script qui parcourt ce fichier et l’affiche de manière plus intelligible.

 http://mesamatrix.net/

Si vous adorez suivre la course qui se tient entre Mesa et OpenGL, et que vous allez souvent voir quelles sont les nouvelles extensions OpenGL qui ont été implémentées et pour quels pilotes, ça pourrait vous intéresser ! Plus d’explications dans la suite de la dépêche.

MesaMatrix

MesaMatrix est écrit majoritairement en PHP pour récupérer le fichier texte source, le parcourir et afficher le tout au format HTML. Il y a aussi un peu de CSS et de JavaScript (néanmoins, pas obligatoire pour que le site fonctionne). Et, parce que je crois dur comme fer au mouvement Libre, le tout est mis sous licence GPL v3.

Le fichier texte source n’étant pas spécialement formaté pour être parcouru par un script, il a fallu quelques commits avant d’avoir une page fonctionnelle, mais fort heureusement des personnes ont rapportés les bogues et Tobias Droste a même proposé des pull requests pour peaufiner tout ça.

Récemment, j’ai rajouté des compteurs pour savoir où en est l’implémentation d’OpenGL dans Mesa, ainsi que dans chaque pilote.

Intérêt

Grâce à ce projet, j’ai pu mieux comprendre comment était structuré l’implémentation de Mesa et de ses pilotes. Et j’espère que cela pourra aider d’autres personnes à comprendre.

Maintenant, nous avons un moyen simple de suivre l’évolution de Mesa. Nous voyons plus clairement le chemin parcouru et celui qu’il reste à faire avant d’avoir une version complètement fonctionnelle d’OpenGL 4.5.

On peut voir qu’à ce jour, il ne reste plus que trois extensions à implémenter dans Mesa pour qu’OpenGL 4.0 soit complet. Et ensuite, nous sommes à seulement trois autres extensions pour arriver directement à OpenGL 4.2. Cependant, il va rester encore pas mal de travail pour implémenter ces extensions dans chaque pilote.

Parlant des pilotes, c’est souvent assez confus de savoir qui fait quoi. Les pilotes intitulés softpipe, swrast et llvmpipe sont dit logiciels (software), car ils ne dépendent d’aucun matériel. À l’inverse, les pilotes i965 (Intel), nv50 et nvc0 (NVIDIA), et r300, r600 et radeonsi (AMD) sont dits matériels (hardware), car dépendant de puces graphiques bien précises.

Vous voulez participer ?

Aucun souci ! Que ce soit pour des suggestions de nouvelles fonctionnalités, des découvertes de bogues ou même des pull requests, le projet est sur GitHub ; vous pouvez en faire ce que vous voulez (dans la limite de la licence GPL v3 évidemment. ;))

Aller plus loin

  • # définition ?

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

    Ou sont les définitions du nom des colonnes ? ( mesa softpipe swrast llvmpipe i965 nv50 nvc0 r300 r600 radeons )

    Il semble s'agir de chipset ou des technos, mais plus précisément ?

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

    • [^] # Re: définition ?

      Posté par  . Évalué à 3.

      Je pense que ça fait référence aux modules Kernel.

      • [^] # Re: définition ?

        Posté par  . Évalué à 1.

        Presque, mais pas du noyau. Si j'ai bien compris, ça fait référence aux drivers que la libGL charge pour l'infrastructure de rendu matériel Direct_rendering_infrastructure.

        • [^] # Re: définition ?

          Posté par  . Évalué à 2.

          Le problème c'est qu'il y a au moins de modes : Gallium3D (le mieux++) avec KMS et DRI, avec DRM.

          Gallium3d à aussi l'avantage d'avoir les pilotes softpipe et surtout LLVMpipe (qui permet de faire un rendu efficace au CPU quand on pas de GPU), et visiblement a inspiré par les avancées dans l'organisation du pilote, Mantle d'AMD (qui est plus rapide que les autres avec rendu matériel du coup), qui a à son tour inspiré OpenGL (et ES) Next, qui sera à son tour dans Mesa :) et Direct3D 12 (mais on s'en fout de ça).

        • [^] # Re: définition ?

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

          C'est ça, mais ça répond pas trop à la question originale ;)

          Alors, je suis pas dev mesa mais ça devrait être assez proche de la réalité.

          Gallium3D est une architecture virtuelle de GPU qui permet d'écrire de représenter les implémentations OpenGL/CL, accel vidéo et tout ce qu'un GPU peut faire comme calcul (pas le rendu). En gros, ça permet de factoriser une bonne partie du code!

          Les pilotes dans mesa:

          • Mesa: Le code original de mesa. On appelle les pilotes qui dépendent que de mesa "DRI", mais c'est vraiment pour perturber le monde ;) Dans mesa, y'a la runtime et aussi la représentation intermédiaire pour les shaders qui est utilisée par Gallium (et transformée en TGSI).
          • swrast: Pilote DRI pour le rendu opengl sur CPU. C'est super lent!
          • softpipe: L'équivalent de swrast pour Gallium3D et c'est giga lent aussi. Ça sert juste à vérifier si des bugs sont dans le code commun ou pas.
          • llvmpipe: Équivalent de softpipe, sauf que les instructions TGSI sont converties en LLVM qui se charge de générer du code efficace pour le CPU. Ça donne des perfs relativement acceptables pour les environnements graphiques! Yeah!
          • i965: Le pilote graphique pour toutes les IGP Intel. Il utilise l'archi DRI, pas Gallium.
          • nv50/c0: Pilote Gallium3D pour les cartes nvidia. Nv50 = Geforce 8 jusqu'aux Geforce 4xx. Nvc0 = Geforce 4xx jusqu'aux Maxwell et possiblement les suivantes aussi :). Il y a aussi d'autres pilotes pour les cartes d'avant, mais elles supportent pas OpenGL3 ;) Un petit rappel sur les chipsets.
          • r300/r600/radeonSI: Comme pour NVIDIA, chaque pilote supporter de multiple générations et de temps en temps, l'architecture change tellement qu'il vaut mieux recommencer de 0 le backend gallium3D. Les chipsets pour AMD.

          J'espère que ça va vous aider un peu!

          • [^] # Re: définition ?

            Posté par  . Évalué à 3.

            Je suis pas dev mesa non plus, mais ça m'a l'air correct ;)

            Sinon pour de plus amples informations à propos de l'ensemble de la pile graphique Linux, il y a un article Wikipedia pour ça: Pile graphique Linux

            Mon script ne se veut pas non plus être une encyclopédie du noyau, mais je pourrais rajouter un lien…

            • [^] # Re: définition ?

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

              Je suis pas hyper fan des pages wikipedia. Faudra que je fixe ça un jour!

              Non mais sans rire, les mecs parlent encore de REnouveau, le truc qu'on a pas utilisé depuis presque 10 ans :D

              • [^] # Re: définition ?

                Posté par  . Évalué à 3.

                Être mis à jour, c'est aussi le but des articles Wikipedia, surtout pour des trucs qui bougent aussi vite que l'informatique ;)
                À la base, c'est moi qui avait lancé cet article et il a été très très largement amélioré par Antistress (qui devrait lire ces colonnes normalement ;)).

                Si tu t'y connais bien sur la pile graphique, je t'invite à améliorer l'article Wikipedia, ça intéressera toujours du monde (moi le premier!).

                • [^] # Re: définition ?

                  Posté par  (site web personnel) . Évalué à 10. Dernière modification le 03 septembre 2014 à 17:51.

                  Oh, je suis totalement d'accord, c'est pour ça que j'ai dit que je le ferai ;)

                  Et quant à connaître la pile graphique, je suis un développeur de Nouveau depuis 4 ans et je me tiens informé sur toute la pile graphique depuis (du coup, c'est pour ça que je contribue sur la partie DRM dans les dépêches du noyau). Et comme le boulot de la fondation X.org, c'est aussi de partager les connaissances, c'est mon boulot en tant que membre de la board de mettre à jour ce genre de source d'infos.

                  • [^] # Re: définition ?

                    Posté par  . Évalué à 2.

                    Je me disais aussi que ton nom me disait quelque chose! ;)

                  • [^] # Re: définition ?

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

                    c'est mon boulot en tant que membre de la board de mettre à jour ce genre de source d'infos.

                    rho la la faut pas dire ça, tu vas te retrouver aussi à faire actualiser http://dri.freedesktop.org/wiki/MissingFunctionality/ (dont certaines ont été implémentées depuis avril 2013 :D)

                    • [^] # Re: définition ?

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

                      Hey hey, y'a du boulot coté communication dans les projets de la fondation X.org! C'est clair!

                      Enfin bon, ma priorité reste d'aider au développement et essayer de faire venir plus de monde dans la pile graphique. Du, je relaye le travail actuel des membres sur G+, j'aide pour le GSoC et l'EVoC (programme équivalent au GSoC, mais financé par la fondation X.org et c'est pas limité à l'été), j'organise l'XDC2014 à Bordeaux cette année et je fais des présentations sur nos travaux dans Nouveau dès que je peux.

                      D'ailleurs, je serai à la kernel recipes à Paris en fin septembre, si ça intéresse des gens :)

                      • [^] # Re: définition ?

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

                        D'ailleurs, je serai à la kernel recipes à Paris en fin septembre, si ça intéresse des gens :)

                        c'est complet, va falloir soudoyer ennael pour faire venir plus de monde ;-)

                        RdV plutôt au Fosdem, ce serait bien de réclamer^Wrécupérer un amphi cette année, il y en a marre des salles trop petites :D (puis bon, vos démos se débugguent en live, tout comme celles de Meeks vous êtes prêts :p)

                        • [^] # Re: définition ?

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

                          c'est complet, va falloir soudoyer ennael pour faire venir plus de monde ;-)

                          Oh, je savais pas!

                          RdV plutôt au Fosdem, ce serait bien de réclamerWrécupérer un amphi cette année, il y en a marre des salles trop petites :D

                          Hey, on a eu un amphi de 200 personnes cette année! Et on l'a rempli plusieurs fois :)

                          (puis bon, vos démos se débugguent en live, tout comme celles de Meeks vous êtes prêts :p)

                          Tu serais pas en train de faire référence à ma démo de reclocking en 2012, si? :D

                          Plus sérieusement, faire des démos de trucs stables, c'est pas sport et pas fun du tout :D

                          • [^] # Re: définition ?

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

                            c'est complet, va falloir soudoyer ennael pour faire venir plus de monde ;-)
                            Oh, je savais pas!

                            ennael< l'a indiqué sur https://linuxfr.org/news/kernel-recipes-2014

                            Hey, on a eu un amphi de 200 personnes cette année! Et on l'a rempli plusieurs fois :)

                            oui, cela fait partie des «  petites » salles :-) (et oui, en tenant la porte ya moyen de passer le « videur » qui empêche de rentrer dans la salle surchauffée pendant que les autres sortent. Nan, je parle d'un des deux (trois ?) vrais amphis ;-)

                            Tu serais pas en train de faire référence à ma démo de reclocking en 2012, si? :D

                            si si, stait rigolo à voir ces fenêtres qui bougent (ya wayland qui a du potentiel aussite :p).

                            Plus sérieusement, faire des démos de trucs stables, c'est pas sport et pas fun du tout :D

                            Exactement, bravo pour tes interventions à chaque fois ; ton anglais est bien meilleur que le français moyen ;-) (oui, je vais aussi dans la dev room java^Wopenjdk ou gnome et libreoffice, j'aime bien passer du bon temps en Belgitie, pfiou depuis 7 ans maintenant o_O).

                            • [^] # Re: définition ?

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

                              oui, cela fait partie des «  petites » salles :-) (et oui, en tenant la porte ya moyen de passer le « videur » qui empêche de rentrer dans la salle surchauffée pendant que les autres sortent. Nan, je parle d'un des deux (trois ?) vrais amphis ;-)

                              Ah ah, je crois que tu sous-estimes la peur qu'ont certain pour présenter. 200 personnes, ça fait déjà pas mal! Et puis ça serait du gâchis étant donné que y'a pas moyen que ça intéresse autant de monde! :D

                              Exactement, bravo pour tes interventions à chaque fois ; ton anglais est bien meilleur que le français moyen ;-) (oui, je vais aussi dans la dev room javaWopenjdk ou gnome et libreoffice, j'aime bien passer du bon temps en Belgitie, pfiou depuis 7 ans maintenant o_O).

                              On fait ce qu'on peut ;) T'as de la chance d'y être allé 7 fois déjà! De mon coté, je suis pas sûr de pouvoir venir l'an prochain mais je ferai mon possible! Si tu me vois, vient dire bjour ;) C'est valable pour toutes les moules cela dit!

            • [^] # Re: définition ?

              Posté par  . Évalué à 3.

              Pour ce genre d'article, généralement je préfère allez voir les pages en anglais qui sont plus précises et à jour.

    • [^] # Re: définition ?

      Posté par  . Évalué à 2.

      Je suis un peu perdu avec le RadeonSI, est-ce que c'est le diminutif de «Radeon Southern Islands» ou «Radeon Sea Islands» ou les deux en même temps ? Et surtout, ou sont tous les chipsets intermédiaire (R700, Evergreen, Northern Islands) ?

      En fouillant un peu j'ai trouver ceci, planqué au milieu du tableau, pour les Radeon http://xorg.freedesktop.org/wiki/RadeonFeature/

      Mesa 3D features R100 R200 R300/R400 R500 R600/700 Evergreen N.Islands S.Islands1 C.Islands
      3D Driver radeon r200 r300g r300g r600g r600g r600g radeonsi radeonsi

      C'est plus pratique pour savoir où se trouve sa carte.

  • # Merci

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

    Merci, très simpa et claire.
    Je note que intel est en avance sur AMD…

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

    • [^] # Re: Merci

      Posté par  . Évalué à 3. Dernière modification le 03 septembre 2014 à 12:03.

      Ils ont beaucoup moins de gpu aussi et plus de moyens ($$$)

    • [^] # Re: Merci

      Posté par  . Évalué à 7. Dernière modification le 03 septembre 2014 à 12:29.

      Qu'est ce qu'ils ont tous avec cette Claire ? hmm peut-être qu'elle est sYmpathique.

      • [^] # Re: Merci

        Posté par  . Évalué à 1.

        Ça fait plaisir ;)

  • # Et du côté des SoC ARM ?

    Posté par  . Évalué à 6.

    Et les GPU des SoC ARM dans tout ça ?

    Freedreno (pilote Gallium3D) est inclus depuis au moins la 10.2.3, et {{refnec|je crois qu'un autre devait faire son apparition dans le git bientôt}} ?

    • [^] # Re: Et du côté des SoC ARM ?

      Posté par  . Évalué à 2.

      Quand le pilote apparaîtra dans le fichier original, je le prendrai en compte ;)

      • [^] # Re: Et du côté des SoC ARM ?

        Posté par  . Évalué à 4.

        Cool, merci, donc, il faut (encore) botter les dev pour qu'ils ajoutent un peu de doc :).

        Au passage, je vois que la partie OpenGL ES commence à 3.1, WebGL utilise OpenGL 2.0 (WebGL 2.0 utilisera OpenGL 3.0). Je me demande si on peut trouver des specs similaires pour OpenGL ES de la série 2, et pourquoi pas d'OpenGL ES 1.x aussi, qui ne traine pas les boulets d'OpenGL 1.x.

        Je pense que ça pourrait servir à la Mozilla fondation, à pas mal de developpeurs web, et aux libristes qui exigent un pingouin élevé en plein air ce genre d'infos.

        • [^] # Re: Et du côté des SoC ARM ?

          Posté par  . Évalué à 2.

          Je crois que Mesa ne s'occupe que de OpenGL à partir de la version 3.0.
          De toute façon les versions précédentes sont tellement différentes/désuettes à écrire… Maintenant les shaders c'est la base d'un moteur 3D, c'est pas une extension ;)

          Enfin je dis peut-être des conneries, mais c'est en tout cas ce que j'ai compris! ;)

      • [^] # Re: Et du côté des SoC ARM ?

        Posté par  . Évalué à 1.

        C'est VideoCore4 (gallium/drivers/vc4) de Broadcomm l'autre pilote GPU de SoC ARM au passage et il est déjà dans le tronc du git Mesa :).

    • [^] # Re: Et du côté des SoC ARM ?

      Posté par  . Évalué à 2. Dernière modification le 03 septembre 2014 à 15:35.

      Ah oui et j'ai aussi entendu parlé d'un "Big driver" pour AMD, mais j'ai pas réussi à retrouvé la source, donc j'ai préféré ne pas le mettre dans l'article. Mais je suis sûr d'avoir lu qu'un gars était en train de rassembler les trois drivers d'AMD en un, afin de factoriser un peu mieux le code et de pouvoir même profiter des optimisations de compilation au link.

      • [^] # Re: Et du côté des SoC ARM ?

        Posté par  . Évalué à 5. Dernière modification le 03 septembre 2014 à 19:38.

        Tu dois sûrement parler de Megadrivers.
        C'est pas seulement pour les pilotes AMD, tous les pilotes Mesa sont concernés. Ça a été proposé par Emil Velikov (le nouveau mainteneur du projet Mesa) et visiblement c'est mergé depuis début juillet 2014. Je n'ai jamais essayé de voir comment ça marchait, je compile toujours mon pilote r600g indépendamment du reste personnellement (enfin comme avant quoi).

        • [^] # Re: Et du côté des SoC ARM ?

          Posté par  . Évalué à 2.

          Ah vi c'est ça! C'est Mega, pas Big!
          Si ça concerne tous les pilotes, ça fait un peu peur… Est-ce que ça ne risque pas de nuire à la maintenabilité du code? On se souvient tous de XFree86 qui était un énorme bloc monolithique imbitable (bon, Xorg, c'est mieux, mais y a du boulot encore ;)).

          • [^] # Re: Et du côté des SoC ARM ?

            Posté par  . Évalué à 3.

            Attention, ce n'est pas du tout une mutualisation du code !

            Actuellement quand tu compiles Mesa, tu obtiens plusieurs fichiers .so (l'équivalent des .dll Windows). Ce sont notamment la libGL.so et les pilotes en eux-mêmes : r600_dri.so, radeonsi_dri.so, vmwgfx_dri.so, i965_dri.so, etc.

            Et en fait chaque pilote (fichier .so) contient beaucoup d'informations partagés. Donc c'est de l'espace disque inutile gâché en quelques sorte.

            Avec Megadrivers, si j'ai bien compris, au lieu d'avoir un fichier .so par pilote, il n'y aura qu'un seul fichier .so avec tous les pilotes dedans.

            Mais surtout le plus intéressant pour nous, c'est qu'en rassemblant tout dans le même fichier .so, la compilation est légèrement optimisée (donc très léger gain de performance).

            • [^] # Re: Et du côté des SoC ARM ?

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

              Et en fait chaque pilote (fichier .so) contient beaucoup d'informations partagés. Donc c'est de l'espace disque inutile gâché en quelques sorte.

              combien de place disque prise ? (avant / après)

              Mais surtout le plus intéressant pour nous, c'est qu'en rassemblant tout dans le même fichier .so, la compilation est légèrement optimisée (donc très léger gain de performance).

              ça prend combien de temps à compiler ? (sur quel type de matos ?). Pas les deux heures de LibreOffice.org pour ceux ayant 4 Go de RAM et plus de 20 Go de swap, j'imagine… !?

              • [^] # Re: Et du côté des SoC ARM ?

                Posté par  . Évalué à 4.

                Je me corrige, c'est Eric Anholt, quand il travaillait encore chez Intel, qui a amené ce projet sur la table. Mais il ne s'était préoccupé que de la partie DRI (pas Gallium). Et c'est Emil Velikov qui a finalisé le projet sur la partie Gallium.

                combien de place disque prise ? (avant / après)

                Je crois que c'est de l'ordre de 4 Mo par pilote.

                ça prend combien de temps à compiler ? (sur quel type de matos ?). Pas les deux heures de LibreOffice.org pour ceux ayant 4 Go de RAM et plus de 20 Go de swap, j'imagine… !?

                La compilation est pas plus longue.
                Actuellement pour compiler r600g sur mon PC (Core i5-2500K) ça mets genre une minute avec "make -j4".

                • [^] # Re: Et du côté des SoC ARM ?

                  Posté par  . Évalué à 4.

                  Je crois que c'est de l'ordre de 4 Mo par pilote.

                  Euh en fait je viens de regarder mon fichier r600_dri.so et je passe plutôt de 33 Mo à 5,7 Mo !

                  • [^] # Re: Et du côté des SoC ARM ?

                    Posté par  . Évalué à 4.

                    Oubliez ce que je viens de marquer, je crois que les 33 Mo sont du au fait que que j'avais compilé avec les options de debug.

                • [^] # Re: Et du côté des SoC ARM ?

                  Posté par  . Évalué à 1.

                  Je me corrige, c'est Eric Anholt, quand il travaillait encore chez Intel, qui a amené ce projet sur la table. Mais il ne s'était préoccupé que de la partie DRI (pas Gallium). Et c'est Emil Velikov qui a finalisé le projet sur la partie Gallium.

                  J'ai pu retrouvé l'article Phoronix où j'avais lu ça, par contre ça semble être Marek Olšák qui a fait le patch:
                  http://www.phoronix.com/scan.php?page=news_item&px=MTY5MTA

                  • [^] # Re: Et du côté des SoC ARM ?

                    Posté par  . Évalué à 2.

                    Ah visiblement Marek a du travailler sur "MegaRadeon" mais Emil travaillait déjà sur un "Megadrivers" (qui comprend tous les pilotes et pas seulement les Radeon). Le travail d'Emil a été commité mais du coup je ne pense pas celui de Marek vu qu'il était moins complet que celui d'Emil.

            • [^] # Re: Et du côté des SoC ARM ?

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

              Oui mais cela prends plus de RAM donc tu perds un peu en performance et ayant tout le code, tu as aussi tous les bogues… Pas sur que la performance et la sécurité y gagne au final.

              • [^] # Re: Et du côté des SoC ARM ?

                Posté par  . Évalué à 5.

                Marek Olsak (développeur AMD) : "I think most people don't get that the primary reason for the "megadrivers" is that it improves performance in CPU-bound apps. All the other reasons are not so important for developers to waste time on."

                • [^] # Re: Et du côté des SoC ARM ?

                  Posté par  . Évalué à 7.

                  Et pour le petit benchmark Unigine Valley 1.0 (64-bit) Basic preset :

                  Avant Megadrivers :
                  Benchmark results:
                  FPS: 19.9424
                  Min FPS: 10.3007
                  Max FPS: 30.6816
                  Score: 834.392

                  Avec Megadrivers :
                  Benchmark results:
                  FPS: 20.1978
                  Min FPS: 12.6586
                  Max FPS: 32.6445
                  Score: 845.077

                  Le GPU c'est une Radeon HD4850 (RV770) sur un Core i5-2500K + 8 Go RAM.

  • # Alternative

    Posté par  . Évalué à 6.

    Cet outil permet de suivre le développement courant.
    Mais récemment Ilia Mirkin avait aussi proposé un outil un peu similaire, qui permet de voir ce qui est implémenté pour une version de Mesa précise, pratique pour voir les évolutions :
    http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html

    • [^] # Re: Alternative

      Posté par  . Évalué à 1.

      Ouaip, j'avais vu cette page (après avoir fait mon script d'ailleurs). Elle offre une vision plus pragmatique des évolutions en testant directement sur la compatibilité avec des GPU bien précis.

      C'est pas con de faire un lien vers la doc pour chaque extensions, faudrait que je vois comment faire ça.

    • [^] # Re: Alternative

      Posté par  . Évalué à 2.

      Pratique ça, dommage, il n'y a pas OpenGL ES, que les OpenGL de bureau. Hors, WebGL par exemple, est basé sur OpenGL ES, donc, ça n'est pas important que pour les smartphones/smartbook/smartbidules/botiers tv/consoles de jeu android, mais aussi pour le web interactif en 3D ou 2D accéléré 3D (même sur processeur supportant OpenGL complet).

      • [^] # Re: Alternative

        Posté par  . Évalué à 5.

        Si c'est présent, regarde il y a 3 boutons : Core, Compat et ES.

        • [^] # Re: Alternative

          Posté par  . Évalué à 0.

          Ah oui, j'ai pas les yeux en face des trous en ce moment :). Il y a même les ES 2.0, top cool ça !!! Et du coup… Ardreno, normal qu'il ne soit pas dans les OpenGL puisqu'il ne supporte,comme la majorité des GPU ARM, sauf les tous récents K1 de Nvidia) qu'OpenGL ES.

          Je garde cette URL dans mon marquepagier du coup :)

    • [^] # Re: Alternative

      Posté par  . Évalué à 2.

      Ceci est excellent, c'est vraiment le genre de "rapport" que j'attendais quant à l'état du support OpenGL et des pilotes libres!

      Si on pouvait avoir le même genre pour Xorg/Wayland, ça serait bien sympatoche.

  • # Améliorations

    Posté par  . Évalué à 4.

    J'ai rajouté un petit espace entre la colonne mesa et les pilotes, c'est une première étape vers une meilleure compréhension.
    J'ai aussi corrigé quelques bogues et rendu le tout valide avec HTML5.

    Si vous avez des idées, n'hésitez pas!
    Elles ne seront peut-être pas toutes réalisables, mais je tenterai de faire de mon mieux! ;)

    • [^] # Re: Améliorations

      Posté par  . Évalué à 4.

      Et je viens de rajouter la séparation par vendeur (Software, Intel, nVidia, AMD) + une colorisation.

  • # R300

    Posté par  . Évalué à 5.

    Je me demande si tu pourrais mettre les trucs pas faits pour OpenGL 3 en R300 : c'est des limitations matérielles qui font que le pilote ne le fera jamais. C'est indiqué dans http://xorg.freedesktop.org/wiki/RadeonFeature/ par N/A.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: R300

      Posté par  . Évalué à 1.

      Je me disais aussi que c'était surprenant que R300 était aussi rouge…
      Je vais voir ce que je peux faire, mais je vois pas de façon automatique de lier les infos de ces deux pages. À investiguer!

      • [^] # Re: R300

        Posté par  . Évalué à 1.

        J'ai demandé aux devs de Mesa et apparemment si c'est rouge ce n'est pas que parce que c'est impossible à faire, ça peut aussi être parce que le r300 ne l'a pas encore implémenté (les cartes du r300 devenant sûrement vieille, peut-être qu'il y a moins de devs pour ce pilote).

        • [^] # Re: R300

          Posté par  . Évalué à 2.

          Mouais, il y a bien 2/3 trucs régulièrement qui sont ajoutés à R300, mais les cartes ayant une compatibilité matérielle limitée à OpenGL 2.1 , certaines lignes resteront perpétuellement en rouge, voilà tout.

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

Suivre le flux des commentaires

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