AccueilđŸ‡«đŸ‡·Chercher

Pile graphique Linux

La pile graphique Linux (Linux graphics stack) dĂ©signe, dans une distribution GNU/Linux, l’ensemble des composants logiciels qui interviennent dans le processus d’affichage.

Historique

  • Pilotes 2D inclus dans X server
    Pilotes 2D inclus dans X server
  • Rendu indirect par-dessus GLX, utilisant Utah GLX
    Rendu indirect par-dessus GLX, utilisant Utah GLX
  • Infrastructure de rendu direct et framebuffer
    Infrastructure de rendu direct et framebuffer
  • Finalement, tous les accĂšs se font Ă  travers le Direct Rendering Manager (gestionnaire de rendu direct).
    Finalement, tous les accĂšs se font Ă  travers le Direct Rendering Manager (gestionnaire de rendu direct).
  • Dans le kernel 3.12, les nƓuds de rendu ont Ă©tĂ© fusionnĂ©s et KMS a Ă©tĂ© Ă©clatĂ©. Wayland implĂ©mente le rendu direct par-dessus EGL.
    Dans le kernel 3.12, les nƓuds de rendu ont Ă©tĂ© fusionnĂ©s et KMS a Ă©tĂ© Ă©clatĂ©. Wayland implĂ©mente le rendu direct par-dessus EGL.


Le serveur X

Traditionnellement, dans les systĂšmes d’exploitation de type Unix, l’affichage graphique est assurĂ© par un serveur X. Le mĂȘme type d’architecture logicielle s’est donc retrouvĂ© dans les systĂšmes GNU/Linux. XFree86 Ă©tait le serveur X libre le plus utilisĂ© par les distributions GNU/Linux. Mais en 2004, en raison d'un problĂšme de licence, un fork est crĂ©Ă©: X.Org. En 2013, ce dernier est le plus rĂ©pandu parmi les distributions GNU/Linux.

Le serveur X Ă©tait un outil trĂšs puissant, mais n’était pas un outil trĂšs performant. DiffĂ©rentes mĂ©thodes ont Ă©tĂ© explorĂ©es pour pallier cette carence :

  • contourner le serveur X lorsqu’il n’était pas utile, pour supprimer un intermĂ©diaire : ainsi, DRI (pour Direct Rendering Interface) permet Ă  Mesa d’interagir avec le matĂ©riel sans passer par le serveur X (Mesa ne peut s’adresser lui‐mĂȘme au matĂ©riel, vivant en espace utilisateur. Voir Ă  ce propos le paragraphe Composition d’un pilote graphique libre sous GNU/Linux ci‐aprĂšs) ;
  • des extensions ont Ă©tĂ© ajoutĂ©es au serveur X : XRender, XRandR, et Composite notamment.

Par ailleurs, un certain nombre de tùches qui étaient gérées par X.Org ont été réaffectées au noyau (evdev, GEM et KMS) ou à des bibliothÚques dédiées (Cairo, pixman, FreeType, Fontconfig, Pango, etc.).

De X.Org Ă  Wayland

Le SystĂšme de fenĂȘtrage repose sur Wayland et utilise EGL, des pilotes supplĂ©mentaires ne sont pas plus nĂ©cessaires.

Avec l’avĂšnement des compositeurs (permettant des effets de transparence, d’ombre portĂ©e, etc.), le fonctionnement de X.Org pour la gestion graphique constitue une Ă©tape supplĂ©mentaire entre l’application et le compositeur ainsi qu’entre le compositeur et le matĂ©riel.

Wayland a Ă©tĂ© proposĂ© pour succĂ©der Ă  X11 : un serveur Wayland joue Ă  la fois le rĂŽle de compositeur (gestionnaire de fenĂȘtres) et de serveur d’affichage. Wayland s’appuie pour cela sur une partie de l’infrastructure existante : pilotes DRI en Mesa 3D, GEM et KMS. Wayland 1.0 est sorti le et poursuit depuis son dĂ©veloppement. GNOME 3.22 devrait pleinement fonctionner avec Wayland et Fedora 25 devrait proposer Wayland par dĂ©faut[1].

