Infrastructure de rendu direct - Direct Rendering Infrastructure

Il existe deux pilotes matériels graphiques : l'un réside à l'intérieur du serveur d'affichage X . Il y a eu plusieurs conceptions de ce pilote. L'actuel le divise en deux parties : DIX (Device-Independent X) et DDX (Device-Dependent X)

Glamour simplifiera le serveur X , et libGL-fglrx-glx pourrait utiliser la libDRM du pilote open-source radeon au lieu du blob binaire propriétaire .

Les calculs de rendu sont sous-traités via OpenGL au GPU pour être effectués en temps réel. La DRI réglemente l'accès et la comptabilité.

L' infrastructure de rendu direct ( DRI ) est un cadre permettant un accès direct au matériel graphique sous le système X Window d'une manière sûre et efficace. L'utilisation principale de DRI est de fournir une accélération matérielle pour l' implémentation Mesa d' OpenGL . DRI a également été adapté pour fournir une accélération OpenGL sur une console framebuffer sans qu'un serveur d'affichage ne soit en cours d'exécution.

L'implémentation DRI est dispersée à travers le serveur X et ses bibliothèques clientes associées, Mesa 3D et le sous-système du noyau Direct Rendering Manager . Tout son code source est un logiciel libre .

Aperçu

Dans l' architecture classique du système X Window , le serveur X est le seul processus avec un accès exclusif au matériel graphique , et donc celui qui fait le rendu réel sur le framebuffer . Tout ce que font les clients X, c'est de communiquer avec le serveur X pour envoyer des commandes de rendu. Ces commandes sont indépendantes du matériel, ce qui signifie que le protocole X11 fournit une API qui fait abstraction du périphérique graphique afin que les clients X n'aient pas besoin de connaître ou de s'inquiéter des spécificités du matériel sous-jacent. Tout code spécifique au matériel réside à l'intérieur du Device Dependent X , la partie du serveur X qui gère chaque type de carte vidéo ou d'adaptateur graphique et qui est aussi souvent appelée pilote vidéo ou graphique .

L'essor du rendu 3D a montré les limites de cette architecture. Les applications graphiques 3D ont tendance à produire de grandes quantités de commandes et de données, qui doivent toutes être envoyées au serveur X pour le rendu. Au fur et à mesure que la quantité de communication inter-processus (IPC) entre le client X et le serveur X augmentait, les performances de rendu 3D ont souffert au point que les développeurs de pilotes X ont conclu que pour tirer parti des capacités matérielles 3D des dernières cartes graphiques, un nouveau Une architecture sans IPC était requise. Les clients X doivent avoir un accès direct au matériel graphique plutôt que de dépendre d'un processus tiers pour le faire, économisant ainsi toute la surcharge IPC. Cette approche est appelée « rendu direct » par opposition au « rendu indirect » fourni par l'architecture X classique. L' infrastructure de rendu direct a été initialement développée pour permettre à n'importe quel client X d'effectuer un rendu 3D en utilisant cette approche de « rendu direct ».

Rien n'empêche d'utiliser DRI pour implémenter un rendu direct 2D accéléré au sein d'un client X. Tout simplement personne n'a eu besoin de le faire parce que les performances de rendu indirect 2D étaient assez bonnes.

Architecture logicielle

L'architecture de base de l'infrastructure de rendu direct comprend trois composants principaux :

• le client DRI —un client X effectuant un "rendu direct"— a besoin d'un "pilote" spécifique au matériel, capable de gérer la carte vidéo ou l'adaptateur graphique actuel afin d'effectuer le rendu dessus. Ces pilotes DRI sont généralement fournis sous forme de bibliothèques partagées auxquelles le client est lié dynamiquement . Étant donné que DRI a été conçu pour tirer parti du matériel graphique 3D, les bibliothèques sont normalement présentées aux clients comme des implémentations matérielles accélérées d'une API 3D telle qu'OpenGL , fournies soit par le fournisseur de matériel 3D lui-même, soit par un tiers tel que le logiciel gratuit Mesa 3D. projet.
• le serveur X fournit une extension de protocole X11 —l'extension DRI— que les clients DRI utilisent pour se coordonner à la fois avec le système de fenêtrage et le pilote DDX. Dans le cadre du pilote DDX, il est assez courant que le processus X Server soit également lié de manière dynamique au même pilote DRI que les clients DRI, mais pour fournir un rendu 3D accéléré matériellement aux clients X en utilisant l' extension GLX pour le rendu indirect (par exemple à distance clients X qui ne peuvent pas utiliser le rendu direct). Pour le rendu 2D, le pilote DDX doit également prendre en compte les clients DRI utilisant le même périphérique graphique.
• l'accès à la carte vidéo ou à l'adaptateur graphique est régulé par un composant du noyau appelé Direct Rendering Manager (DRM). Le pilote DDX du serveur X et le pilote DRI de chaque client X doivent utiliser DRM pour accéder au matériel graphique. DRM assure la synchronisation avec les ressources partagées du matériel graphique - des ressources telles que la file d'attente de commandes, les registres de carte, la mémoire vidéo, les moteurs DMA, ... - garantissant que l'accès simultané de tous ces multiples processus d'espace utilisateur concurrents ne t interférer les uns avec les autres. DRM sert également d'agent de sécurité de base qui ne permet à aucun client X d'accéder au matériel au-delà de ce dont il a besoin pour effectuer le rendu 3D.

