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

Logo

Cette année 2015 fut très riche et très excitante au sujet des pilotes graphiques libres. Grosse nouveauté, Mesa 11 a été annoncée le 12 septembre 2015 avec l’annonce de la 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, mais s’attarde aussi sur les actualités des puces graphiques embarquées, et se permet quelques incursions du coté 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

Après des années de stagnation à n’annoncer que la prise en charge d’OpenGL 3.3, la pile Mesa a annoncé fin 2015 la prise en charge OpenGL 4.2 ! Actuellement, seuls les pilotes radeonsi et nouveau (pour les cartes 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 !

Mesa 11.2 et OpenGL 4.1 sur Ubuntu

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 le dépôt padoka ou oibaf sur Ubuntu).

Nouveautés Mesa à la lumière du trio AMD, Intel & nVidia

Un peu d’histoire

Pourquoi la pile Mesa 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 (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 i965 (Intel) a une certaine avance sur ses concurrents 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 annonce déjà la prise en charge d’Open GL 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 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, il faut que Mesa ait été compilé avec une version récente d’LLVM (plus de détails sont fournis ci-après).

Mesa 11.0

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

Le 23 juillet 2015, Dave Airlie a ajouté à Mesa la prise en charge de l’extension ARB_shader_subroutine qui était la dernière qui restait à implémenter pour que Mesa 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 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 qu’une seule extension pour annoncer la prise en charge 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 n’annonçait donc que la prise en charge d’OpenGL 3.3. Certains proposaient de renommer Mesa 10.7 en Mesa 11 qui allait être distribuée en septembre, il faut dire que ça valait le coup ! Emil Velikov sanctionna cette numérotation le premier août et publia Mesa 11.0 le 12 septembre.

Mais attention, le pilote gallium3D radeonsi (le pilote qui gère les Radeons 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 devait être compilé avec LLVM 3.6.2, tandis que pour OpenGL 4.1 et supérieur, Mesa 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 11.1

Mesa 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 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é d’OpenCL, le travail a commencé pour les cartes nVidia des générations nv50 et 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 16x 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é plateforme 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 plateforme 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 consommerait 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 fabriquants 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 (Xorg 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, ils allaient créer un nouveau pilote noyau nommé AMDGPU qui pourrait être utilisé aussi bien par le pilote libre Mesa/Gallium que par un nouveau pilote propriétaire redistribué par AMD. La partie binaire et fermée serait 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 GPU. Il peut gérer les processeurs graphiques CI (Sea Islands) pour tester le pilote, mais celui-ci est prévu pour les nouvelles cartes (Volcanic Islands et suivante). Le pilote a été intégré dans le noyau 4.2 et reçoit depuis des améliorations à chaque nouvelle version du noyau Linux, 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. 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. Par contre, à 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 GPU. Mesa 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, il a été intégré dans Mesa 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/sera utilisé par OpenCL 2.1 et Vulkan. Avec OpenGL les shader GLSL sont fournis au pilote 3D en format texte, le pilote doit donc embarquer un parseur 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 et la première plate-forme à en bénéficier est la plate-forme Intel (depuis le 4 novembre), les autres plate-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. Sa priorité désormais est de travailler sur l’extension GL_ARB_enhanced_layouts, une extension OpenGL 4.4.

Coté OpenCL, beaucoup de choses sont encore à faire… Comme indiqué précédemment, le développement chez nouveau est balbutiant, du côté de radeonsi la version 1.1 de la norme est exploitable mais le support des images n’y est pas fonctionnel. Par contre le développement de Beignet (Intel) est assez actif, mais a lieu en dehors de Mesa. 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 SoC (System On a Chip) ont la particularité d’avoir un découpage explicite en modules des fonctionnalités fournies ensemble par les GPU de bureau. Là où, grâce à un seul pilote, un GPU de bureau prend en charge la gestion de l’affichage (sortie vidéo), l’accélération 2D/3D et l’accélération de l’encodage et du décodage vidéo, les SoC 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 dans les SoC 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 GPU Adreno des SoCs 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 GPU Adreno ont une base commune avec les GPU Radeon (Qualcomm a racheté la branche GPU mobile d’ATI), le fait que les Radeon aient un pilote open-source 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 GPU 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 Android ?

Etnaviv

Les modules d’accélération 2D/3D vectoriel de Vivante sont pris en charge par le pilote libre etnaviv. Les GPU 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 et rendu public au début de l’année 2013. Il a créé un pilote espace utilisateur open-source par rétro-ingénierie. Ensuite, Christian Gmeiner a pris le relais pour créer un pilote KMS/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 (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. Les précédentes diffusions sur la liste de mails dri-devel du noyau Linux avaient seulement pour but de recueillir des retours des autres développeurs de pilote DRM, mais le 4 décembre une série de patchs 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 à été diffusée le 9 décembre, et le 15 décembre une demande d’intégration a été diffusée sur la mailing list dri-devel pour intégration dans le kernel 4.5.

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 GPU des Raspberry Pi (1 et 2) est le VC4 : Broadcom a embauché Eric Anholt pour travailler sur un pilote opensource (KMS/DRM + Mesa/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’info sur un éventuel pilote open-source pour GPU PowerVR, mais Imagination cherche un programmeur pour travailler sur un pilote Linux (espérons que ce soit un pilote libre)…

Lima & Tamil

Les GPU Mali (venant directement d’ARM) ont pour elles 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 (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.

En mai 2013 j’ai écrit une nouvelle proposition à ARM à propos d’un plan Open source pour Mali (j’en avais fait une première en 2011 quand j’étais chez codethink), j’espérais que leur point de vue en l’absence de proposition entre-deux ferait la différence cette fois.
J’ai reçu un soutien non officiel de personnes chez ARM, mais ils ont juste obtenu le droit de se taire, j’espère qu’ils n’ont pas trop souffert d’avoir essayé de faire changer les choses. La vitesse avec laquelle ma proposition a été rejetée par Jem Davies, et le ton de l’email de réponse, laissait penser que son idée était déjà faite et qu’il n’était toujours pas d’accord avec mes actions.

Sur ce même blog on peut lire que l’écriture de 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 de ARM :

When Codethink ran into a cashflow issue in Oktober 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.

Quand Codethink a eu des problèmes financiers en Octobre 2012, on m’a mis à la porte. Cette décision a aggravé ma déception grandissante sur la façon de traiter Lima et les projets clients sur lesquels j’étais et avec l’hypothèse qu’un développeur qualifié comme moi aurait de la facilité à trouver un autre employeur. Pendant la conversation téléphonique m’annonçant mon licenciement, on m’a dit que ARM avait déjà été informé de mon départ, et 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 SoC, comme par exemple les Allwiner A10, A20, la majorité des Exynos, … Luc Verhaegen, l’auteur des pilotes Lima et Tamil (pour les GPU 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 veulent 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

Lors du FOSDEM, j’ai remarqué un inexcusable manque de conférences, et mes doigts se mirent à nouveau à me démanger. Le travail de consultant a suffisamment boosté mon moral pour me remettre au code et présenter quelques rendus sur le Mali T semblait faisable dans les cinq prochaines semaines. J’ai donné au FOSDEM un scoop sympa, et rempli une des nombreuses lacunes du calendrier. Cette fois je ne voulais pas changer le monde ou me faire mousser, cette fois je voulais me prouver que j’avais appris/grandi depuis Lima, et que je peux encore faire ce genre de choses, avec facilité, tout en prenant du plaisir à le faire 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 SoC de la gamme Tegra semblent avoir leur pilote de moteurs d’affichage upstream nommé tegra, et NVIDIA a travaillé pour utiliser Nouveau pour les Tegra K1 et X1. Ces SoC utilisent des GPU directement dérivés des GPU de bureau (respectivement les architectures Kepler et Maxwell). Pour les SoC plus anciens Tegra 1 à 4, il existe une documentation partielle, un pilote libre (grate) existe.

Allwinner

Le pilote du moteur d’affichage des SoCs Allwinner est développé par un employé de Free Electrons. Par contre, 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 opensource. 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 Khronos Group (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-plateforme, est soutenue par de nombreux acteurs majeurs du marché, et annonce de bien meilleures performances qu’OpenGL (voir la page Wikipedia 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 GDC 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 voir les pilotes Mesa implémenter et annoncer sa prise en charge.

Mesa 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 11.1, comme le code pour le pavage (tesselation) qui est 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 11.2 !

Du côté de chez AMD, les cartes de la génération r600 et 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 de 4.2 le premier ? Intel va-t-il laver l’affront ? La course est serrée !

Par contre nous le savons déjà, les cartes 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 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 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, mais à quoi cela sert-il ? Cela servirait à pouvoir utiliser plusieurs implémentations OpenGL en même temps, par exemple la pile OpenGL Mesa sur un écran et la pile propriétaire nvidia sur un autre. Aaron Plattner de chez Nvidia a publié un premier pilote (beta) 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 on a hâte que libglvnd fasse son petit bout de chemin dans Mesa, 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 de partager en OpenSource 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 software rasterizer est un logiciel de rendu graphique développé pour se satisfaire d’un CPU généraliste. Bien que forcément moins performant qu’un GPU 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 de GPU chez Intel, et que contrairement à ce dernier, OpenSWR se base sur Gallium3D. OpenSWR annonce de bien meilleures performances qu’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.

Catalyst s’est fait complètement humilier ! 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 de Nvidia.

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

Lire les commentaires

(Source: LinuxFr.org : les dépêches)