En complément, XWayland permet d'avoir un serveur X tournant au-dessus de Wayland afin de pouvoir faire fonctionner les applications initialement conçues pour X.Org et qui n'auront pas été adaptées.

Canonical développe de son cÎté un serveur graphique concurrent pour Ubuntu : Mir.

Composition d’un pilote graphique libre sous GNU/Linux

Pile graphique sur noyau Linux

Sous GNU/Linux, un pilote de carte graphique se décompose en trois parties distinctes :

Le pilote DDX (pour Device Dependent X) est un pilote spĂ©cifique Ă  chaque matĂ©riel (nommĂ© xf86-video-ati pour les cartes AMD, xf86-video-nouveau pour les cartes Nvidia et xf86-video-intel pour les puces graphiques Intel) utilisĂ© par le serveur X pour gĂ©rer la 2D, c’est‐à‐dire essentiellement pour les effets de composition et l’accĂ©lĂ©ration vidĂ©o (via les procĂ©dĂ©s d’accĂ©lĂ©ration 2D du serveur X comme GLAMOR ou EXA – et ses dĂ©rivĂ©s UXA, SNA – ou encore X video extension (en)).

Mesa est l’implĂ©mentation libre d’OpenGL pour GNU/Linux (OpenGL Ă©tant un procĂ©dĂ© d’accĂ©lĂ©ration 3D). PrĂ©cisĂ©ment, Mesa se dĂ©compose en deux parties : la bibliothĂšque Mesa 3D proprement dite, et les pilotes DRI chargĂ©s de traduire les fonctions gĂ©rĂ©es par la bibliothĂšque Mesa 3D en instructions comprĂ©hensibles par la carte graphique. Le rĂ©sultat est envoyĂ© Ă  la carte graphique via DRM (pour Direct Rendering Manager), le pilote du noyau correspondant qui gĂšre seul dorĂ©navant les accĂšs au matĂ©riel (DDX avait Ă©galement accĂšs au matĂ©riel avant que KMS ne permette de transfĂ©rer la gestion des modes d’affichage au noyau ; aujourd’hui DDX passe par DRM pour accĂ©der au noyau). L’accĂ©lĂ©ration 3D requiert donc une prise en charge Ă  la fois par Mesa et le noyau.

Depuis la création de KMS, tout passe donc par DRM :

Avec X.Org :

Application X11
Application OpenGL
Application Framebuffer
Compositeur
X.Org
Pilote 2D
Pilote OpenGL DRI
DRM
Puce graphique

Avec un compositeur Wayland :

Application Wayland
Application OpenGL
Compositeur Wayland
Pilote OpenGL DRI
DRM
Puce graphique

Gallium3D : optimisation de la pile

Gallium3D est prĂ©sentĂ© tout d'abord comme le successeur de Mesa 3D : il consiste Ă  proposer un plus grand niveau d’abstraction du matĂ©riel afin d'unifier l'interface, dans la continuation de la modularisation de X.org, de rĂ©duire et simplifier Ă©galement les tĂąches des dĂ©veloppeurs Ă  l'essentiel et de mieux sĂ©parer les diffĂ©rentes couches.

Implémentation libre d'OpenGL : Mesa 3D ou Gallium3D

Si les pilotes libres pour cartes Nvidia (projet Nouveau) et AMD (projet radeon) se basent dorĂ©navant sur Gallium3D, Intel (qui dĂ©veloppe lui‐mĂȘme les pilotes libres pour ses puces) ne souhaite pas s'engager dans ce changement et continue de proposer des pilotes Mesa classiques dans lesquels il estime avoir beaucoup investi[2].

Implémentation libre d'OpenCL : Gallium3D ou Beignet

