Stephane Marchesin a écrit 254 commentaires

Trois petites choses :
Quand la TNT est est sortie, on ne parlait pas vraiment d'OpenGL hardware sur Windows pour Nvidia. Le pilote de base OpenGL sous windows 95 était pur soft.
Et kes drivers qui existait à l'époque s'installait à coup de copie de DLL et d'édition de base de registre.
Les hints sont essentiels dans la plupart des applis professionnelles. Car le rendu diffère vraiment d'un cas à l'autre.
Les denière générations de Cartes 3D sur lesquelles j'ai bossé chez NVidia (à savoir les 8000) font un peu ce qu'elles veulent et ignorent les hints. Certains rendus sont fait en GL_Nicest, les autres sont fait en ce qu'on peut. Et tant pis si il y a des Z aliasing ou des déformations à la con parceque le pilote fait des arrondis un peu cavalier. Certes il s'agit de cartes de desktop, donc ce n'est pas grave techniquement. Mais d'un autre coté ca oblige à tester son rendu carte par carte pour savoir sil il est propre ou pas.

Non, encore une fois c'est faux. Toutes les cartes nvidia depuis la première geforce n'ont pas de quoi gérer les hints dont tu parles, les hint en question n'existent plus et ne servent à rien. Source : je suis le fondateur de nouveau donc je connais le hard nvidia un peu. Et si tu ne me crois pas les specs des cartes nvidia qu'on a RE sont bien au chaud dans un fichier xml : http://nouveau.cvs.sourceforge.net/viewvc/nouveau/renouveau/(...)
Tu verras que seules les TNT ont les fameux hints.

L'architecture Xorg fait que toutes les applis utilisent la même instance avec le composting. L'avantage est que plusieurs applis peuvent faire de l'OpenGL en même temps, l'inconvennient est que toutes les applis sont impactées si il y a un problème. Par exemple si tu charges une vidéo en mode texture dans une appli, tout le monde morfle.

Non. Des instances séparées de libGL sont utilisées pour chaque appli OpenGL que tu lances. Source : je suis dev X.Org et mesa.

Autre inconvennient tu ne peux pas charger des pilotes spécifiques à ton appli. C'est le même tarif pour tout le monde. Si tu veux faire de l'accéleré Hardware pour un pré-rendu et ensuite du Mesa pour un rendu correct techniquement, tu es bon pour recharger ton Xorg entre les deux.

Non c'est faux. Tu peux très bien utiliser LD_PRELOAD si tu veux un autre implémentation de GL (par exemple du mesa soft dans une certaine appli au lieu d'un driver DRI).
Source : t'as qu'à essayer LD_PRELOAD=/path/to/mesa/libGL.so ./monappli et tu auras du rendu soft. Tout ça sans "recharger ton X.Org"

OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware.

Non, OpenGL est une spec, et une spec n'a pas de mécanismes pour faire des trucs en software. Source : va voir sur opengl.org et tu verras que c'est une spec.

Les mini ports vont plus loin, ils permettent de faire en rendu hardware certaines fonctions OpenGL sous certaines conditions, mais de retomber en rendu soft si la même fonction est appelée dans d'autres conditions. Historiquement les certaines fonctions en question étaient celles utilisées par Quake 2 et les certaines conditions celles de Quake 2. Déjà toutes les fonctions qui n'utilisaient pas GL_RGB mais un autre espace de couleur (au hasard YUV pour plaquer des vidéo) repassaient en soft immédiatement. Alors que les cartes de l'époque (TNT2, ATI Xpert, Millenium G100, Millenium G200 etc.) savaient convertir le YUV en RGB en Hard.

Non, Quake 1/2 n'a jamais utilisé aucun truc en espace de couleur YUV. Source : lis le code source de quake 1/2. C'est tout du RGB.

Idem si on charge les textures avec autre chose que du GL_SMOOTH.

Non, GL_SMOOTH ne s'applique pas aux textures. Source : la doc OpenGL qui explique que GL_SMOOTH s'applique a l'interpolation des couleurs sur les facettes et non pas l'interpolation des textures.

