Les pilotes graphiques libres : rétrospective et vue sur l’avenir

Cette année 2015 fut très riche et très excitante au sujet des pilotes graphiques libres. Grosse nouveauté, Mesa 3D 11 a été annoncée le 12 septembre 2015, avec une prise en charge d’OpenGL 4.2, après une très longue stagnation en version 3.3.

Cette dépêche fait donc la part belle aux récentes nouveautés de Mesa 3D, mais s’attarde aussi sur les actualités des puces graphiques embarquées, et se permet quelques incursions du côté de certains pilotes propriétaires dans leur collaboration avec les projets libres ou leurs initiatives qui profitent à tous.

Pour finir, nous nous permettrons d’annoncer quelques actualités à venir ayant pris racine en 2015.

Merci à tous les contributeurs de cette rétrospective !

Sommaire

• Nouveautés de Mesa 3D à la lumière du trio AMD, Intel & NVIDIA
  • Un peu d’histoire
  • Mesa 3D 11.0
  • Mesa 3D 11.1
  • Adaptive Scalable Texture Compression
  • Progression de l’initiative amdgpu
  • NIR (New Intermediate Representation)
  • Lentement mais sûrement
• Évolution du côté de l’écosystème ARM
  • Freedreno
  • Etnaviv
  • VC4
  • PowerVR
  • Lima & Tamil
  • Tegra
  • Allwinner
• Les attentes de l’année 2016
  • Vulkan
  • Mesa 3D 11.2 : quelques prédictions
  • OpenGL Vendor Neutral Dispatch Library
  • GPUOpen
  • OpenSWR
  • Bientôt de gros changements du côté des performances chez radeonsi ?

Après des années de stagnation à n’annoncer que la prise en charge d’OpenGL 3.3, les développeurs de la bibliothèque Mesa 3D ont annoncé fin 2015 la prise en charge d’OpenGL 4.2 ! Actuellement, seuls les pilotes radeonsi et nouveau (pour les processeurs graphiques Fermi NVC0) prennent en charge OpenGL 4.1. Aucun pilote matériel ne prend encore en charge OpenGL 4.2 et les autres pilotes restent encore à OpenGL 3.3. Mais cela arrive vite ! Pourquoi un tel saut ? Qu’est‐ce que cela signifie ? Comment en profiter ? On fait le tour !

En attendant l’inclusion dans les dépôts officiels des distributions, les plus intrépides peuvent déjà bénéficier de toutes ces avancées en utilisant des dépôts tiers (comme les dépôts padoka et oibaf sur Ubuntu).

Nouveautés de Mesa 3D à la lumière du trio AMD, Intel & NVIDIA

Un peu d’histoire

Pourquoi la pile graphique Mesa 3D est‐elle passée d’un coup de la prise en charge d’OpenGL 3.3 à OpenGL 4.1 sans passer par l’étape intermédiaire 4.0 ? En réalité, comme on peut le voir sur l’excellente page mesamatrix.net (merci Creak<), chaque version d’OpenGL est une liste de différentes extensions à implémenter. Or, elles ne sont pas nécessairement implémentées dans l’ordre, ou bien elles le sont dans un ordre différent de celui auquel on pourrait s’attendre.

C’est pourquoi, par exemple, on peut voir que le pilote Intel i965 a une certaine avance sur ses concurrents de chez NVIDIA et AMD concernant la prise en charge d’OpenGL 4.2 (les extensions 4.2 sont toutes implémentées), mais comme il lui reste à implémenter une extension 4.0 et une extension 4.1, il reste bloqué à la version 3.3. Il en était exactement de même pour les pilotes nouveau et radeonsi qui stagnaient en 3.3 malgré de nombreuses extensions 4.0 et 4.1 implémentées.

C’est pour cette raison que, bien que Mesa 3D annonce déjà la prise en charge d’OpenGL 4.2, en réalité, vous ne pourrez pas en bénéficier, car aucun pilote matériel n’est encore à ce niveau‐là…

Si Intel est encore en 3.3 (bouh, même les reverseux font mieux !), il faut tout de même noter qu’ils ont la liste d’extensions implémentées la plus complète, ils ont repris la tête du peloton après s’être fait temporairement doubler par le projet nouveau.