En revanche cet argument chronologique ne peut servir dans le cas d'OpenCL dont Intel a décidé de lancer sa propre implémentation libre (sous le nom de Beignet) bien aprÚs la mise en place d'un backend OpenCL pour Gallium3D[3] - [4]. Ce backend pour Gallium3D sera utilisé par les pilotes libres pour cartes NVIDIA (nv50, nvc0
) et AMD (Evergreen, Northern Islands
)[5].

LLVMpipe pour le rendu logiciel accéléré

Le pilote LLVMpipe, basé sur le compilateur JIT LLVM et sur Gallium3D et l'infrastructure DRM/DRI a permis de multiplier la vitesse exécution d'Open GL sans accélération matérielle. Cette implémentation a inspiré l'API Mantle (en) d'ATI qui à a son tour été utilisée pour Vulkan.

Les pilotes graphiques ou vidéo libres par modÚles

Puces graphiques Ă  destination des ordinateurs personnels

Les ordinateurs personnels embarquent généralement une puce graphique émanant d'un des trois concepteurs suivants : AMD, NVIDIA et Intel.

AMD Radeon et FirePro

Radeon et FirePro forment l'offre de cƓurs et cartes graphiques d'AMD.

Pilotes Gallium3D : issus du projet radeon, il existe diffĂ©rents pilotes (R300g, R600g, RadeonSI) correspondant Ă  diffĂ©rentes gĂ©nĂ©rations de puces graphiques AMD. À noter qu'avec RadeonSI, la 2D est dorĂ©navant gĂ©rĂ©e par glamor, un procĂ©dĂ© d’accĂ©lĂ©ration 2D gĂ©nĂ©ral basĂ© sur OpenGL (lire ci-aprĂšs). À noter Ă©galement que, Ă  partir de la famille de puces GCN (Graphics Core Next) de 3e gĂ©nĂ©ration "GCN 1.2" (famille de puces postĂ©rieure Ă  Sea Islands), le pilote Gallium3D RadeonSI est basĂ© sur le pilote noyau commun aux pilotes libre et propriĂ©taire AMDGPU.

NVIDIA GeForce et Quadro

GeForce et Quadro forment l'offre de cartes graphiques de NVIDIA.

Pilotes Gallium3D : issus du projet Nouveau, il existe différents pilotes (nv30, nv50, nvc0
)[6] correspondant à différentes générations de puces graphiques NVIDIA[7].

Intel GMA et HD Graphics

HD Graphics (et prĂ©cĂ©demment GMA) constitue l'offre de cƓurs graphiques d'Intel pour ses propres microprocesseurs.

Pilotes Mesa classique officiels

Ce pilote 3D, développé à l'initiative d'Intel, est le pilote par défaut de la pile graphique de GNU/Linux pour ces puces. Il existe en deux versions [8]:

  • le pilote i915 concerne les puces Intel (Ă  fonctions fixes) de troisiĂšme gĂ©nĂ©ration : 915G[M], 945G[M][E] et PineView ;
  • le pilote i965 concerne les puces Intel (programmables) de quatriĂšme gĂ©nĂ©ration et postĂ©rieures : GMA X3000, X3100, X3500, 4500, X4500, X4500HD, 4500MHD et HD Graphics que l'on trouve dans les processeurs de gĂ©nĂ©ration Ironlake (Clarkdale et Arrandale) et les suivantes (Sandy Bridge, Haswell
).

Attention à ne pas confondre : le pilote 2D, commun à tous les circuits, est communément appelé i915.

Pilotes alternatifs Gallium3D

i915g est un pilote Gallium3D développé indépendamment d'Intel, à l'initiative de VMware, puis de Google, pour les puces de troisiÚme génération[9] - [10].

Cas particulier des GMA 500/600

Pour accompagner ses processeurs Atom, Intel utilise le circuit graphique GMA 500 (nom de code : Poulsbo) ou son successeur : le GMA 600 (Cedarview). Ces circuits n’ont pas Ă©tĂ© entiĂšrement dĂ©veloppĂ©s en interne et sont basĂ©s sur le PowerVR SGX 535 d’Imagination Technologies pour la 3D et le rendu vidĂ©o. Ils nĂ©cessitent donc des pilotes spĂ©cifiques.