- Une vraie rupture de compatibilité, ou à défaut un hint qui permette de dire si l'on veut utiliser les fonctions OpenGL en mode 3.0 ou en mode deprecated. celà permettrait de faire un grand ménage dans tout un tas de fonctions qui ne sont plus utilisées par personne aujourd'hui. C'était la principale promesse d'OpenGL 3.0.
Un exemple tout con : plaquer une texture S3TC/DXTC sur un cube demande une page complète de code, pour charger la texture, la valider, la binder, la décompresser, la transformer en texels 2D, l'appliquer, corriger la perspective, la lisser et enfin l'afficher.

Non, tu n'as pas à valider la texture, tu n'as pas à explicitement la décompresser (fait par la carte), ni à la transformer en texels 2D (ça veut rien dire), ni à corriger la perspective (c'est fait tout seul). Source : les docs OpenGL.

Et là je parle même pas de charger plusieurs résolutions de textures pour faire du filtering aniso. En DirectX 8+ ca ne prend que quelques lignes.

Oh si parlons-en. En OpenGL l'anisotropique s'active en 1 ligne : glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0);
Source : http://www.opengl.org/registry/specs/EXT/texture_filter_anis(...)

Enfin bref, encore une fois, j'ai montré point par point que tu dis n'importe quoi et que tu dénigres OpenGL sans fondement. Tu as lu 3 keywords OpenGL et tu crois connaître l'API. Encore une fois, c'est ça le gros problème d'OpenGL, le fait que les gens mal renseignés parlent en mal du bouzin mais écoutent le marketting à microsoft. Et le sens critique dans tout ça il est où ? On dirait une bande de moutons...

Bêêêêêêêêêeee

PS: alors, le fait que Direct3D ait des shaders séparés comme OpenGL, pourri ou pas pourri du coup ? Si c'est pourri dans OpenGL, c'est pourri dans Direct3D non ?

Bof, je suis moyennement d'accord avec toi sur le fond, et pas du tout sur certains points techniques. Par exemple :

La première chose que l'on fait quand on écrit un programme OpenGL est de définir quelle sera la qualité du rendu, en d'autres termes quelle précision de calcul on veut. Cette option va de GL_Default jusqu'à GL_Nicest.