Si l’on est attentif, on remarque qu’en réalité Intel priorise la prise en charge d’OpenGL ES 3.1, qui regroupe un sous‐ensemble d’extensions communes à différentes versions d’OpenGL. On comprend donc pourquoi la prise en charge des extensions semble désordonnée malgré un grand nombre d’extensions développées… Intel est actuellement la seule plate‐forme à prendre entièrement en charge OpenGL ES 3.1, on ne peut pas être partout à la fois !

Pour bénéficier d’une prise en charge d’OpenGL supérieure à 3.3, il ne suffit pas d’utiliser une version récente de Mesa 3D, il faut que Mesa 3D ait été compilé avec une version récente de LLVM (plus de détails sont fournis ci‐après).

Mesa 3D 11.0

De gros changements du côté de Mesa 3D ont fait les titres à l’été 2015.

Le 23 juillet 2015, Dave Airlie a ajouté à Mesa 3D la prise en charge de l’extension ARB_shader_subroutine, qui était la dernière qui restait à implémenter pour que Mesa 3D annonce la prise en charge d’OpenGL 4.0. Au même moment, Ilia Mirkin envoyait du code pour la prise en charge du pavage (tesselation) pour les cœurs graphiques Intel, et Marek Olšák en faisait de même pour les cœurs et cartes graphiques AMD.

Mais cela ne s’arrêtait pas là, car à cet instant il ne manquait plus à Mesa 3D qu’une seule extension pour annoncer la prise en charge d’OpenGL 4.1 : GL_ARB_shader_precision, et une seconde extension pour annoncer la prise en charge d’OpenGL 4.2 : ARB_shader_image_load_store.

Tout cela est arrivé très vite : Dave Airlie annonça la prise en charge d’OpenGL 4.1 le 28 juillet, et l’extension ARB_shader_image_load_store fut ajoutée le 11 août. Ainsi, la liste des extensions nécessaires fut enfin complète pour annoncer la prise en charge d’OpenGL 4.2.

Jusque‐là, Mesa 3D n’annonçait donc que la prise en charge d’OpenGL 3.3. Certains proposaient de renommer Mesa 3D 10.7 en Mesa 3D 11, qui allait être distribué en septembre. Il faut dire que ça valait le coup ! Emil Velikov sanctionna cette numérotation le premier août et publia Mesa 3D 11.0 le 12 septembre.

Mais attention, le pilote Gallium3D radeonsi (le pilote qui gère les puces graphiques Radeon basées sur l’architecture Graphics Core Next, ou GCN) utilise un compilateur de shader construit à partir de LLVM. L’architecture GCN étant utilisée par toutes les cartes graphiques d’AMD depuis les Radeon HD 7xxx, pour prendre en charge OpenGL 4.0, Mesa 3D devait être compilé avec LLVM 3.6.2, tandis que pour OpenGL 4.1 et supérieur, Mesa 3D devait être compilé avec LLVM 3.7, qui était alors annoncée pour fin août. C’est finalement le premier septembre qu’Hans Wennborg a annoncé la publication de LLVM 3.7, ce qui a enfin permis au public libriste de bénéficier d’OpenGL 4.x.

Mesa 3D 11.1

Mesa 3D 11.1 voit l’arrivée d’un tout nouveau pilote nommé VirGL basé sur Gallium3D. Ce pilote permet à une machine virtuelle de bénéficier de l’accélération matérielle de la machine hôte. Pour en bénéficier, il faut utiliser un noyau Linux 4.4 (qui n’est sorti qu’en janvier 2016) et un QEMU récent.

Pour rester du côté de la virtualisation, le pilote VMware (VMWgfx) prend désormais en charge OpenGL 3.3.

Du côté de la bibliothèque de calcul intensif exécuté sur processeurs graphiques, OpenCL, le travail a commencé pour les cartes NVIDIA des générations Tesla NV50 et Fermi NVC0. Très peu de choses sont implémentées pour le moment, mais c’est encourageant.

Le pilote Intel permet désormais l’anticrénelage 16× MSAA (à partir des processeurs Skylake).

AMD a contribué à la gestion du décodage H.265/HEVC pour Gallium3D, accessible via l’interface VA-API.

Côté plate‐forme ARM, le pilote Freedreno prend désormais en charge OpenGL 3.1, et le pilote VC4 pour Raspbery Pi a été beaucoup retravaillé. Vous trouverez plus de détails concernant ces processeurs graphiques plus loin dans la dépêche.

Adaptive Scalable Texture Compression