DRI1

Dans l'architecture DRI d'origine, en raison de la taille de la mémoire des cartes vidéo à cette époque, il n'y avait qu'une seule instance du tampon avant et arrière de l'écran (également du tampon de profondeur auxiliaire et du tampon stencil ), partagée par tous les clients DRI et le serveur X. Tous sont rendus directement sur le tampon arrière, qui a été échangé avec le tampon avant à un intervalle de suppression vertical . Afin d'effectuer le rendu dans le tampon arrière, un processus DRI doit s'assurer que le rendu a été découpé dans la zone réservée à sa fenêtre .

La synchronisation avec le serveur X s'est faite via des signaux et une mémoire tampon partagée appelée SAREA. L'accès au périphérique DRM était exclusif, donc tout client DRI devait le verrouiller au début d'une opération de rendu . Entre-temps, d'autres utilisateurs de l'appareil, y compris le serveur X, ont été bloqués et ont dû attendre que le verrou soit libéré à la fin de l'opération de rendu en cours, même s'il n'y aurait pas de conflit entre les deux opérations. Un autre inconvénient était que les opérations ne conservaient pas les allocations de mémoire après que le processus DRI actuel ait libéré son verrou sur l'appareil, de sorte que toutes les données téléchargées dans la mémoire graphique, telles que les textures, étaient perdues pour les opérations à venir, ce qui avait un impact significatif sur les performances graphiques.

De nos jours, DRI1 est considéré comme complètement obsolète et ne doit pas être utilisé.

DRI2

En raison de la popularité croissante des gestionnaires de fenêtres de composition comme Compiz , l'infrastructure de rendu direct a dû être repensée afin que les clients X puissent également prendre en charge la redirection vers des "pixmaps hors écran" tout en effectuant un rendu direct. Les clients X réguliers respectaient déjà la redirection vers une pixmap séparée fournie par le serveur X en tant que cible de rendu — la soi-disant pixmap hors écran —, mais les clients DRI ont continué à faire le rendu directement dans le backbuffer partagé, contournant efficacement le gestionnaire de fenêtres de composition. La solution ultime consistait à changer la façon dont DRI gérait les tampons de rendu, ce qui a conduit à une extension DRI complètement différente avec un nouvel ensemble d'opérations, ainsi qu'à des changements majeurs dans le gestionnaire de rendu direct . La nouvelle extension a été nommée "DRI2", bien qu'il ne s'agisse pas d'une version ultérieure mais d'une extension différente même pas compatible avec le DRI d'origine - en fait, les deux coexistent au sein du serveur X depuis longtemps.

Dans DRI2, au lieu d'un seul tampon (arrière) partagé, chaque client DRI obtient son propre tampon arrière privé, ainsi que les tampons de profondeur et de gabarit associés, pour restituer le contenu de sa fenêtre à l'aide de l' accélération matérielle . Le client DRI l' échange ensuite avec un faux " tampon avant ", qui est utilisé par le gestionnaire de fenêtres de composition comme l'une des sources pour composer (construire) le tampon arrière d'écran final à échanger à l' intervalle VBLANK avec le vrai tampon avant.

