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.