Intel a publié en août 2015 du code pour prendre en charge le format ASTC à partir de la plate‐forme Skylake Gen9. ASTC, pour Adaptive Scalable Texture Compression est un format de compression de texture exempt de brevets destiné à remplacer S3TC (bardé de brevets, lui). Le principe de ces formats de compression est que la décompression est faite par la carte graphique elle‐même. Ainsi, à la différence, par exemple, d’une texture JPEG qui serait décompressée par le processeur généraliste (qui est donc mis à contribution) et qui serait ensuite envoyée décompressée à la carte graphique (ce qui consomme beaucoup de bande passante), la texture est envoyée directement compressée à la carte qui se charge de la décompresser elle‐même, économisant donc les ressources de calcul du processeur généraliste et la bande passante entre la mémoire centrale et la mémoire dédiée du processeur graphique. En plus d’être exempt de brevet, ce nouveau format est bien évidemment meilleur et a la bonne idée d’être officiellement pris en charge par les récentes spécifications OpenGL, OpenGL ES et DirectX. Les fabricants aussi expriment leurs enchantements concernant ce nouveau format, ASTC est donc le format du futur qui met tout le monde d’accord !

Progression de l’initiative amdgpu

En octobre 2014, lors de la XDC 2014 (X.Org developer conference), Alex Deucher a annoncé qu’AMD souhaitait augmenter le partage de code sous Linux entre le pilote libre et le pilote propriétaire. Pour cela, les développeurs allaient créer un nouveau pilote noyau nommé AMDGPU qui pourrait être utilisé aussi bien par le pilote libre Mesa 3D/Gallium3D que par un nouveau pilote propriétaire redistribué par AMD, la partie binaire et fermée étant limitée à l’espace utilisateur.

Le 20 avril 2015, Alex Deucher publie la version initiale du pilote amdgpu. Ce nouveau pilote est créé comme une copie du pilote radeon et est ensuite adapté pour gérer les particularités des nouveaux processeurs graphiques. Il peut gérer les puces CI (Sea Islands) pour tester le pilote, mais celui‐ci est prévu pour les nouvelles cartes (Volcanic Islands et suivantes). Le pilote a été intégré dans le noyau Linux 4.2 et reçoit depuis des améliorations à chaque nouvelle version du noyau. Par exemple, une nouvelle gestion de l’alimentation appelée powerplay, destinée à remplacer DPM (Dynamic Power Management), sera intégrée à la version 4.5 de Linux. Dans le même temps, la partie libdrm a été intégrée et le pilote Gallium3D radeonsi a été mis à jour pour gérer le pilote amdgpu. En revanche, à l’heure actuelle, il n’y a pas d’information sur la publication du pilote propriétaire qui sera basé sur le pilote amdgpu. Le pilote Vulkan d’AMD devrait dans un premier temps être seulement disponible pour Linux sous forme binaire, et il est possible que le premier pilote propriétaire basé sur le pilote amdgpu sera celui intégrant Vulkan.

Pendant ce temps, AMD a renommé sa suite de pilotes propriétaires et le centre de contrôle Catalyst Control Center en Radeon Software Crimson Edition. Si les utilisateurs de Windows bénéficient déjà de changements sensibles (amélioration des performances et nouvelle interface utilisateur), les utilisateurs de GNU/Linux ne voient que le même pilote et les mêmes outils sous un nouveau nom. Il est fort probable que ce pilote amdgpu fasse partie de cette nouvelle stratégie commerciale et que les améliorations promises par Crimson seront fournies lorsque le pilote propriétaire rebasé sur amdgpu sera publié. Tout comme le pilote amdgpu est prévu pour les cartes de dernière génération, la suite Crimson annonce ne prendre en charge que les cartes basées sur l’architecture GCN (Graphics Core Next), ce qui correspond à peu près au même périmètre.

NIR (New Intermediate Representation)

Le code GLSL des jeux ou applications 3D nécessite d’être compilé en langage machine avant de pouvoir être exécuté par les unités de shader du processeur graphique. Mesa 3D utilise une représentation intermédiaire appelé GLSL IR, mais celle‐ci a des défauts difficiles à résoudre. Dans le cadre d’un stage chez Intel, Connor Abbott avait travaillé sur un nouveau langage intermédiaire qui permet de mieux gérer le code des shaders et de meilleures optimisations. C’est ainsi que NIR est né.

