David Madore's WebLog: Pourquoi ne réussis-je pas à avoir de la 3D sous Linux ?

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]

↓Entry #1867 [older| permalink|newer] / ↓Entrée #1867 [précédente| permalien|suivante] ↓

(samedi)

Pourquoi ne réussis-je pas à avoir de la 3D sous Linux ?

Un des domaines où Linux est incroyablement et obstinément nul, au point que ça en devient presque comique et en tout cas extrêmement embarrassant, c'est l'accélération graphique 3D. En fait, plutôt que comique, ça en devient très problématique, parce que de plus en plus de sites Web sont accessibles uniquement par les navigateurs supportant le WebGL (c'est-à-dire l'extension à l'élément <canvas> du HTML5 permettant d'accéder à l'accélération 3D depuis le navigateur). Par exemple l'extraordinaire site Web d'anatomie humaine bodybrowser.googlelabs.com. Or il n'y a quasiment aucune combinaison de matériel, pilote graphique et navigateur qui permette effectivement d'avoir du WebGL accéléré en matériel sous Linux.

Récapitulons pour ceux qui n'y connaissent rien. D'abord, quand je parle de 3D, il ne s'agit pas de ce qu'on aurait au cinéma en 3D (par vision stéréoscopique), mais de représentation 2D d'images 3D calculées par une technique dont je ne connais pas le nom (mais qui s'oppose à celle du raytracing) et qui consiste à trianguler (=décomposer en petits triangles) les surfaces à projeter et à faire des calculs de rendu de surface (ombres portées, textures, etc.) sur ces triangles pour les afficher finalement en 2D. Tous les jeux sur ordinateur modernes utilisent cette technique. Et l'enjeu est tellement important qu'on a développé des cartes graphiques (actuellement toutes les cartes graphiques) qui sont capables de faire en matériel les principaux calculs nécessaires pour cette technique : on appelle ça l'accélération 3D matérielle (et les cartes en question sont beaucoup, beaucoup plus rapides que le processeur principal dans leur domaine de compétence). Encore faut-il que le logiciel derrière soit capable de s'en servir, c'est-à-dire, d'avoir les bons pilotes, les bonnes bibliothèques, etc. (et éventuellement le bon navigateur s'il s'agit de WebGL et que c'est une page Web dynamique qui veut bénéficier de cette accélération).

Les principales cartes (ou puces) graphiques du marché se rangent en trois familles : celles des constructeurs nVidia, ATI qui a été racheté par AMD, et Intel (ce dernier se concentre plutôt sur les puces graphiques pour portables alors que nVidia et ATI/AMD font plutôt des cartes graphiques pour ordinateurs de bureau). Il y a sans doute des différences de vitesse entre ces différentes cartes, cruciales pour les gamerz qui comptent les fps (frames per second) comme d'autres comptent les centimètres de leur bite, mais pour quelqu'un comme moi qui voudrais juste pouvoir accéder à des sites WebGL assez basiques, cela n'a aucune importance, je veux juste quelque chose d'un peu plus rapide que de la 3D non-accélérée (=rendue en logiciel).

Autrefois, Linux avait une bonne excuse : les fabricants de cartes graphiques ne publiaient pas les spécifications de leurs cartes (ou du moins, seulement sous signature d'un accord de non-divulgation), parce qu'une idée parfaitement stupide abondait chez eux selon laquelle il valait mieux que leur matériel ne marchât pas du tout que d'en faire paraître le mode d'emploi avec lequel, horresco referens, on risquerait de, euh, je ne sais pas, de s'en servir je suppose. Sans spécifications, pas moyen d'écrire un pilote, et l'histoire s'arrêtait là. Maintenant, les choses ont un peu changé : si nVidia persiste dans cette stratégie grotesque, en revanche lorsque AMD a racheté ATI, ils ont inversé la politique et ont publié en 2007 de gros manuels de programmation de leurs puces graphiques (je crois que c'était pour les puces récentes). Quant à Intel, ils sont plutôt ouverts sur la question, même s'il y a des changements occasionnels comme on en a l'habitude avec ce genre de grosse compagnie. Toujours est-il que si j'ai applaudi lorsque ATI a libéré les spécifications de ses puces, j'espérais voir un pilote utilisable apparaître en un an ou deux. Ou trois. Mais quatre ans plus tard, c'est vraiment embarrassant à quel point le progrès est nul. (Et ce n'est pas faute de moyens : il y a des développeurs qui bossent vraiment dessus, y compris des développeurs payés par le constructeur.)

La première chose qui pose problème, c'est que plus Personne N'Y Comprend Rien®. Autrefois, pour faire de la 3D sous un Unix à la Linux, il y avait plusieurs approches possibles : (1) faire les calculs purement en logiciel (c'est-à-dire, sans accélération matérielle, donc sans besoin de matériel spécifique, mais en échange de quoi tout sera très lent), ce qui peut vouloir dire (1a) faire les calculs côté serveur (le serveur, dans la terminologie X11, étant l'ordinateur, ou le processus, qui affiche vraiment l'image sur l'écran) ou bien (1b) faire les calculs côté client (le client, dans la terminologie X11, étant l'ordinateur ou le processus qui fait tourner le programme graphique), la distinction étant pertinente parce que le système X11 est un protocole client-serveur, ce qu'on a tendance à oublier de nos jours ; ou bien (2) utiliser une accélération matérielle côté serveur, c'est-à-dire que le client (qui peut très bien tourner sur un ordinateur différent) fait passer au serveur des demandes d'affichage de triangles (ou je ne sais quoi d'autre) et le serveur les refile à la carte graphique rattachée à l'écran. Pour une raison d'efficacité, on a introduit une nouvelle possibilité, (3) le direct rendering, par laquelle le client graphique parle directement à la carte graphique sans passer par le serveur (il a juste demandé une sorte d'autorisation générale au serveur). Je crois que c'est quand on a introduit ça que tout a foutu le camp ; a commencer par la possibilité (2) d'avoir de l'accélération 3D matérielle en faisant tourner le client graphique sur une machine différente du serveur qui gère l'écran : personne n'est capable de me dire si cette possibilité existe encore sur les X.org/Linux modernes ; et je ne parle pas de la sécurité, parce que permettre à un programme non privilégié de parler à la carte graphique qui a un accès direct au bus mémoire et pas trop de notion de permissions, c'est ouvrir un trou de sécurité de la taille du Brésil dans le modèle de sécurité de l'ordinateur. Toujours est-il que l'idée de faire de l'accélération 3D matérielle sans ce direct rendering a l'air d'avoir complètement échappé à tout le monde (pourtant, j'en ai vu, ç'eut été possible).

Là-dessus, il y a toute une salade de sigles et de termes dont on ne sait pas ce qu'ils recouvrent au juste : il y a OpenGL, qui est une sorte de standard pour les primitives graphiques 3D, et qui a l'air atrocement mal foutu parce que personne n'a l'air d'accord sur ce qu'il contient exactement. Il y a Mesa, qui est apparemment l'implémentation libre d'OpenGL et qui a l'air de servir dans un sous-ensemble des cas (1a), (1b), (2) et (3) évoqués ci-dessus, mais c'est absolument impossible de savoir exactement lesquels (peut-être tous, mais rien n'est moins clair). Il y a des choses nébuleuses appelées libglu, libglut, libosmesa et encore d'autres, dont je n'ai aucune idée de ce qu'elles font (enfin, si, un peu : les deux premières sont des surcouches sur OpenGL, et la troisième permet de faire des calculs 3D offline, c'est-à-dire sans les afficher effectivement à l'écran). Et il y a des choses dans le noyau Linux et dans le serveur X.org qui parlent entre eux, et tout cela est ficelé de la façon habituelle en informatique, c'est-à-dire qu'on peut trouver des explications techniques très précises sur chacun des bouts, mais aucune documentation synthétique pour décrire comment les différentes pièces du puzzle s'assemblent.

Globalement, pour faire de la 3D accélérée sous Linux, au moins dans la solution (3) (les autres, comme je le disais, je ne sais pas s'ils existent encore), on a les possibilités suivantes : (α) avoir une carte nVidia avec le pilote propriétaire fourni par nVidia (qui souffre de quantité de défauts, par exemple de ne pas gérer correctement le XRandR, et de casser à chaque version de Linux, mais qui au moins marchouille) ; (β) avoir une carte nVidia avec le pilote libre Nouveau (non, ce n'est pas un nouveau pilote, enfin, si, ç'en est un, mais c'est surtout un pilote qui s'appelle Nouveau) ; (γ) avoir une carte graphique AMD/ATI avec le pilote libre Radeon ; ou (δ) avoir une puce graphique Intel (typiquement, mais pas exclusivement, sur portable) et le pilote libre qui va avec. (Il est possible qu'il y ait d'autres options, je ne les connais pas bien.) J'ai une machine avec chacune de ces possibilités, et je peux confirmer la chose suivante : rien ne marche. Enfin, (α) marche un peu, si d'une part on n'est pas un intégriste du logiciel libre (ou plus pragmatiquement si on est prêt à laisser nVidia prendre le contrôle de son ordi avec un énorme blob binaire dont on ne sait pas ce qu'il peut contenir) et si d'autre part on veut bien supporter leur politique de distribution vraiment pénible. Pour les gens qui veulent du libre, optez pour (β)–(δ), et là vous aurez vraiment la garantie que ça ne marche pas du tout.

Oh, il est censé y avoir des choses. Certains vous diront que, si, si, Nouveau fait maintenant de la 3D accélérée, ou que Radeon marche correctement, ou qu'ils n'ont pas de problème avec leur puce graphique Intel. Reste que les problèmes sont tellement nombreux et les pilotes tellement buggués que Firefox 4, qui a introduit le WebGL, décide de désactiver cette extension dans tous les pilotes Linux autres que le pilote propriétaire nVidia (ce que j'ai appelé (α)). On peut demander à la réactiver de force en lançant Firefox avec la variable MOZ_GLX_IGNORE_BLACKLIST=1 : j'ai essayé, et j'ai réussi à planter Firefox, à planter mon serveur X, mais jamais à avoir le moindre bout de WebGL qui marche — donc ce n'est pas une blague. Même son de cloche du côté de Chrome/Chromium. (Et je précise que j'essaie avec le noyau 2.6.38.3, X.org 7.6, Mesa 7.10, un pilote Nouveau de moins d'une semaine, et Firefox 4 ou Chromium 10.0.648.205.)

Certes, on peut quand même avoir du WebGL sans accélération (solution (1b)) : sous Firefox 4, il s'agit essentiellement d'installer la bibliothèque libosmesa version 6 et de configurer webgl.osmesalib pour en donner le chemin (typiquement /usr/lib/libOSMesa.so) ; mais c'est tellement lent que j'ai tout de suite craqué.

Mais le pire, c'est que non seulement l'accélération 3D ne marche pas, mais l'accélération 2D ne marche plus non plus. Autrefois ces choses étaient bien séparées : maintenant, la 3D est devenue tellement importante que les cartes graphiques rapportent tout à ça, tant et si bien que si on veut avoir de l'accélération 2D (pour voir un film, pour déplacer les fenêtres de façon fluide, etc.), il faut plus ou moins que la 3D marche. Sur celle de mes machines qui utilise le pilote Radeon ((γ) ci-dessus), par exemple, j'ai de l'accélération 2D, mais uniquement sur le premier serveur X que je lance : que je m'avise d'en ouvrir un second, et plus rien n'est accéléré (il paraît que la solution à ce problème consiste à utiliser KMS, mais tout ce que j'ai réussi à en tirer c'est un écran noir) ; quant au pilote Nouveau ((β)), il a l'air tellement peu accéléré que le simple avertissement visuel du terminal (XTerm a une option pour changer brièvement de couleur au lieu de bipper) est atrocement lent.

Finalement, l'accélération 3D marche mieux sur mon téléphone mobile que sur mon ordinateur.

↑Entry #1867 [older| permalink|newer] / ↑Entrée #1867 [précédente| permalien|suivante] ↑

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]