Non c'est faux, ces hints sont optionnels, et en plus au moins 90% des drivers ne les implémentent pas. Et pour cause, le hardware video n'a plus de fonctionnalité pour réaliser ces hints (pour référence le dernier hardware nvidia à implementer ces hints c'est la TNT/TNT2, les générations suivantes ont l'équivalent de GL_NICEST et c'est tout).

OpenGL gère l'ensemble du pipeline de rendu graphique de la carte vidéo. Ce qui est très bien pour un rendu de précision, mais qui pose un véritable problème dans le cadre d'un PC de bureau. Si vous lancez une application OpenGL, elle va mettre la main sur tout un pipeline de rendu. Donc si vous lancez une seconde application OpenGL, soit vous avez une carte graphique professionnelle avec Autant de pipeline que nécessaire, soit la seconde application ne sera pas accélérée 3D et passera en mode pur soft. Sous Direct3D il est tout à fait possible d'accélerer simultanément plusieurs rendus, car c'est le système et non l'appli qui fait le dispatch des traitements. C'est pour celà que sous Vista et 7 tant que l'on a pas désactivé Aero, les performances OpenGL sont assez limitée. Bon Microsoft a sorti un patch qui fait que si l'appli OpenGL passe en plein écran aero va faire dodo et on a des perfs correctes, mais en fenétré c'est une catastrophe.

Encore une fois c'est faux. Avoir plusieurs applications OpenGL avec l'acceleration, on y arrive sous X.Org (avec compositing et tout le bordem) et aucune des instances ne tourne en soft. Tu imagines sinon ? Tu tournes compiz (== 1 appli OpenGL) et après tu n'as plus d'accélération 3D, on se ferait massacrer. Après si c'est la merde sous Vista c'est la faute de Microsoft et c'est tout, pas besoin d'accuser OpenGL. OpenGL ce n'est pas une grosse main qui attrape ta carte video et qui après ne veut pas la rendre :)

Seulement il s'agissait de Mini-Drivers, c'est à dire de pilote conçus pour faire tourner Quake 2 et rien d'autre. Pas un vrai support OpenGL.

Si tu parles de drivers miniport, ce n'est pas fait pour quake2. En fait miniport est une couche simplifiée entre OpenGL et le driver windows qui permet de faire un driver OpenGL plus facilement, et laisser miniport implémenter les trucs un peu tordus de manière générique en logiciel. Si tu regardes les cartes de l'époque, elles ne pouvaient pas accélerer tout OpenGL, donc elles auraient de toute façon du implémenter ces fameux fallback en logiciel. Pour résumer, les trucs que miniport faisait en logiciel, tu ne les avais pas dans direct3D.

Et puis OpenGL 1.3 est sorti. Et là les fabriquants de cartes graphique sont éclatés de rire et se sont tournés vers Directx7 qui était beaucoup plus raisonnable en terme de puissance demandé pour un résultat correct. C'est un petit nouveau : NVidia qui est venu mettre la pagaille dans tout çà, en annonçant coup sur coup le support du transform and Lightning sur Directx7 et le support complet d'openGL 1.3 (Bon complet du tronc principal de l'ARB, toutes les extensions officielles n'étant pas supportée). La geforce va se vendre comme des petits pains. Et les autres constructeurs corrigent leur copie pour utiliser à fond OpenGL 1.3.

Ah voilà un exemple intéressant, celui du transform and lightning. Les applications qui étaient écrites en OpenGL 1.0 (ou plus) ont pu exploiter le transform and lighting sans avoir besoin de recompilation/modification d'aucun genre. A côté de ça microsoft a introduit DirectX 7 comme une révolution et tout le monde a trouvé géniale l'idée du Transform and lighting. Et ça m'amène au point principal que je veux soulever : c'est le marketting qui fait que DirectX/Direct3D gagne, et c'est tout.

OpenGL 3.0 qui devait corriger le tir et devenir un direct3D Killer prend un an de retard sans pratiquement aucune communication du groupe Khronos. Finalement loin de la refonte attendue qui aurait permis de rendre OpenGL utile dans uen optique de jeu, c'est une suite logique d'OpenGL 2.0 qui sort avec ses archaisme et ses shaders séparés. La puissance de calcul nécessaire pour faire de l'OpenGL 3.x en hardware, et la complexité de programmation clouent définitvement OpenGL au sol. Son apotre Carmack prend sa retraite et pouf.

Concrètement, tu voudrais quels changements dans OpenGL ? Par exemple tu critiques les shaders séparés, mais Direct3D 10 et OpenGL 3.0 ont tous les deux des shaders séparés. Donc d'après ton critère, Direct3D 10 est aussi nul que OpenGL ? D'ailleurs les APIs sont très proches, ayant pratiqué les 2 je trouve qu'on passe de l'un à l'autre sans souci.

Encore une fois j'ai l'impression que OpenGL a surtout un problème de communication (au point que même les geeks de linuxfr le renient) en face de la machine de communication de Microsoft. Alors certes cet article est partisan, mais mettons un peu les choses en perspective et comparons-le au marketting fait pour Direct3D. Je pense que tout le monde est d'accord pour dire qu'il y a encore quelques ordres de grandeur de différence :)

Dans l'idée ça peut être bien (très basse conso et ça fait assez bien le boulot), mais il y a une limitation à mon sens : le fait que le firmware (dont il est question plus tard) implémente juste 2 ou 3 codecs sans possibilité de le mettre à jour. Il faudrait pouvoir s'assurer que c'est évolutif (pour décoder du H.265 par exemple) sinon ça peut devenir très rapidement caduc.

Certes pour lire du BluRay les formats sont connue est fixes, mais en matière de video streamée, les formats évoluent plus rapidement. Dans un futur sympa, les décodeurs video seraient écrits dans un langage de haut niveau, chargés depuis internet à la demande, et compilés à la volée pour chaque matériel...

(bon ok j'arrête de rêver)

Allez nouveau, 2010 sera-t-il l'année de ta diffusion au grand public?

Meuh non, 2010 c'est avant tout l'année de Linux sur le desktop !

Plus sérieusement, Linus a mergé nouveau l'autre jour (c'est son cadeau de noël) :
http://article.gmane.org/gmane.linux.kernel/925943

D'ailleurs 2010 est aussi l'année où Linus reconnaît son amour immodéré des poney :
http://article.gmane.org/gmane.linux.kernel/926222

Bref, l'état des lieux libre me va très bien, avec des outils qui avancent lentement mais surement : VA-API est fonctionnel.

...uniquement sur les chipsets poulsbo (GMA500) et certains S3 et avec des pilotes propriétaires. Est-ce-que ça compte quand même comme "état des lieux libre" ?