Présenté a la XDC 2014 à Bordeaux, il a été intégré dans Mesa 3D en janvier 2015, grâce au travail de Jason Ekstrand de chez Intel (sa présentation de NIR sur la liste mesa-dev vaut la lecture). NIR a continué de mûrir tout au long de l’année et un nombre croissant de pilotes l’utilisent désormais. NIR est aujourd’hui utilisé par défaut par le pilote Intel, le pilote VC4 (Raspberry Pi 1 et 2) et le pilote Freedreno.

Un convertisseur SPIR-V vers NIR est également en cours de développement. SPIR-V est un format standard de représentation intermédiaire de shader. C’est un format en bytecode pré‐optimisé qui est ou sera utilisé par OpenCL 2.1 et Vulkan. Avec OpenGL, les shaders GLSL sont fournis au pilote 3D en format texte, le pilote doit donc embarquer un analyseur de texte, un optimiseur de code et enfin un compilateur pour générer le code machine. Avec SPIR-V, le pilote n’a plus besoin que du compilateur final (et éventuellement d’un petit optimiseur), ce qui est plus léger à la fois en empreinte mémoire et en temps de calcul.

Lentement mais sûrement

Vous vous souvenez peut‐être de la campagne de financement participatif visant à salarier Timothy Arceri (il n’en est pas à son coup d’essai) pour travailler sur l’implémentation de l’extension Array of array (prérequis de OpenGL ES 3.10 et GLSL 4.30) ? Cela a été long, mais le travail n’a pas été abandonné ! Ce dernier travail de Timothy a été fusionné dans Mesa 3D et la première à en bénéficier est la plate‐forme Intel (depuis le 4 novembre), les autres plates‐formes devraient suivre sous peu. Tout cela a mis beaucoup de temps parce que le processus de revue pour inclusion est assez lent mais, bonne nouvelle, Timothy annonçait en septembre qu’à partir de novembre, il serait embauché par Collabora pour travailler à temps plein sur Mesa 3D. Sa priorité désormais est de travailler sur l’extension GL_ARB_enhanced_layouts, une extension OpenGL 4.4.

Côté OpenCL, beaucoup de choses sont encore à faire… Comme indiqué précédemment, le développement pour nouveau est balbutiant. Du côté de radeonsi, la version 1.1 de la norme est exploitable, mais la prise en charge des images n’y est pas fonctionnelle. En revanche, le développement de Beignet (Intel) est assez actif, mais a lieu en dehors de Mesa 3D. Pour le moment, si vous souhaitez bénéficier de l’OpenCL (par exemple avec Darktable), il vous faudra encore vous tourner vers les pilotes propriétaires pour les cartes autres qu’Intel. On peut cependant noter que Clover intègre déjà certaines fonctionnalités de la norme 1.2, par exemple clCreateImage. Espérons que les choses seront plus encourageantes en 2016 !

Évolution du côté de l’écosystème ARM

Les systèmes monopuces (System On a Chip) ont la particularité d’avoir un découpage explicite en modules des fonctionnalités fournies ensemble par les processeurs graphiques d’ordinateurs de bureau. Là où, grâce à un seul pilote, un processeur graphique de bureau prend en charge la gestion de l’affichage (sortie vidéo), les accélérations 2D et 3D, ainsi que les accélérations de l’encodage et du décodage vidéo, les systèmes monopuces ARM ont souvent des modules et pilotes séparés pour les différentes parties. Modules qui peuvent même venir de concepteurs différents.

De nombreux moteurs d’affichage utilisés par les systèmes monopuces ARM ont un pilote développé en amont dans le noyau Linux, et de nouveaux pilotes sont régulièrement intégrés. On peut citer omap, imx, etc. Mais beaucoup de modules d’accélération 2D/3D ont un pilote intégré ; pour l’instant, il y a le pilote freedreno, tandis qu’un pilote etnaviv est en développement pour une intégration prochaine (peut‐être pour le noyau 4.5 ?).

Freedreno

Les processeurs graphiques Adreno des systèmes monopuces Snapdragon de Qualcomm utilisent un pilote nommé freedreno. Le développement de ce pilote libre a été démarré en rétro‐ingénierie par Rob Clark pendant son temps libre ; Rob a ensuite été embauché par Red Hat pour continuer de travailler dessus et sur la pile graphique Linux par la même occasion. Les processeurs graphiques Adreno ont une base commune avec les processeurs graphiques Radeon (Qualcomm a racheté la branche processeurs graphiques mobiles d’AMD), le fait que les Radeon aient un pilote libre et de la documentation publique aurait aidé la rétro‐ingénierie. Aujourd’hui, le pilote progresse bien, il est actuellement capable de gérer jusqu’à OpenGL ES 3.0 (pour le matériel qui le prend en charge), reçoit la participation de Qualcomm et la prise en charge des nouveaux processeurs graphiques est intégrée peu à peu. Un travail est également en cours pour que ce pilote marche avec Android, et peut‐être même deviendra‐t‐il un jour le pilote officiel pour Android ?