Depuis sa version 3.3, le noyau Linux inclut un pilote libre gma500_gfx pour ces puces (apparu pour la premiÚre fois dans la branche -staging de la version 2.6.39 du noyau) ; cependant, celui-ci est limité à l'affichage 2D (pas d'accélération vidéo ni 3D).

Les modĂšles qu’Intel a lancĂ©s Ă  partir de fin 2013 (Valley View et suivants) marquent l’abandon du PowerVR au profit de la solution maison, refermant ainsi cette parenthĂšse[11].

CƓurs graphiques Ă©quipant les systĂšmes sur une puce

Les SoC embarquent gĂ©nĂ©ralement l'un des cƓurs graphiques ci-aprĂšs pour la 3D. Ils sont couplĂ©s Ă  diffĂ©rents autres cƓurs pour l'affichage et la 2D, voire la vidĂ©o, suivant les SoC.

En gĂ©nĂ©ral, les fabricants de SoC proposent un pilote fermĂ© (en espace utilisateur) pour Android pour ces cƓurs graphiques ; ce pilote ne peut ĂȘtre utilisĂ© en l'Ă©tat par une distribution GNU/Linux sauf Ă  utiliser la bibliothĂšque logicielle libre Libhybris conçue initialement pour le projet Mer[12] - [13] - [14].

CƓurs graphiques pour accĂ©lĂ©rer la 3D

Les SoC embarquent gĂ©nĂ©ralement un cƓur graphique Ă©manant d'un des six concepteurs suivants : ARM, Qualcomm, NVIDIA, Vivante, Broadcom, et Imagination Technologies.

ARM Mali

Les cƓurs graphiques Mali sont conçus par ARM.

ARM ne fournit pas de pilote libre. Un pilote libre, qui avait pour plan de supporter Mesa 3D, était jusqu'à début 2013 développé par rétro-ingénierie à l'initiative de Luc Verhaegen alias libv, rejoint par Connor Abbott alias cwabbott : Lima[15]. Le projet semblait bien avancer, le pilote permettant par exemple de faire tourner Quake 3 Arena[16]. Le , Luc a expliqué sur son blogue les déboires que lui avaient causé ce projet, notamment parce qu'il aurait déplu à ARM, et la démotivation qui en découlait et qui le conduisait à mettre le projet de cÎté[17] - [18]. Toutefois un appel à contribution est apparu sur le site du projet le et quelques contributions au code sont apparues sur une branche parallÚle, nommée ng. Le développement est à nouveau trÚs actif depuis 2018. Un autre pilote libre, Panfrost a également été créé permettant de gérer les nouvelles générations de processeurs Mali (Txxx et Gxx). Ces deux pilotes supportent OpenGL (version bureau) contrairement au pilote officiel et sont tous deux intégrés à la partie Gallium3D des pilotes de Mesa[19].

Qualcomm Adreno

Adreno est conçu par Qualcomm dont il équipe les SoC ARM Snapdragon. La technologie employée dérive des puces Radeon d'AMD (dont Adreno est une anagramme).

Qualcomm ne fournit pas de pilote libre mais un pilote 2D/3D libre Gallium3D est activement développé par rétro-ingénierie notamment par Rob Clark sur son temps libre : freedreno[20] - [21].

À noter que, dans la mesure oĂč les modĂšles A3xx et suivants n'ont pas de cƓur 2D, un backend XA pour Gallium3D est utilisĂ© pour gĂ©rer la 2D[22].

Le pilote DRM, nommé msm, prenant en charge KMS et fonctionnant tant avec X.org (via xf86-video-freedreno) qu'avec Wayland/Weston, a intégré la version 3.12 du noyau Linux[23] tandis que freedreno, le pilote Gallium3D, a intégré la version 9.2 de Mesa[24]. Il s'agit donc du premier pilote libre 2D/3D disponible pour un SoC ARM. Ce pilote permet aux puces a3xx et a4xx de prendre en charge OpenGL ES 3.0 (depuis Mesa 3D 11.0) et OpenGL 3.1 (depuis Mesa 3D 11.1)[25] - [26].

