Mesa, l’OpenGL libre
En mettant à jour récemment Chromium (la version libre de chrome) sous Ubuntu, je me suis retrouvé avec la version 20 qui supporte enfin WebGL, auparavant, seul Firefox me permettait d’utiliser WebGL. Comme j’utilise le pilote libre Mesa et le processeur graphique (GPU) intégré Intel HD 3000 intégré APU (non commercial pour les SoC mal finis de technologie x86), il y a pour le moment des limitations. Mesa est en retrait des autres pilotes au niveau de la compatibilité OpenGL et OpenGL ES (à l’origine à destination de l’embarqué, ES=Embedded System, signifiant système embarqué).
Dans les versions 7.x la compatibilité OpenGL 2.x était présente.
En Mesa 8.0 sorti le 9 février 2012, on atteignait à peu près la compatibilité OpenGL 3.0, globalement stabilisé en mai après avec la 8.0.3, la 8.0.4 finissant la stabilisation en juillet 2012. En Mesa 9.0 (quasi stable) qui devrait sortir officiellement ce mois ci (septembre 2012) ou en début de mois prochain, on atteint la compatibilité OpenGL 3.1 et presque complète 3.2 et 3.3 avec des bouts d’OpenGL 4.x. Sur la tronc de développement, des bouts d’OpenGL ES 3 commencent également à être implémentés, une évolution d’OpenGL ES reprenant les améliorations d’OpenGL 3 et 4. On a toujours des gros bugs niveaux textures (notamment entre mode textures compressées et non compressées avec le simulateur de vol libre Flightgear) et reconnaissance sur différentes applications (un patch publié aujourd’hui résoudra peut être ce problème ?).
Depuis environ un an ça avance donc beaucoup plus vite, mais il y a encore du retard à rattraper, j’estime au pifomètre (avec une grosse marge d’erreur), en voyant les évolutions, qu’il y en a encore pour environ un an ou un peu plus pour rattraper le retard.
Textures compressées
La mémoire graphique utilisé par le processeurs graphiques (GPU) étant toujours finie et donc limitée, on a intérêt à compresser les textures afin de gagner de la place et d’éviter de transférer les grosses textures depuis la mémoire vive de l’ordinateur, tache longue, d’autant plus que cela ralentie le transfert des données fondamentales, coordonnées des objets, rotation, transformations etc…. et que pour le GPU, la décompression de ces textures est un calcul plutôt léger voir négligeable. Le Taïwanais S3 à mis au point il y a quelques années cette technique et le format de texture compressé DDS (DirectDraw Surface). C’est devenu un standard de fait, mais le logiciel est breveté, obligeant dans les pays ayant eu la mauvaise idée d’autoriser le brevet logiciel (notamment États-Unis d’Amérique et Japon, on y échappe pour le moment en Europe) à en limiter l’utilisation, ralentissant ainsi les progrès techniques. Heureusement, la norme OpenGL 4.x introduit une méthode non-brevetée de compression et compatible.
Voici un exemple de textures compressées, si cela ne fonctionne pas chez vous pour le moment, lisez le reste de l’article :
http://media.tojicode.com/webgl-samples/dds.html
WebGL
WebGL est un standard de représentation 3D dans les pages web au format HTML5, basé sur le standard OpenGL ES 2.0, lui permettant d’être adaptable sur le matériel embarqué, comme les tablettes ou téléphones mobiles. Il y a déjà eu différents essais de normes qui ont eu un succès très limité. Mais aujourd’hui WebGL est relativement mature et supporté par tous les navigateur répandus (Firefox, Chrome et Chromium, Opéra, Safari, …), à l’exception, comme d’habitude, de Microsoft Internet Explorer. Il le supportera probablement, comme à son habitude avec les standards, sans doute plus ou moins bien d’ici 1 ou 2 ans. On y est maintenant habitué et il perds, pour cela jour après jour des parts de marché. Il avait 75 % de part de marché il y a quelques années, et est encore 2e navigateur derrière Chromium (27 %), avec environ 23 % selon les statistiques d’août 2012 de Wikipédia, ce qui est encore trop, suivi par Firefox avec 18 %). Wikipédia étant le 5e site le plus visité au monde, cela donne une bonne idée de la répartition des navigateurs.
Google a également crée Google Chrome Frame qui permet d’utiliser du vrai HTML5 avec Internet Explorer.
WebGL à l’avantage d’être un standard ouvert et libre (sans contraintes d’utilisation), et d’être quasiment similaire à OpenGL ES, OpenGL étant le premier et principal standard de 3d, utilisé par 99% des téléphones et autres matériel, la majorité des consoles de jeux et les ordinateurs (Windows utilise également Direct3D, qui est un peu plus lent et plutôt fermé).
Mozilla Firefox et Google Chromium
Firefox un navigateur ouvert et relativement libre (restriction au niveau du nom ayant poussé à des dérivés IceWeasel et autres), dérivé de Mozilla, lui même dérivé de Netscape fût pendant longtemps le principal navigateur web. détrôné par IE pendant quelques années sous Windows et maintenant par Google Chrome plus généralement.
Google Chrome est le navigateur fermé de Google (qui refile, comme Apple et Microsoft) toutes vos infos confidentiels aux services secrets des États-Unis d’Amérique et a quelques autres sociétés contre un peu d’argent. Google Chromium est quand à lui une version ouverte et libre.
Mozilla Firefox comme Google Chromium ont tous deux pleins d’outils espions (ou fonctionnalités) Google intégrées, Dans Firefox, il suffit de taper dans la barre de navigation : about:config pour nettoyer la majorité, et de désactiver Google dans les moteurs de recherche (et remplacer par une occurrence de votre choix de Seeks) (local ou un des nombreux nœuds existants. Sous Chromium c’est encore plus dur, mais on peut aussi supprimer les moteurs Google et limiter les dégâts.
Sortons du thème du contre-espionnage et venons en à ce qui me motive pour ce billet. Firefox et Chromium se font une guerre effrénées aux meilleurs performances, pour notre plus grand bien. Chromium à toujours était globalement plus gourmand en mémoire, mais à eu l’avantage dès sa sortie d’être multi-thread (se répartissant bien sur les différents processeurs, plus de réactivités lors qu’un des onglets de réagit pas, etc..) et surtout plus rapide. Firefox l’avait largement devancé en performance mono-thread (pour javascript avec le test Sunspider 9.1) en début d’année, mais était toujours moins réactif du fait de son fonctionnement globalement monothread. Il y a quelques mois, il est devenu mono-thread, explosant ainsi Chromium au tests JavaScript. Chromium 20 a comblé son retard et même devancé Firefox. il utilise maintenant autant de cœurs de processeurs en parallèle mais de façon plus légère tout en étant plus rapide. 15 s pour chromium 20 contre 25 s pour firefox 15 au test Sunspider 9.1. Les versions suivantes de Sunspider seront un peu modifiée pour avantager Chromium sur des fonctionnalités non standard{{refnec}} et ne seront donc pas intéressant pour les tests.
Chromium et WebGL avec Mesa et GPU Intel
Chromium 20 supporte enfin WebGL sur mon système mais il pose encore quelques problèmes.
Avec Firefox jusqu’à 15 (paquet Ubuntu ou Mozilla standard) et avec Chromium 20 (paquet ubuntu 12.04 standard) fonctionnent mais ne supportent pas les textures compressées avec Mesa et GPU Intel. il faut pour contourner se problème régler la variable d’environnement force_s3tc_enable=true avant de lancer l’un de ces navigateurs.
Firefox 16 (actuellement beta4) supporte les textures compressées indépendamment, je ne sais pas pourquoi, je soupçonne une décompression soft, il faut que je cherche, dans ce cas, on aurait avantage à également utiliser le flag, plutôt que de le lancer et d’avoir un ralentissement des applications.
Chromium 21 et 22 (récupérés sur des PPA) ne considèrent plus que mon GPU supporte WebGL, il faut donc lui forcer la main avec l’option : --ignore-gpu-blacklist et tout fonctionne bien.
J’ajoute à chrome une autre argument : --no-sandbox qui permet d’éviter que celui-ci soit lancé en SUID (root) et expose ainsi à tout le web des failles de sécurité béantes à mon système.
Donc, pour le côté pratique je réuni tout ça dans un script qui peut être appelé en ligne de commande ou dans l’interface graphique du système :
#!/bin/bash
force_s3tc_enable=true /usr/bin/chromium-browser --no-sandbox --ignore-gpu-blacklist $1
J’appelle ce script /usr/bin/chromium3d et lui donne les droits d’exécution (chmod +x /usr/bin/chromium3d. le $1 lui permet de récuperer le premier argument (l’URL lorsqu’on click sur un lien où l’ajoute sur le ligne de commande).
Maintenant, le FPS Bananabread devrait fonctionner chez vous