Etnaviv

Les modules d’accélération 2D/3D vectoriels de Vivante sont pris en charge par le pilote libre etnaviv. Les processeurs graphiques Vivante bénéficient d’un pilote noyau libre qui utilise l’API fbdev (mais qui n’est pas intégré au noyau Linux en amont) et d’une partie propriétaire en espace utilisateur.

Initialement nommé etna_viv, le projet a été lancé par Wladimir J. van der Laan et rendu public au début de l’année 2013. Il a créé un pilote libre en espace utilisateur par rétro‐ingénierie. Ensuite, Christian Gmeiner a pris le relai pour créer un pilote noyau KMS et DRM, mais y travaillant uniquement sur son temps libre, la progression était lente. Heureusement, au printemps 2015, Lucas Stach a diffusé une série de modifications correspondant à un pilote KMS. Ce pilote a été créé sur la base du travail de Christian et activement développé par Russell King (Le mainteneur ARM dans le projet Linux) et Lucas dans le cadre de son travail chez Pengutronix.

Plusieurs mises à jour ont depuis été diffusées sur la liste de diffusion dri-devel, et le code pour la libdrm et Mesa 3D (Gallium3D) progresse avec le travail de Christian, Russell et Lucas. D’ailleurs, Christian maintient sur son profil GitHub un dépôt libdrm et un dépôt Mesa 3D. Les précédentes diffusions sur la liste de de diffusion dri-devel du noyau Linux avaient seulement pour but de recueillir des retours des autres développeurs de pilotes DRM, mais le 4 décembre une série de correctifs de la partie noyau du pilote a été diffusée pour relecture dans le but, cette fois, d’avoir une intégration dans la branche principale. Une deuxième version avec quelques corrections a été diffusée le 9 décembre, et le 15 décembre une demande d’intégration dans le noyau 4.5 a été diffusée sur la liste de diffusion dri-devel.

On est donc en bonne voie de pouvoir utiliser une Fedora avec bureau GNOME 3 (par exemple) de façon fluide sur une Wandboard ou une Cubox-i dans les mois à venir (ou autre utilisation d’OpenGL).

VC4

Le processeur graphique des Raspberry Pi (1 et 2) est le VC4. Broadcom a embauché Eric Anholt pour travailler sur un pilote libre (KMS/DRM + Mesa 3D/Gallium3D). Côté Mesa, le pilote Gallium3D vc4 est intégré en amont depuis quelque temps et continue d’évoluer. Côté noyau, une première version du pilote a été intégrée dans la version 4.4, cette première version permet la prise en charge du module de gestion de l’affichage. Le code permettant l’accélération 3D devrait être intégré dans la version 4.5.

PowerVR

Nous n’avons pas d’informations sur un éventuel pilote libre pour processeur graphique PowerVR, mais Imagination cherche un programmeur pour travailler sur un pilote Linux (espérons que ce soit un pilote libre)…

Lima & Tamil

Les processeurs graphiques Mali (venant directement d’ARM) ont pour eux le projet libre de pilote Lima. Bien qu’ayant démarré début 2012 et ayant bien progressé (il a réussi à faire fonctionner Quake III Arena), le projet est en pause depuis plus de deux ans. La dernière nouvelle sur le site officiel était de mars 2013, mais un appel à contribution est apparu le 20 décembre 2015, signifiant peut‐être un redémarrage du projet (en tout cas une certaine volonté). Il semblerait qu’ARM ne le voyait pas d’un très bon œil, en effet sur le blog de Luc Verhaegen on peut lire une publication datant du 23 avril 2015 :

In May 2013, I wrote another proposal to ARM for an open source strategy for Mali (the first was done in Q2 2011 as part of Codethink), hoping that in the meantime sentiments had shifted enough and that the absence of an in‐between company would make the difference this time round. It got the unofficial backing of some people inside ARM, but they just ended up getting their heads chewed off, and I hope that they didn’t suffer too much for trying to do the right thing. The speed with which this proposal was rejected by Jem Davies (ARM MPD VP of Technology), and the undertone of the email reply he sent me, suggests that his mind was made up beforehand and that he wasn’t too happy about my actions this time either.