Donc si j'ai bien compris Imagination Technologies vend des très bonnes puces (graphiques), mais vend les pilotes à part oi propose des NDA pour que le constructeur écrive ses propres pilotes ?
Non, imgtec ne vend pas les pilotes en sus. Il y a un pilote proprio pour SGX sur ARM et tu peux l'avoir en t'enregistrant sur leur site. Le problème c'est aussi que imgtec ne cible pas x86 à la base alors que poulsbo si...

Quel est l'intérêt d'avoir un chouette puce 3D sans pilote (cas du N800) !?
La raison principale pour laquelle le n800 n'a pas l'accélération 3D, c'est que les batteries n'auraient pas pu le supporter, l'autonomie aurait été massacrée. Et pour un appareil comme le N800, avoir une autonomie ridicule c'est pire que ne pas avoir de 3D. Et si on l'activait quand même les utilisateurs auraient du mal à comprendre pourquoi utiliser des jeux/applis 3D tue les batteries.

Ouaip, la personne qui faisait les TINDC a arrêté. C'est du logiciel libre, personne ne se force à faire quoi que ce soit :)

Perso, je n'ai pas le temps de m'en occuper, j'ai quelques autres projets sur le feu. Donc je pense qu'à ce niveau ça sera le status quo. Mais par contre le wiki devrait être à jour, et en particulier la feature matrix qui contient l'état des différentes choses.

Après, c'est peut-être pas la priorité de certains de faire avancer Nouveau. (hein, vendredi toussa)

Ouais d'ailleurs Nouveau sapu moi je trouve !

D'accord, le timing est mal tombé pour Ubuntu. Mais tu suggères quoi, si on considère que Ubuntu ne contribue pas à plymouth/KMS/aux drivers video ? Les dévelopeurs RedHat devraient aligner leurs plannings sur les releases Ubuntu ? :)

Ca c'est du fud. Voilà le git de plymouth (enfin, les renderers de pymouth) :
http://cgit.freedesktop.org/plymouth/tree/src/plugins/render(...)

On y trouve :
d--------- drm 458 log
d--------- frame-buffer 75 log
d--------- x11