Pour gérer tous ces nouveaux buffers, le Direct Rendering Manager devait intégrer de nouvelles fonctionnalités, notamment un gestionnaire de mémoire graphique . DRI2 a été initialement développé à l'aide du gestionnaire de mémoire expérimental TTM , mais il a ensuite été réécrit pour utiliser GEM après avoir été choisi comme gestionnaire de mémoire DRM définitif. Le nouveau modèle de gestion de tampon interne DRI2 a également résolu deux goulots d'étranglement de performances majeurs présents dans l'implémentation DRI d'origine :

• Les clients DRI2 ne verrouillent plus l'intégralité du périphérique DRM lorsqu'ils l'utilisent pour le rendu, car chaque client dispose désormais d'un tampon de rendu distinct, indépendant des autres processus.
• Les clients DRI2 peuvent allouer leurs propres buffers (avec textures, listes de vertex, ...) dans la mémoire vidéo et les conserver aussi longtemps qu'ils le souhaitent, ce qui réduit considérablement la consommation de bande passante de la mémoire vidéo .

Dans DRI2, l'allocation des buffers privés hors écran (back buffer, fake front buffer, depth buffer, stencil buffer, ...) pour une fenêtre est effectuée par le serveur X lui-même. Les clients DRI récupèrent ces tampons pour effectuer le rendu dans la fenêtre en appelant des opérations telles que DRI2GetBuffers et DRI2GetBuffersWithFormat disponibles dans l'extension DRI2. En interne, DRI2 utilise des noms GEM — un type de descripteur global fourni par l' API GEM qui permet à deux processus accédant à un périphérique DRM de faire référence au même tampon — pour transmettre des « références » à ces tampons via le protocole X11 . La raison pour laquelle le serveur X est en charge de l'allocation de tampon des tampons de rendu d'une fenêtre est que l' extension GLX permet à plusieurs clients X de faire du rendu OpenGL en coopération dans la même fenêtre. De cette façon, le serveur X gère l'ensemble du cycle de vie des tampons de rendu tout au long du processus de rendu et sait quand il peut les recycler ou les supprimer en toute sécurité. Lorsqu'un redimensionnement de fenêtre est effectué, le serveur X est également chargé d'allouer de nouveaux tampons de rendu correspondant à la nouvelle taille de fenêtre et de notifier la modification du ou des clients DRI rendus dans la fenêtre à l'aide d'un événement InvalidateBuffers, afin qu'ils récupèrent le GEM noms des nouveaux tampons.

L'extension DRI2 fournit d'autres opérations de base pour les clients DRI, telles que la recherche du périphérique et du pilote DRM qu'ils doivent utiliser ( DRI2Connect ) ou l'authentification par le serveur X afin de pouvoir utiliser les fonctionnalités de rendu et de mémoire tampon du périphérique DRM. ( Authentification DRI2 ). La présentation des tampons rendus à l'écran est effectuée à l'aide des requêtes DRI2CopyRegion et DRI2SwapBuffers . DRI2CopyRegion peut être utilisé pour effectuer une copie entre le faux tampon avant et le vrai tampon avant, mais il ne fournit aucune synchronisation avec l'intervalle de suppression vertical, ce qui peut provoquer un déchirement . DRI2SwapBuffers , d'autre part, effectue un échange synchronisé VBLANK entre les tampons arrière et avant, s'il est pris en charge et que les deux tampons ont la même taille, ou une copie ( blit ) sinon.

DRI3

Bien que DRI2 ait été une amélioration significative par rapport au DRI d'origine, la nouvelle extension a également introduit de nouveaux problèmes. En 2013, une troisième itération de l'infrastructure de rendu direct connue sous le nom de DRI3 a été développée afin de résoudre ces problèmes.

Les principales différences de DRI3 par rapport à DRI2 sont :

• Les clients DRI3 allouent eux-mêmes leurs tampons de rendu au lieu de s'appuyer sur le serveur X pour effectuer l'allocation — c'était la méthode prise en charge par DRI2.
• DRI3 se débarrasse de l'ancien mécanisme de partage de tampon GEM non sécurisé basé sur les noms GEM (descripteurs GEM globaux) pour transmettre des objets tampon entre un client DRI et le serveur X en faveur d'un plus sécurisé et polyvalent basé sur PRIME DMA-BUFs , qui utilise descripteurs de fichiers à la place.

