URL: https://linuxfr.org/news/les-pilotes-graphiques-libres-retrospective-et-vue-sur-l-avenir Title: Les pilotes graphiques libres : rétrospective et vue sur l’avenir Authors: Thomas Debesse Davy Defaud, BAud, xoddark, reynum, ZeroHeure, palm123, antistress, bubar🦥, Yves Bourguignon, babytux, EdB, esdeem, Lucas, Mohamed MEDIOUNI, Spyhawk, Le Gab, Benoît Sibaud, jcr83, Nÿco, ptitjano, Christophe "CHiPs" PETIT, come, ʭ ☯ , Anonyme, err404, PolePosition, Frédéric Massot, M5oul, ariasuni et Narann Date: 2015年08月26日T03:26:30+02:00 License: CC By-SA Tags: arm, graphique, opengl, opengles, gpu, opencl et mesa Score: 110 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](http://mesa3d.org/relnotes/11.0.0.html), 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 ! ---- [The OpenGL vs Mesa matrix](http://mesamatrix.net/) [Radeonsi with si scheduler humiliates Catalyst in all tests](http://www.linuxsystems.it/2015/08/radeonsi-with-si-scheduler-humiliates-catalyst-in-all-tests/) [Intel Enables ASTC Texture Compression In Mesa For Skylake](http://www.phoronix.com/scan.php?page=news_item&px=Intel-ASTC-Mesa-Skylake) [[Mesa-dev] Mesa 11.0.0](http://lists.freedesktop.org/archives/mesa-dev/2015-September/094286.html) [[Mesa-dev] Mesa 11.1.0](http://lists.freedesktop.org/archives/mesa-dev/2015-December/103231.html) [Pilote libre Tegra 1 à 4](https://github.com/grate-driver/grate) ---- 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](http://nouveau.freedesktop.org/wiki/CodeNames/#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](http://dl.illwieckz.net/b/mesa/20160127.mesa-11.2-opengl-4.1-ubuntu-padoka.png) _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](https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa) _et_ [oibaf](https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) _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_](http://mesamatrix.net) ([merci _Creak<_](https://linuxfr.org/news/mesamatrix-pour-suivre-les-progres-de-mesa)), 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](https://fr.wikipedia.org/wiki/OpenGL_ES "Open Graphics Library for Embedded System — OpenGL pour systèmes embarqués") 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](https://fr.wikipedia.org/wiki/LLVM "Low Level Virtual Machine — machine virtuelle de bas niveau") (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é](http://cgit.freedesktop.org/mesa/mesa/commit/?id=c3fad009c54fb526d236fd10f4377ce7fbb54459) à 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](http://cgit.freedesktop.org/mesa/mesa/commit/?id=bac12c8948681a23fd1a8f8a6bbb5523ccfe0939) 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](http://lists.freedesktop.org/archives/mesa-dev/2015-July/090032.html) 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](http://cgit.freedesktop.org/mesa/mesa/commit/?id=d03c65793a5ee31f1138cbd0fba6fac6cd942428). Ainsi, [la liste des extensions nécessaires fut enfin complète](http://cgit.freedesktop.org/mesa/mesa/commit/?id=3c04a90e91a64a4a09d77c76c6ddcaca949e9b0e) 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](http://cgit.freedesktop.org/mesa/mesa/commit/?id=6f2d88927a77f902157704d16b70b1265e0ca357) cette numérotation le premier août et [publia](http://lists.freedesktop.org/archives/mesa-dev/2015-September/094286.html) 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_](https://en.wikipedia.org/wiki/Graphics_Core_Next), ou GCN) utilise un compilateur de [_shader_](https://fr.wikipedia.org/wiki/Shader "nuanceur") 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](http://lists.llvm.org/pipermail/llvm-announce/2015-September/000065.html), 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](https://fr.wikipedia.org/wiki/OpenCL "Open Computing Language"), le travail a commencé pour les cartes NVIDIA des générations _Tesla_ [NV50](http://nouveau.freedesktop.org/wiki/CodeNames/#NV50) et _Fermi_ [NVC0](http://nouveau.freedesktop.org/wiki/CodeNames/#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]] _×ばつ [MSAA](https://en.wikipedia.org/wiki/Multisample_anti-aliasing)_ (à partir des processeurs _[[Skylake]]_). AMD a contribué à la gestion du décodage [H.265/HEVC](https://fr.wikipedia.org/wiki/H.265/HEVC) pour Gallium3D, accessible via l’interface [VA-API](https://fr.wikipedia.org/wiki/Video_Acceleration_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](https://en.wikipedia.org/wiki/Adaptive_Scalable_Texture_Compression)_ est un format de compression de texture exempt de brevets destiné à remplacer _[S3TC](https://en.wikipedia.org/wiki/S3_Texture_Compression)_ (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](http://www.phoronix.com/scan.php?page=news_item&px=MTE1NDk) 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_](http://www.x.org/wiki/Events/XDC2014/) (_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_](http://lists.freedesktop.org/archives/dri-devel/2015-April/081501.html). 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](http://lists.freedesktop.org/archives/dri-devel/2015-June/084083.html) et reçoit depuis des améliorations à chaque nouvelle version du noyau. Par exemple, une nouvelle gestion de l’alimentation appelée [_powerplay_](http://lists.freedesktop.org/archives/dri-devel/2015-November/094230.html), 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_](http://www.x.org/wiki/Events/XDC2014/ "X.Org Developer’s Conference") à Bordeaux, il a été [intégré dans Mesa 3D](https://www.phoronix.com/scan.php?page=news_item&px=Mesa-NIR-Lands) 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](http://lists.freedesktop.org/archives/mesa-dev/2014-December/072761.html)). NIR a [continué de mûrir](http://cgit.freedesktop.org/mesa/mesa/log/?id=d3636da9026dd10493fb57b0d6803e33166abd1b&qt=grep&q=nir) 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](https://www.indiegogo.com/projects/improve-opengl-support-for-the-linux-graphics-drivers-mesa#/) visant à salarier Timothy Arceri (il n’en est pas à [son coup d’essai](http://linuxfr.org/users/florentin_raud/journaux/succes-de-l-extension-de-mesa-en-financement-participatif)) 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](http://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=AoA) 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](http://www.itsqueeze.com/2015/09/arrays-of-arrays-update-and-where-to-from-here/) qu’à partir de novembre, il serait embauché par Collabora pour travailler à temps plein sur Mesa 3D. [Sa priorité désormais](http://cgit.freedesktop.org/mesa/mesa/commit/?id=64831832791139328a67b80387f062d39e304d24) 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_](http://www.freedesktop.org/wiki/Software/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](http://www.darktable.org/)_), 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](http://www.phoronix.com/scan.php?page=news_item&px=Clover-CL1.2-Create-Image)_. 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_](https://fr.wikipedia.org/wiki/Syst%C3%A8me_sur_une_puce)) 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](https://fr.wikipedia.org/wiki/Adreno)_ des systèmes monopuces _[Snapdragon](https://fr.wikipedia.org/wiki/Snapdragon)_ de [Qualcomm](https://fr.wikipedia.org/wiki/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](https://fr.wikipedia.org/wiki/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](https://fr.wikipedia.org/wiki/Interface_de_programmation "Application Programming Interface — interface de programmation") _[fbdev](https://fr.wikipedia.org/wiki/Framebuffer_Linux "Framebuffer Linux")_ (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](https://blog.visucore.com) 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](https://fr.wikipedia.org/wiki/Kernel-based_mode-setting "Kernel‐based mode‐setting") et [DRM](https://fr.wikipedia.org/wiki/Direct_rendering_infrastructure "Direct rendering infrastructure"), 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](https://fr.wikipedia.org/wiki/Kernel-based_mode-setting "Kernel‐based mode‐setting"). 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](https://github.com/austriancoder/libdrm)_ et un dépôt [Mesa 3D](https://github.com/austriancoder/mesa-1). 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](http://lists.freedesktop.org/archives/dri-devel/2015-December/097164.html) 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_](https://en.wikipedia.org/wiki/Mali_%28GPU%29) (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](http://limadriver.org/ "limadriver.org") é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](http://libv.livejournal.com/27461.html) 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](http://www.linaro.org/), 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](http://www.phoronix.com/scan.php?page=news_item&px=Allwinner-A10-DRM-Display) dans la prise en charge des _Mali_ sur Linux. Phoronix avait publié un [petit état des lieux en avril](https://www.phoronix.com/scan.php?page=news_item&px=Liba-Tamil-Lost-Traction), à 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](https://en.wikipedia.org/wiki/Tegra). 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](http://free-electrons.com). 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](https://www.khronos.org/vulkan) est une [API](https://fr.wikipedia.org/wiki/Interface_de_programmation "Application Programming Interface — interface de programmation") poussée par le groupe [Khronos](https://fr.wikipedia.org/wiki/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‐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_](https://fr.wikipedia.org/wiki/Vulkan_%28API%29) 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](https://fr.wikipedia.org/wiki/Game_Developers_Conference "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](http://lists.freedesktop.org/archives/mesa-dev/2015-December/102235.html) chez Intel. Du côté des radeon R600, le [code pour le pavage est là aussi](http://cgit.freedesktop.org/mesa/mesa/commit/?id=33404f141551d0ace00101e78f9b2d93cad135f1). 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](https://github.com/NVIDIA/libglvnd)_ (_OpenGL Vendor Neutral Dispatch Library_) sur la liste de diffusion _[mesa-dev](https://www.mail-archive.com/mesa-dev%40lists.freedesktop.org/msg94800.html)_ 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](https://devtalk.nvidia.com/default/topic/908423) (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](http://www.phoronix.com/scan.php?page=news_item&px=AMD-Looking-At-GLVND) 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](http://www.phoronix.com/scan.php?page=news_item&px=Mesa-Will-Do-GLVND). ## GPUOpen AMD a annoncé en décembre 2015 [l’initiative _GPUOpen_](http://www.hardware.fr/news/14446/gpuopen-reponse-amd-gameworks.html) 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](http://gpuopen.com/welcometogpuopen/), du code a [commencé à être publié sur GitHub](https://github.com/GPUOpen-Tools). Plus de détails peuvent être trouvés dans le [journal de _freejeff_](http://linuxfr.org/users/freejeff/journaux/gpuopen) et ses commentaires. ## OpenSWR Intel travaille sur un nouveau _[rasterizer](https://fr.wikipedia.org/wiki/Rast%C3%A9risation)_ logiciel nommé [_OpenSWR_](http://openswr.org/) et concurrençant [_LLVMPipe_](http://www.mesa3d.org/llvmpipe.html). 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](http://lists.freedesktop.org/archives/mesa-dev/2015-October/097816.html) (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](http://openswr.org/slides/SWR_Sept15.pdf) (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_](http://sdvis.org/) et le [code est libre](https://github.com/OpenSWR/openswr-mesa), 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](https://github.com/axeldavy/llvm/commit/5005a869e01debaf3f78df804ab4fe67325ad88a)_, 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](http://www.linuxsystems.it/2015/08/radeonsi-with-si-scheduler-humiliates-catalyst-in-all-tests/) 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 !

AltStyle によって変換されたページ (->オリジナル) /