Traduction :

« En mai 2013, j’ai écrit une nouvelle proposition à ARM à propos d’une stratégie open source pour Mali (la première avait été faite au 2^e trimestre 2011 dans le cadre de Codethink), espérant qu’entretemps en l’absence de société intermédiaire, leur point de vue aurait significativement évolué. Elle a reçu un soutien non officiel de gens chez ARM, mais ils ont juste obtenu le droit de se taire, et j’espère qu’ils n’ont pas trop souffert d’avoir essayé de faire le bon choix. La vitesse avec laquelle ma proposition a été rejetée par Jem Davies, et le ton de son courriel de réponse, suggérait que son opinion était déjà faite et qu’il n’était toujours pas très emballé par mes actions. »

Sur ce même blog, on peut lire que l’écriture du pilote Mali lui a causé beaucoup de déboires ; il soupçonne même que son renvoi d’une société fût causé par le lobbying d’ARM :

When Codethink ran into a cashflow issue in October 2012 (which apparently was resolved quite successfully, as Codethink has grown a lot more since then), I was shown the door. This wasn’t too unreasonable a decision given my increasing disappointment with how Lima was being treated, the customer projects I was being sent on, and the assumption that a high profile developer like me would have an easy time getting another employer. During the phonecall announcing my dismissal, I did however get told that ARM had already been informed about my dismissal, so that business relations between ARM and Codethink could be resumed. I rather doubt that that is standard procedure for dismissing people.

Traduction :

« Quand Codethink a eu des problèmes de trésorerie en octobre 2012 (qui apparemment ont été plutôt bien résolus, puisque Codethink s’est beaucoup développé depuis), on m’a mis à la porte. Cela n’était pas une si mauvaise décision vue ma déception grandissante quant à la manière dont a été traité Lima, les projets client sur lesquels j’ai été envoyé, et en considérant qu’un développeur hautement qualifié comme moi aurait de la facilité à trouver un autre employeur. Pendant la conversation téléphonique annonçant mon licenciement, on m’a cependant laissé entendre qu’ARM avait déjà été informé de mon départ, de telle sorte que les relations commerciales entre ARM et Codethink pourraient être restaurées. Je doute que ce soit une procédure standard de licenciement. »

Tout cela est vraiment dommage, car on peut trouver ce processeur graphique dans une multitude de systèmes monopuces comme, par exemple, les Allwiner A10 et A20, la majorité des Exynos… Luc Verhaegen, l’auteur des pilotes Lima et Tamil (pour les processeurs graphiques Mali T-Series), explique qu’il n’est plus aussi motivé pour nettoyer et faire évoluer le code de ces pilotes. Lima et Tamil existent, mais seul Lima est sorti. Personne n’est suffisamment intéressé pour l’embaucher et financer le travail sur ces pilotes. Beaucoup de monde (personnes, entreprises, organisations) lui expliquent que cela ne sert à rien et que l’existence d’un pilote libre pourrait même être contre‐productif. Linaro, une organisation dont le but est de faire tourner Linux sur ARM, explique qu’elle compte sur le soutien d’ARM pour avancer ; mais Linaro (et certainement d’autres…), ne voulant pas se fâcher avec ARM, ne veut pas subventionner Luc Verhaegen.

En tout cas, une chose est sure, c’est que le manque de soutien général l’a réellement démotivé pendant pas mal de temps (au moins deux ans), mais il semblerait que cette période soit passée, peut‐être travaillera‐t‐il à nouveau sur Lima :

When I was putting together the FOSDEM Graphics DevRoom schedule around christmas, I noticed that there was a inexcuseably low amount of talks, and my fingers became itchy again. The consulting job had boosted morale sufficiently to do some code again and showing off some initial renders on Mali T series seemed doable within the 5 or so weeks left. It gave the FOSDEM graphics devroom another nice scoop, and filled in one of the many many gaps in the schedule. This time round i didn’t kid myself that it would change the world or help boost my profile or anything. This time round, i was just going to prove to myself that i have learned a lot since doing Lima, and that i can do these sort of things still, with ease, while having fun doing so and not exerting myself too much. And that’s exactly what I did, nothing more and nothing less.