L'allocation de tampon côté client rompt les hypothèses de GLX dans le sens où il n'est plus possible pour plusieurs applications GLX de s'afficher de manière coopérative dans la même fenêtre. Du côté positif, le fait que le client DRI soit en charge de ses propres tampons tout au long de leur durée de vie apporte de nombreux avantages. Par exemple, il est facile pour le client DRI3 de s'assurer que la taille des tampons de rendu correspond toujours à la taille actuelle de la fenêtre, et élimine ainsi les artefacts dus au manque de synchronisation des tailles de tampon entre le client et le serveur qui a entravé le redimensionnement de la fenêtre dans DRI2. Une meilleure performance est également obtenue car maintenant les clients DRI3 économisent l'aller-retour supplémentaire en attendant que le serveur X envoie les tampons de rendu. Les clients DRI3, et en particulier les gestionnaires de fenêtres de compositeur, peuvent tirer parti de la conservation des anciens tampons des images précédentes et de les réutiliser comme base sur laquelle ne restituer que les parties endommagées d'une fenêtre en tant qu'autre optimisation des performances. L'extension DRI3 n'a plus besoin d'être modifiée pour prendre en charge de nouveaux formats de tampons particuliers, car ils sont désormais gérés directement entre le pilote client DRI et le pilote du noyau DRM. L'utilisation de descripteurs de fichiers, d'un autre côté, permet au noyau d'effectuer un nettoyage sécurisé de tout objet tampon GEM inutilisé, sans référence à celui-ci.

Techniquement, DRI3 se compose de deux extensions différentes, l'extension "DRI3" et l'extension "Présent". L'objectif principal de l'extension DRI3 est d'implémenter le mécanisme pour partager les tampons rendus directs entre les clients DRI et le serveur X. Les clients DRI allouent et utilisent des objets tampons GEM comme cibles de rendu, tandis que le serveur X représente ces tampons de rendu à l'aide d'un type d'objet X11 appelé « pixmap ». DRI3 fournit deux opérations, DRI3PixmapFromBuffer et DRI3BufferFromPixmap , une pour créer une pixmap (dans "l'espace X Server") à partir d'un objet tampon GEM (dans "l'espace client DRI"), et l'autre pour faire l'inverse et obtenir un objet tampon GEM à partir de une carte de pixels X. Dans ces opérations DRI3 les objets tampon GEM sont passés en tant que descripteurs de fichier DMA-BUF au lieu de noms GEM. DRI3 fournit également un moyen de partager des objets de synchronisation entre le client DRI et le serveur X, permettant à la fois un accès sérialisé au tampon partagé. Contrairement à DRI2, l' opération initiale DRI3Open ( la première que chaque client DRI doit demander pour savoir quel périphérique DRM utiliser) renvoie un descripteur de fichier déjà ouvert au nœud de périphérique au lieu du nom de fichier du nœud de périphérique, avec toute procédure d'authentification requise déjà effectuée à l'avance par le serveur X.

DRI3 ne fournit aucun mécanisme pour afficher les tampons rendus à l'écran, mais s'appuie sur une autre extension, l' extension Present , pour le faire. Present est ainsi nommé car sa tâche principale est de "présenter" les tampons à l'écran, ce qui signifie qu'il gère la mise à jour du framebuffer en utilisant le contenu des tampons rendus fournis par les applications clientes. Les mises à jour d'écran doivent être effectuées au bon moment, normalement pendant l' intervalle VBLANK afin d'éviter les artefacts d'affichage tels que le déchirement . Present gère également la synchronisation des mises à jour d'écran avec l'intervalle VBLANK. Il tient également le client X informé de l'instant où chaque tampon est réellement affiché à l'écran à l'aide d'événements, afin que le client puisse synchroniser son processus de rendu avec le taux de rafraîchissement actuel de l'écran.

Present accepte n'importe quel X pixmap comme source pour une mise à jour d'écran. Étant donné que les pixmaps sont des objets X standard, Present peut être utilisé non seulement par les clients DRI3 effectuant un rendu direct, mais également par tout rendu client X sur une pixmap par n'importe quel moyen. Par exemple, la plupart des applications GTK+ et Qt non basées sur GL étaient utilisées pour faire un rendu de pixmap à double tampon à l' aide de XRender . L'extension Present peut également être utilisée par ces applications pour obtenir des mises à jour d'écran efficaces et sans déchirure. C'est la raison pour laquelle Present a été développé comme une extension autonome distincte au lieu de faire partie de DRI3.