(drm c'est le support KMS)

chassé croisé qui montre qu'Ubuntu aussi propose et fait avancer le libre avec du code.

Je crois que le problème ce n'est pas tant le fait de faire du code ou pas, que l'utilité du dit code sur le long terme. Par exemple :
- Ubuntu fait Xsplash qui est une bidouille pour démarrer le serveur X plus tôt, et dénigre KMS qui est la solution propre techniquement
- Avant que AIGLX ne soit terminé, Ubuntu empaquetait Xglx (un hack qui empile un serveur X sur un autre pour lancer compiz), pendant que RedHat et les autres des X bossaient sur une solution propre (AIGLX en l'occurrence).

Donc oui, Ubuntu écrit du code, mais ce qui m'ennuie c'est son manque d'utilité sur le long terme. Je ne suis pas sur que réinventer la roue en faisant des trucs jetables (comme Xsplash qui finira bien par être remplacé par KMS + plymouth ou plymouth-like) soit une contribution qui fait réellement avancer le libre.

En fait, le problème est pour moi le suivant : Canonical n'a pas vraiment de développeurs à la hauteur de ses ambitions (par exemple capables de débugger les drivers video pour faire marcher KMS plymouth) et se contente de bidouiller des solutions ad-hoc.

Après ce n'est que mon avis...

Par contre, c'est probablement très au delà de ton budget, et je ne suis pas certain que ça te convienne en ce qui concerne la fiabilité du code flottant. Pour les experts : les GPUs récents sont-ils conformes à la norme IEEE-754 ?

Oui pour ce qui est de la précision des calculs flottants, non pour la gestion des nombres infinis/nan/denormaux. Donc si tu sais que ton code ne génère pas de tels nombres ou ne dépend pas des comportements associés à ces nombres c'est bon.

ce que je dis dans cette partie, c'est que ce bout de code x86 aurait été beaucoup plus difficile à analyser s'il avait été compilé pour le GPU.

Ok, je commence a comprendre ce que tu veux faire. Cependant, je ne partage toujours pas ton point de vue. Par exemple, pourquoi les slides disent qu'on ne sait pas analyser le PTX ? Je te renvoie vers deux projets qui savent desassembler des shaders/cuda nv50 :
http://www.cs.rug.nl/~wladimir/decuda/
http://nouveau.freedesktop.org/
Ces 2 projets datent de 2007 et 2005 respectivement, donc sont antérieurs aux slides qui disent 2008.

Du coup, je ne pense pas que le code cuda soit difficile à comprendre, il suffit de lancer les utilitaires et de lire l'assembleur. Comme pour x86 en fait...

Et ça veut dire qu'on peut faire des malware parce que ? Je ne vois pas le lien de cause à effet.

Si tu me disais par exemple comment outrepasser la protection mémoire pour ajouter du code maison dans un shader, d'accord. Je connais assez bien les GPUs, n'hésite pas à être très technique dans cette description. En passant la modification de shaders requiert une intervention du CPU sur les puces nvidia et ATI, donc déjà un hypothétique malware aurait besoin de tourner sur le CPU. Du coup là on ne parle plus d'un malware GPU...

En fait il n'y a pas aujourd'hui de façon de mettre des malware sur GPU. Par contre il y a des failles au niveau du driver, et ce dans la plupart des drivers à mon avis.

La tentation de crier au loup a toujours été forte sur internet où tout le monde veut s'exprimer sans maîtriser les sujets, le faire c'est facile et vendeur... Mais en l'occurence baser un tel raisonnement sur de vagues impressions sur le debugging c'est du fud.

Fais attention, tu sombres dans le même travers :) Je demande un exemple technique, une raison, même juste une théorie de fonctionnement d'un tel malware.

Là dans les slides on a :
- une partie où il dit qu'il ne sait pas trop comment fonctionne le GPGPU avec des visions haut niveau, et des distinctions d'APIs qui n'entrent pas en jeu pour ce qu'il veut faire
- une partie avec des bouts de malwares pour x86 donc non pertinent pour ce qui nous intéresse
- une partie sur la retro ingenierie qu'il n'a pas faite (aucun détail sur le fonctionnement de la protection mémoire sur GPU, par exemple qui pourrait expliquer qu'on puisse faire des malware)
- une partie sur le packing, encore une fois avec les principes de fonctionnement x86, et aucune idée sur comment le faire marcher sur GPU
- une conclusion qui met du FUD en rouge

Bref, à mon avis c'est un concentré de poudre aux yeux. (J'espère que l'auteur de passe pas par ici, sinon il va me détester :)

Intéressante présentation

Bof, je n'ai pas vu un seul exemple technique, ni une seule justification qui montrerait qu'on peut faire des malwares sur GPU. Je ne dis pas que c'est impossible, mais je voudrais bien voir un exemple ; en l'état ça ressemble à un gros FUD.

le code implémentant OpenGL dans X.org n'était pas libre.

En fait si on veut pinailler, la bonne phrase est "le code implémentant GLX dans X.org n'était pas libre".

Il y a 2 choses qui ont changé de licence :
- l'implémentation OpenGL de référence de SGI. Cette implémentation est bien moins avancée que mesa, donc le libre est très peu concerné. OpenGL en lui-même sous linux a toujours été libre puisque mesa a toujours été libre. Et on pouvait déjà utiliser mesa de manière libre si on ne passait pas par glx (avec par exemple miniglx ou EGL).
- le code de GLX qui est celui utilisé aujourd'hui dans X.Org. Là effectivement ça va changer quelque chose : ça sera surement la fin du débat récurrent sur la liberté de cette licence et son utilisation ou non dans les distributions.

Est-ce tu sais si du coup ils vont ajouter le contrôle du ventilateur pour rendre les Aspire One silencieux ? C'est une machine qui a l'air sympa, mais je suis freiné par les gens qui se plaignent du bruit du ventilo...

Et Powertop ? Et latencytop ?

Hum, on parlait pas du graphique là ? :) A mon avis il n'y a pas de problème avec ce que fait intel hors du graphique, le problème c'est qu'à l'intérieur d'intel toutes les équipes ne fonctionnent pas pareil.

Je suppose (et j'espère) que c'est lié à la relative "jeunesse" des drivers video dans le noyau (à comparer au support des cpu/chipsets qui a eu bien plus de temps pour arriver à maturation).

Franchement, je trouve ça bizarre qu'on fasse rentrer un composant censé unifier l'accélération graphique, tout en étant fait uniquement pour un constructeur pour le moment (et qui n'a été "designé" que pour leur type de carte - s'ils voulaient vraiment un truc générique, pourquoi n'ont-ils pas fait une "surcouche" simplifiée à TTM ?)

Oui, d'un côté il y a les gens de Red Hat et de ATI/AMD qui sont en train d'essayer d'adapter GEM/TTM (de prendre le meilleur de chaque) pour en faire quelque chose d'utilisable pour tout le monde. Et de l'autre côté, intel court-circuite le chemin "habituel" que prennent les patches DRM (normalement ils passent par le mainteneur du DRM) et les envoient directement à la lkml.

Donc il serait plus profitable de bosser sur son amélioration que de grogner car il va falloir vivre avec.

Le problème est que comme GEM a été développé (en secret, sans aucune discussion avec les autres devs) par intel et pour intel, il n'est pas vraiment "future proof". Mais bon, je suppose que dans 2 ans on refera autre chose...

Et sur le long terme, j'ai bien peur qu'intel monopolise tout le graphique sous linux, il n'y a pas de boîte qui investit assez pour les contrer aujourd'hui. Donc dans 5 ans on pourrait se retrouver dans une situation où seulement les cartes intel marchent bien sous linux. Et on aura droit à des "mouah linux c'est nul ma carte video marche pas dessus".

PS: je pense que j'ai écrit assez de code dans le domaine des drivers video pour éviter d'être accusé de "grogner" sans rien faire.

La difference avec TTM c'est pas surtout que il y a beaucoup plus de collaboration entre GEM et le kernel que entre TTM et le kernel ?

Oui, surtout parce que les gens de intel (du noyau et des drivers video) bossent entre eux. Mais si il y a collaboration avec le kernel, mais pas avec les autres drivers, avoue que c'est un peu ennuyeux.

Et, à ce sujet, quel est le point de vue du projet Nouveau? GEM nécessite-t-il, en l'état, beaucoup de modifications pour être utilisé par vous?

Comme GEM ne fonctionne pas en l'état avec les cartes non-integrées (il ne gère pas la ram video, juste la ram système partagée), il faudra effectivement des adaptations (pour nouveau, pour radeon, pour toutes les cartes séparées en fait). TTM le fait, même si le code est plus complexe.

Voilà, c'est un post un peu critique, mais faut voir ce qu'il se passe en ce moment avec Intel : ils font "bouger" les choses en "emmerdant" tout le monde (i.e. en refaisant de zéro des trucs qui sont déjà en développement), ce qui d'un coté est pas mal car cela lance le débat, mais cela se fait de manière un peu brutale en essayant de "forcer" tout ça upstream afin d'être les premiers intégrés, et donc comme souvent, le seul qui restera ... (vous savez, le principe d'être présent par défaut, partout ...)

Oui c'est exactement ça, j'ai l'impression qu'il y a chez intel une vague de Not_Invented_Here en ce moment. C'est très malsain, ils sont en train de faire la même chose pour le noyau où ils prétendent que GEM va marcher partout...

Pourquoi vous allez me dire ? Tout simplement parce que lors de l'adaptation de EXA à GEM [1] [2], Keith Packard n'a pas voulu modifier EXA pour le faire fonctionner avec GEM (ça aurait encore tout cassé) mais plutôt séparer les 2 travaux en dupliquant EXA ailleurs pour ensuite supprimer/adapter le code là où il y avait besoin. Le bébé fait 5000 lignes là où EXA fait environ 7500 lignes et Keith a donc décidé de l'appelé UXA (UMA Acceleration Architecture. Et UMA ? Mystère ...).


Et d'ailleurs 5000 lignes + 7500 lignes de code à maintenir, c'est moins que juste 7500 lignes à supporter pour les devs de X.Org. J'ai bon ?

En plus, EXA permet déjà de faire tout ce que fait UXA. Alors je veux bien que tu m'expliques à quoi ça sert de faire une nouvelle archi.

Après l'intégration de la gestion du mode de la carte graphique dans le kernel ainsi que l'apparation prochaine de GEM dans le kernel, on ne peut que se réjouir de ces changements qui laisse entrevoir un avenir radieux pour l'accélération graphique sous Linux. Imaginez plutôt :

Oui c'est radieux, pour preuve, on a GEM et UXA, deux composants qui sont spécifiques aux cartes intel. Ca va être bien pour tout le reste du matos.