À 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
- MesaMatrix (380 clics)
- GitHub de MesaMatrix (48 clics)
- Fichier texte source (38 clics)
- Mesa 3D sur Wikipedia (130 clics)
# définition ?
Posté par Nicolas Boulay (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 floreal . Évalué à 3.
Je pense que ça fait référence aux modules Kernel.
[^] # Re: définition ?
Posté par GTof . É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 tao popus . É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 Martin Peres (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:
J'espère que ça va vous aider un peu!
[^] # Re: définition ?
Posté par Creak . É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 Martin Peres (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 Creak . É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 Martin Peres (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 Creak . Évalué à 2.
Je me disais aussi que ton nom me disait quelque chose! ;)
[^] # Re: définition ?
Posté par BAud (site web personnel) . Évalué à 6.
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 Martin Peres (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 BAud (site web personnel) . Évalué à 2.
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 Martin Peres (site web personnel) . Évalué à 2.
Oh, je savais pas!
Hey, on a eu un amphi de 200 personnes cette année! Et on l'a rempli plusieurs fois :)
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 BAud (site web personnel) . Évalué à 2.
ennael< l'a indiqué sur https://linuxfr.org/news/kernel-recipes-2014
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 ;-)
si si, stait rigolo à voir ces fenêtres qui bougent (ya wayland qui a du potentiel aussite :p).
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 Martin Peres (site web personnel) . Évalué à 2.
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
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 WhiteCat . É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 Nerach . É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/ :
C'est plus pratique pour savoir où se trouve sa carte.
[^] # Re: définition ?
Posté par WhiteCat . Évalué à 3.
Quoi, tu ne connaissais pas cette page ?! ;-) C'est une mine d'or ! De même pour celle-ci : https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units
[^] # Re: définition ?
Posté par Nerach . Évalué à 1.
Si, mais on peu pas dire que l'info indiquant que les chipsets de la famille R700 sont dans la catégorie r600 du projet mesa soit très visible.
Concernant la page wikipédia, là, elle ne sert à rien. Je sais déjà que le chipset de ma CG est un RV740.
# Merci
Posté par alpha_one_x86 (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 deasy . É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 deasy . É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 Creak . Évalué à 1.
Ça fait plaisir ;)
# Et du côté des SoC ARM ?
Posté par tao popus . É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 Creak . É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 tao popus . É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 Creak . É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 WhiteCat . Évalué à 4.
Mesa existe depuis 21 ans ! Donc non il ne s'occupe pas que d'OpenGL 3 :-) Il gère OpenGL 1 et 2 aussi.
[^] # Re: Et du côté des SoC ARM ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Dans opengl SC, utilisé sur les écrans des avions, ils sont encore à opengl 1.x. Le coté compilation de shader fait encore peur. https://en.wikipedia.org/wiki/OpenGL_SC
"La première sécurité est la liberté"
[^] # Re: Et du côté des SoC ARM ?
Posté par tao popus . É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 Creak . É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 WhiteCat . É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 Creak . É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 WhiteCat . É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 BAud (site web personnel) . Évalué à 1.
combien de place disque prise ? (avant / après)
ç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 WhiteCat . É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.
Je crois que c'est de l'ordre de 4 Mo par pilote.
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 WhiteCat . Évalué à 4.
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 WhiteCat . É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 Creak . Évalué à 1.
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 WhiteCat . É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 Sytoka Modon (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 WhiteCat . É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 WhiteCat . É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 WhiteCat . É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 Creak . É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 tao popus . É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 WhiteCat . Évalué à 5.
Si c'est présent, regarde il y a 3 boutons : Core, Compat et ES.
[^] # Re: Alternative
Posté par tao popus . É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 Ph Husson (site web personnel) . Évalué à 2.
Je connais pas les différences entre OpenGL et OpenGL ES pour pouvoir déterminer à quel point c'est intéressant, mais apparement freedreno sur Adreno est aussi capable de gérer du OpenGL 2.0:
http://inforcecomputing.com/blog/?p=172
[^] # Re: Alternative
Posté par tao popus . Évalué à 1.
Ah oui, même OpenGL 2.1 d'après la table glxinfo, mais cela se limite également aux Snapdragons les plus récents, avec Adreno A3xx:
http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#v=Mesa%2010.3.0&p=compat
PowerVR G6xx a également fait une annonce dans ce sens sur ses derniers modèles au moment de la sortie de l'Allwinner A80 (qui l'intègre). Mais c'est dur d'avoir une confirmation, la moitié des infos sur leur site ne le donne pas, et ce ne sont que des pages à aspect promotionnelle, il n'y a pas de pages réellement orientées spécifications techniques brutes.
Du côté d'ARM par contre, même les Mali les plus récents/puissants (T7xx) ne supportent qu'OpenGL ES jusqu'à 3.1, de l'OpenCL, mais pas d'OpenGL complet :
http://www.arm.com/zh/products/multimedia/mali-high-end-graphics/mali-t760.php
[^] # Re: Alternative
Posté par Le Gab . É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 Creak . É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 Creak . É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 Creak . É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 Creak . É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.