En plus de permettre aux clients non-GL X de se synchroniser avec VBLANK, Present apporte d'autres avantages. Les performances graphiques de DRI3 sont meilleures car Present est plus efficace que DRI2 dans l'échange de tampons. Un certain nombre d'extensions OpenGL qui n'étaient pas disponibles avec DRI2 sont désormais prises en charge sur la base des nouvelles fonctionnalités fournies par Present.

Present fournit deux opérations principales aux clients X : mettre à jour une région d'une fenêtre en utilisant une partie ou tout le contenu d'une pixmap ( PresentPixmap ) et définir le type d'événements de présentation liés à une certaine fenêtre dont le client veut être averti ( PresentSelectInput ). Il existe trois événements de présentation à propos desquels une fenêtre peut notifier un client X : lorsqu'une opération de présentation en cours - normalement à partir d'un appel à PresentPixmap - est terminée ( PresentCompleteNotify ), lorsqu'un pixmap utilisé par une opération PresentPixmap est prêt à être réutilisé ( PresentIdleNotify ) et lorsque la configuration de la fenêtre ( principalement la taille de la fenêtre) change ( PresentConfigureNotify ). Qu'une opération PresentPixmap effectue une copie directe ( blit ) sur le tampon avant ou un échange de l'intégralité du tampon arrière avec le tampon avant est un détail interne de l'implémentation de l'extension Present, au lieu d'un choix explicite du client X tel qu'il était dans DRI2.

Adoption

Plusieurs pilotes DRI open source ont été écrits, notamment pour ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 à Voodoo5, Matrox G200 à G400, SiS 300-series, Intel i810 à i965, S3 Savage, chipsets graphiques VIA UniChrome et nouveau pour Nvidia . Certains fournisseurs de graphiques ont écrit des pilotes DRI à source fermée, notamment ATI et PowerVR Kyro.

Les différentes versions de DRI ont été implémentées par divers systèmes d'exploitation, entre autres par le noyau Linux , FreeBSD , NetBSD , OpenBSD et OpenSolaris .

Histoire

Le projet a été lancé par Jens Owen et Kevin E. Martin de Precision Insight (financé par Silicon Graphics et Red Hat ). Il a d'abord été rendu largement disponible dans le cadre de XFree86 4.0 et fait maintenant partie du serveur X.Org . Il est actuellement maintenu par la communauté du logiciel libre .

Le travail sur DRI2 a commencé au X Developers' Summit 2007 à partir d'une proposition de Kristian Høgsberg . Høgsberg lui-même a écrit la nouvelle extension DRI2 et les modifications de Mesa et GLX . En mars 2008, DRI2 était presque terminé, mais il n'a pas pu être intégré à la version 1.5 du serveur X.Org et a dû attendre la version 1.6 de février 2009. L'extension DRI2 a été officiellement incluse dans la version X11R7.5 d'octobre 2009. La première La version publique du protocole DRI2 (2.0) a été annoncée en avril 2009. Depuis lors, il y a eu plusieurs révisions, la plus récente étant la version 2.8 de juillet 2012.

En raison de plusieurs limitations de DRI2, une nouvelle extension appelée DRI-Next a été proposée par Keith Packard et Emma Anholt à la X.Org Developer's Conference 2012. L'extension a été à nouveau proposée sous le nom DRI3000 à Linux.conf.au 2013. DRI3 et Present extensions ont été développés en 2013 et fusionnés dans la version X.Org Server 1.15 à partir de décembre 2013. La première et la seule version du protocole DRI3 (1.0) a été publiée en novembre 2013.

• 

  Pilotes 2D à l'intérieur du serveur X

• 

  Rendu indirect sur GLX , en utilisant Utah GLX ; séparé : fbdev

• 

  Early DRI: le réglage du mode est toujours effectué par le serveur d'affichage X , ce qui le force à être exécuté en tant que root

• 

  Enfin tous les accès passent par le Direct Rendering Manager

• 

  Dans le noyau Linux 3.12, des nœuds de rendu ont été introduits ; DRM et le pilote KMS ont été séparés. Wayland implémente le rendu direct sur EGL

Voir également

• Responsable Rendu Direct
• Mesa 3D
• Système X Window

Les références

Liens externes

• Page d'accueil du projet d'infrastructure de rendu direct
• Documents de spécification actuels (toujours mis à jour vers la version la plus récente) :
  • L'extension DRI2 (Kristian Høgsberg, 2008)
  • L'extension DRI3 (Keith Packard, 2013)
  • L'extension actuelle (Keith Packard, 2013)