Depuis , Qualcomm aide au développement de ce pilote libre communautaire, en fournissant patches et documentation[27] - [28].

NVIDIA GeForce ULP

Le GeForce ULP (pour Ultra Low Power) est conçu par NVIDIA dont il équipe les SoC ARM Tegra.

Avec l'aide de NVIDIA, un pilote libre 2D pour Tegra 2/3 a Ă©tĂ© introduit dans la version 3.8 du noyau Linux[29] et complĂ©tĂ© dans la version 3.10 du noyau Linux[30]. À compter de la version 3.13 du noyau Linux, le pilote DRM est composĂ© de deux parties : host1x et tegra[31] et la prise en charge de Tegra 4 est ajoutĂ©e.

Un pilote libre 3D est en cours de développement par rétro-ingénierie à l'initiative de Erik Faye-Lund alias kusma (et précédemment de Thierry Reding) : grate.

Vivante Corporation Vivante

Le cƓur graphique Vivante est conçu par Vivante Corporation et Ă©quipe divers SoC (sĂ©rie i.MX6 de Freescale, gamme Armada de Marvell, RK2918 de Rockchip).

En 2015/2016, un pilote libre 2D/3D etnaviv est activement développé par Lucas Stach pour le compte de la société allemande Pengutronix, Christian Gmeiner et Russell King. Comme résultat de ce travail, le pilote DRM, basé sur le code de freedreno (le pilote libre pour les processeurs graphiques Qualcomm Adreno inclus dans les SoC Snapdragon), a intégré la version 4.5 du noyau Linux. ParallÚlement, le développement du pilote Gallium3D, qui a été commencé par rétro-ingénierie par Wladimir J. van der Laan alias wumpus, se poursuit.

Broadcom VideoCore

Le VideoCore est conçu par Broadcom.

Malgré l'architecture alambiquée de la puce, une initiative indépendante de pilote libre avait été commencée par Herman H Hermitage : videocoreiv.

AprÚs le faux-départ de fin 2012[32] - [33] - [34] - [35], Broadcom a finalement levé le secret sur certaines parties de ses puces début 2014[36] - [37] - [38].

Finalement, en , Broadcom a recrutĂ© Eric Anholt, ancien principal dĂ©veloppeur des pilotes libres Mesa pour les processeurs graphiques d'Intel, pour crĂ©er un pilote 3D libre Ă  destination du VideoCore 4 (qui Ă©quipe notamment les Raspberry Pi et Pi 2) : vc4. Une Ă©bauche est entrĂ©e dans Mesa 3D le , utilisant l'architecture Gallium3D[39], qui reste Ă  complĂ©ter Ă  la date du .

ParallÚlement, une mouture préliminaire du pilote noyau a été intégrée dans la version 4.4 de Linux, qui a été complétée dans la version 4.5 afin de pouvoir prendre en charge la 3D en conjonction avec le pilote Gallium3D[40].

Le pilote 2D/3D peut ĂȘtre testĂ© Ă  partir de l'image Raspbian publiĂ©e le [41].

Imagination Technologies PowerVR

Les PowerVR (modÚles Series 5 et postérieurs) sont conçus par Imagination Technologies.

Imagination Technologies ne fournit pas de pilote libre. Compte tenu de l'architecture alambiquée de la puce, il est peu probable qu'un pilote libre voie le jour et ce, malgré le souhait de la Free Software Foundation[42].

Intel HD Graphics

Intel a lancĂ© fin 2013 Valley View, un premier SoC regroupant un processeur Atom (architecture x86) et un cƓur HD Graphics (de septiĂšme gĂ©nĂ©ration) pour lequel le fondeur fournit directement un pilote libre.

Intel a annoncé mi- qu'il se retirait du segment des smartphones et tablettes[43].

Allwinner CedarX