Traduction :

« Lorsque j’étais en train de mettre sur pieds le programme de la conférence des développeurs de pilotes graphiques pour le FOSDEM aux environs de Noël, j’ai remarqué qu’il y avait un manque inexcusable de conférences, et mes doigts se mirent à nouveau à me démanger. Le travail de consultant a suffisamment renforcé mon moral pour coder à nouveau et présenter quelques rendus initiaux sur le Mali série T semblait faisable dans les quelque cinq prochaines semaines restantes. J’ai donné à l’assemblée des développeurs de pilotes graphiques du FOSDEM un scoop sympa, et rempli une des très nombreuses lacunes du programme des conférences. Cette fois, je ne voulais pas jouer à changer le monde ou me faire mousser, mais je voulais me prouver que j’avais beaucoup appris depuis que j’avais travaillé sur Lima, et que je pouvais encore faire ce genre de choses, avec facilité, tout en prenant du plaisir à le faire et sans trop me surmener. Et c’est exactement ce que j’ai fait, ni plus ni moins. »

Malgré tout, les choses avancent dans la prise en charge des Mali sur Linux. Phoronix avait publié un petit état des lieux en avril, à défaut de code, il faudra s’en contenter pour le moment.

Tegra

Les systèmes monopuces de la gamme Tegra semblent avoir leur pilote principal de moteur d’affichage nommé tegra, et NVIDIA a travaillé pour utiliser Nouveau pour les Tegra K1 et X1. Ces systèmes monopuces utilisent des processeurs graphiques directement dérivés de leurs homologues dédiés aux ordinateurs de bureau (respectivement les architectures Kepler et Maxwell). Pour les systèmes monopuces plus anciens Tegra 1 à 4, il existe une documentation partielle, un pilote libre (grate) existe.

Allwinner

Le pilote du moteur d’affichage des systèmes monopuces Allwinner est développé par un employé de Free Electrons. En revanche, la partie accélération 3D est gérée par des modules Mali de chez ARM ou PowerVR de chez Imagination Technologies, qui ne possèdent pas de pilotes libres. Ses pilotes sont nommés sun4i et sunxi dans le noyau Linux.

Les attentes de l’année 2016

Vulkan

Vulkan est une API poussée par le groupe Khronos (les mêmes derrière OpenGL) qui a pour but affiché de remplacer OpenGL dans le futur et de proposer dès maintenant une interface plus moderne. Vulkan se veut multi‐plate‐forme. Il est soutenue par de nombreux acteurs majeurs du marché, et annonce de bien meilleures performances qu’OpenGL (voir la page Wikipédia Vulkan pour plus de détails et de vulgarisation en français). Connue initialement sous le nom de code glNext, Vulkan a été annoncé lors de la Game Developers’ Conference de 2015. La publication des spécifications était attendue pour fin 2015, mais cela ne devrait plus tarder ! Cependant, si nous savons que certains pilotes propriétaires seront publiés avec la prise en charge de Vulkan dès la publication des spécifications, il faudra certainement attendre plus de temps pour en voir une implémentation dans les pilotes Mesa 3D.

Mesa 3D 11.2 : quelques prédictions

Intel est en train de rattraper son (apparent) retard, mais les nouveautés intéressantes sont arrivées trop tard pour faire partie de la version 11.1, comme le code pour le pavage (tesselation), pourtant déjà fonctionnel chez Intel.

Du côté des radeon R600, le code pour le pavage est là aussi.

Chose très intéressante, il ne manquera plus que deux extensions (GL_ARB_vertex_attrib_64bit et GL_ARB_gpu_shader_fp64) pour que le pilote Intel fasse le grand saut depuis OpenGL 3.3 vers OpenGL 4.2. Vivement Mesa 3D 11.2 !

Du côté de chez AMD, les cartes de la génération R600 et celles prises en charge par le pilote radeonsi n’attendent plus que les deux extensions GL_ARB_shader_atomic_counters et GL_ARB_shader_image_load_store pour passer d’OpenGL 4.1 à OpenGL 4.2. Il en est de même pour les cartes NVIDIA de la génération NVC0. Quel pilote activera la gestion d’OpenGL 4.2 le premier ? Intel va‐t‐il laver l’affront ? La course est serrée !

En revanche, nous le savons déjà, les puces graphiques NV50 n’arriveront jamais à l’OpenGL 4 de par leurs limites matérielles… Dommage, mais que cela ne gâche pas la fête : Mesa 3D 11.2 est très attendu !