Allwinner ne fournissait pas de pilote libre pour le CedarX et un pilote libre a commencĂ© Ă  ĂȘtre dĂ©veloppĂ© par rĂ©tro-ingĂ©nierie (projet Cedrus) ; AllWinner a ensuite rĂ©alisĂ© un pilote libre mais incomplet[44] - [45].

Rockchip

Les processeurs de décodage vidéo de Rockchip ont des pilotes libres présent dans la pile vidéo standard Linux. Rockchip fourni sous licence libre les bibliothÚques depuis 2016[46].

Prochaine étape : accélération 2D via les fonctions 3D de la puce graphique

Les procĂ©dĂ©s d’accĂ©lĂ©ration 2D actuels (EXA/XAA/UXA) ayant montrĂ© leurs limites, c'est pourquoi les dĂ©veloppeurs sont Ă  pied d’Ɠuvre pour en dĂ©velopper de nouveaux. Plusieurs initiatives parallĂšles sont en cours[47] - [48] - [49].

Rendu 2D via OpenGL

Cairo-gl est un backend OpenGL pour Cairo.

glamor est un procĂ©dĂ© d’accĂ©lĂ©ration 2D gĂ©nĂ©ral basĂ© sur OpenGL. Il se compose d’une bibliothĂšque gĂ©nĂ©rique pouvant s’interfacer avec le pilote DDX, et qui vise Ă  convertir les opĂ©rations du serveur X en instructions OpenGL qui seront traitĂ©es par Mesa. Un pilote DDX modifiĂ© pour tirer parti de glamor, EGL et KMS rend possible le dĂ©marrage d’un serveur X via Mesa/EGL sans systĂšme de fenĂȘtrage natif[50]. Eric Anholt et Zhigang Gong, tous deux dĂ©veloppeurs pour Intel, en sont les principaux dĂ©veloppeurs initiaux. glamor est utilisĂ© par le pilote RadeonSI pour les cartes AMD Radeon les plus rĂ©centes (lire ci-avant) ainsi que pour XWayland.

Ces deux projets ont pour avantage une simplification à terme de la pile graphique (un seul pilote restant à maintenir : le pilote 3D) mais pour inconvénient de vouloir faire rentrer un pied dans une chaussure à coup de marteau : OpenGL n'est pas conçu pour accélérer les fonctions 2D, et ré-exprimer les primitives 2D en commandes 3D au niveau de l'API 3D n'est pas optimal.

Rendu 2D direct

Il s'agit de permettre à une application 2D d'adresser directement le matériel comme peut le faire une application 3D. Mais au lieu de prendre un biais en passant par OpenGL, on essaye d'exposer directement les primitives adaptées à l'accélération 2D.

Des projets comme cairo-drm ou pixman-drm ont cet objectif.

Également, Gallium3D dispose de backends permettant d’accĂ©lĂ©rer EXA via les fonctions 3D de la puce graphique : st/xorg, st/xa. Mais aucun des deux n'est activement maintenu.

Cette approche aboutit cependant Ă  une complexification des pilotes.