OpenGL Vendor Neutral Dispatch Library

Le 30 septembre 2015, Kyle Brenneman a annoncé son projet libglvnd (OpenGL Vendor Neutral Dispatch Library) sur la liste de diffusion mesa-dev en vue d’une intégration. C’est une initiative poussée par NVIDIA depuis 2013 et qui semble plutôt bien vue par Mesa 3D, mais à quoi cela sert‐il ? Cela servirait à pouvoir utiliser plusieurs implémentations d’OpenGL en même temps, par exemple la pile OpenGL Mesa 3D sur un écran et la pile propriétaire nvidia sur un autre. Aaron Plattner de chez NVIDIA a publié un premier pilote (bêta) compatible libglvnd le 5 janvier. Cela ne concerne que le pilote propriétaire NVIDIA pour le moment, mais AMD ne cache pas son intérêt et l’on a hâte que libglvnd fasse son petit bout de chemin dans Mesa 3D, et que cela profite à d’autres, ce qui semble bien parti.

GPUOpen

AMD a annoncé en décembre 2015 l’initiative GPUOpen qui vise à concurrencer GameWorks de NVIDIA. L’idée de GPUOpen est un partage de code source libre d’un maximum de ressources logicielles (exemples, démos, librairies). Lors du lancement le 26 janvier 2016, du code a commencé à être publié sur GitHub. Plus de détails peuvent être trouvés dans le journal de freejeff et ses commentaires.

OpenSWR

Intel travaille sur un nouveau rasterizer logiciel nommé OpenSWR et concurrençant LLVMPipe. Un rasterizer est un logiciel de rendu graphique développé pour se satisfaire d’un processeur généraliste. Bien que forcément moins performant qu’un processeur graphique dédié, cela permet par exemple de simplifier les procédures de test de rendu graphique. Timothy Rowley de chez Intel a annoncé ce projet le 20 octobre dernier (l’annonce est très détaillée et vaut le détour), on retiendra que l’équipe derrière ce projet n’est pas la même que celle développant les pilotes des processeurs graphiques chez Intel et que, contrairement à ce dernier, OpenSWR se base sur Gallium3D. OpenSWR annonce de bien meilleures performances que LLVMpipe (OpenSWR répartit notamment plus de tâches entre les cœurs), et est lui aussi basé sur LLVM. OpenSWR fait partie du projet Software Defined Visualization et le code est libre, bien entendu.

Bientôt de gros changements du côté des performances chez radeonsi ?

Grosse surprise de fin d’année 2015, le SI Machine Scheduler, un nouvel ordonnanceur expérimental créé par Axel Davy a fait parler de lui : une fois activé, le pilote libre radeonsi surpasserait Catalyst sur toute la ligne. Cet ordonnanceur est encore expérimental, mais on attend son intégration pour 2016 avec impatience !

Comme l’a écrit darkbasic dans un article qui compare radeonsi et Catalyst :

Catalyst got completely humiliated! Radeonsi is so much faster that I will no longer consider Catalyst as a reference for future performance improvements: we aim at the Nvidia performance now.

Traduction :

« Catalyst s’est fait complètement humilier ! Le radeonsi est tellement plus rapide que, dorénavant, je ne considérerai plus Catalyst comme une référence pour les futures améliorations de performances : maintenant nous visons les performances du pilote nvidia. »

N. D. M. : pondération de l’auteur quelques semaines plus tard :

« As I stated on IRC, the boost was largely due to a big regression reverted in Mesa while doing the first test. Only a little boost is accountable for the SI scheduler. »

Traduction :

« Comme je l’ai écrit sur IRC, le gain était largement dû à une grande régression corrigée dans Mesa 3D pendant mon premier test. Seul un petit gain est imputable à l’ordonnanceur SI. »

L’année 2016 est déjà là, et elle s’annonce comme une année très excitante !

Aller plus loin

• The OpenGL vs Mesa matrix (536 clics)
• Radeonsi with si scheduler humiliates Catalyst in all tests (442 clics)
• Intel Enables ASTC Texture Compression In Mesa For Skylake (146 clics)
• [Mesa-dev] Mesa 11.0.0 (107 clics)
• [Mesa-dev] Mesa 11.1.0 (120 clics)
• Pilote libre Tegra 1 à 4 (169 clics)