Notes et références

  1. (en) Why Wayland anyway ? par Matthias Clasen, Goings on, le
  2. (en) Intel & The Shortcomings Of Gallium3D par Michael Larabel, phoronix, le
  3. (en) Intel Makes First Release Of Linux OpenCL Project par Michael Larabel, phoronix, le
  4. (en) More Criticism Comes Towards Intel's Beignet OpenCL par Michael Larabel, phoronix, le
  5. (en) GalliumCompute, sur le wiki de dri.freedesktop.org
  6. (en) nouveau: MesaDrivers, sur le wiki de nouveau.freedesktop.org
  7. (en) nouveau: CodeNames, sur le wiki de nouveau.freedesktop.org
  8. (en) IntelGraphicsDriver, sur le wiki de la X.org Foundation
  9. (en) Google's Into Intel Gallium3D For Chromium OS? par Michael Larabel, phoronix, le
  10. (en) Intel i915 Gallium3D Driver Might Become The Default par Michael Larabel, phoronix, le
  11. (en) Intel Is Planning To Drop PowerVR Graphics par Michael Larabel, phoronix, le
  12. (en) Libhybris Let You Use Android Drivers & HW Libraries in Linux, CNXSoft, le
  13. (en) Wayland utilizing Android GPU drivers on glibc based systems, Part 1 par Carsten Munk, le
  14. (en) Wayland utilizing Android GPU drivers on glibc based systems, Part 2 par Carsten Munk, le
  15. (en) « Site officiel »(Archive.org ‱ Wikiwix ‱ Archive.is ‱ Google ‱ Que faire ?)
  16. (en) Q3A with open source generated shaders! par Luc Verhaegen, le
  17. (en) The value of writing code and instigating change par Luc Verhaegen, le
  18. (en) Has The Sky Fallen? Qualcomm Contributes To Freedreno's DRM/KMS Driver, commentaire de Luc Verhaegen sur le forum de phoronix, le
  19. Voir les articles mentionnés pour les références
  20. (en) Code et wiki sur GitHub
  21. (en) Liste de discussion
  22. (en) Freedreno Gallium3D Gets XA Acceleration Support par Michael Larabel, phoronix, le
  23. (en) PATCHv4 0/5 drm/msm: A DRM/KMS driver for snapdragon SoCs sur la liste de diffusion dri-devel, le
  24. (en) Mesa 9.2 Release Notes / (August 27, 2013)
  25. (en) « Mesa 11.0.0 Release Notes / September 12, 2015 »,
  26. (en) « Mesa 11.1.0 Release Notes / 15 December 2015 »,
  27. (en) « freedreno a4xx »,
  28. (en) « freedreno - mesa 11.0 progress update, OpenGLES3 and more »,
  29. (en) The Back Story On The Open NVIDIA Tegra Driver par Michael Larabel, phoronix, le
  30. (en) NVIDIA Tegra DRM Prepares For Linux 3.10 Kernel par Michael Larabel, phoronix, le
  31. (en) PATCHv7 00/10 Support for Tegra 2D hardware
  32. (en) Open Source ARM userland par Alex Bradbury, le
  33. (en) Commentaire de Luc Verhaegen sous le billet d'annonce par Alex Bradbury, en date du
  34. (en) raspberry pi drivers are NOT useful par Dave Airlie, le
  35. (en) L'avis de Theo de Raadt donné sur la liste de diffusion OpenBSD, le
  36. (en) Android for All: Broadcom Gives Developers Keys to the VideoCoreÂź Kingdom par Eben Upton sur blog.broadcom.com, le
  37. (en) L'avis de Rob Clark donné sur le forum de Phoronix, le
  38. (en) The Raspberry Pi, en route to becoming a proper open platform par Luc Verhaegen, le
  39. (en) Eric Anholt, « vc4: Initial skeleton driver import. », sur dépÎt git de Mesa3d sur freedesktop.org, (consulté le )
  40. (en) Eric Anholt, « vc4 status update 2015-12-14 », (consulté le )
  41. (en) Raspbian Now Ships With Experimental Support For The New VC4 OpenGL Driver
  42. (en) page wiki correspondante sur gnu.org
  43. (en) Intel's Changing Future: Smartphone SoCs Broxton & SoFIA Officially Cancelled par Ian Cutress et Ryan Smith, Anandtech, le
  44. (en) CedarX sur le wiki sunxi
  45. (en) Allwinner Publishes New CedarX Open-Source Code par Michael Larabel, phoronix, le
  46. « Rockchip-Linux », sur Github
  47. (en) The Battle for 2D Acceleration par Chris Wilson, le
  48. (en) From Click to Pixel: A Tour of the Linux Graphics Stack par Carl Worth, le
  49. (en) Making the GPU do its job par Carl Worth, le
  50. (en) Pull Request - Glamor: A 2D rendering acceleration implementation based on OpenGL, par zhigang gong, sur la liste de diffusion X.org, le

Annexes

Articles connexes

Base de données

Articles

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.