Sauf OpenGL, je n'ai jamais utilisé ces bibliothèques, mais je vais essayer de deviner, en lisant les pages wikipedia, comme vous l'avez fait.
Vous avez raison sur Mesa. Voici les informations supplémentaires que nous avons:
"Le système X Window est un système logiciel informatique et un protocole réseau qui fournit une interface graphique de base pour les ordinateurs en réseau. Il crée une couche d'abstraction matérielle."
"GLX permet aux programmes souhaitant utiliser OpenGL de le faire dans une fenêtre fournie par le système X Window.
GLX se compose de trois parties:
- Une API qui fournit des fonctions OpenGL.
- Une extension du protocole X, qui permet au client d'envoyer des 3D commandes de rendu - Une extension du serveur X qui reçoit les commandes de rendu du client et les transmet à la bibliothèque OpenGL installée
Si le client et le serveur s'exécutent sur le même ordinateur et qu'une carte graphique 3D accélérée est disponible, les deux anciens composants peuvent être contourné par DRI. Le programme client est alors autorisé à accéder directement au matériel graphique. "
"L'infrastructure de rendu direct (DRI) est une interface utilisée dans le système X Window pour permettre aux applications utilisateur d'accéder au matériel vidéo sans que les données soient transmises via le serveur X."
"Open Inventor est une API graphique C ++ 3D conçue pour fournir une couche supérieure de programmation pour OpenGL"
Pour simplifier les choses, imaginons un flux simplifié de données (et de commandes) qui se produit aux entrées et sorties de chacune de ces API. Au tout début, nous avons votre programme d'application (code compilé), que vous exécutez à partir de votre ordinateur. À la fin, nous avons des images qui s'affichent sur votre écran.
Il y a plusieurs cas que je
limiterai aux réponses à ces questions: - votre ordinateur a-t-il une carte graphique (GPU), ou seulement un CPU, pour traiter les fonctions graphiques?
- votre application est-elle intégrée dans une fenêtre du système x-window?
-si vous utilisez le système x window, le "serveur x" fonctionne-t-il sur votre ordinateur ou sur un autre ordinateur du réseau?
Je suppose que vous avez les pilotes pour votre GPU si vous en avez un et que vous avez Mesa pour le rendu logiciel).
Premier scénario: vous exécutez une application graphique écrite avec OpenInventor, sans utiliser le système X Window, et vous n'avez pas de carte graphique. Le déroulement du programme serait assez similaire à:
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Mesa
↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
↓
3D Images on your screen
Ce qui se passe ici est appelé "rendu logiciel": les commandes graphiques ne sont gérées par aucun matériel graphique, mais plutôt par votre CPU habituel, le processeur qui exécute généralement les logiciels.
Deuxième scénario: imaginez maintenant qu'avec les mêmes conditions que ci-dessus, vous disposez d'une carte graphique. Le flux ressemblerait plus à ceci:
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Proprietary Drivers
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
Ce qui se passe maintenant est appelé "accélération matérielle", généralement plus rapide que le premier scénario.
Troisième scénario: introduisons maintenant le flux du système X Window, ou du moins comment je pense qu'il est basé sur les quelques lignes de Wikipédia que j'ai lues.
Oublions le matériel graphique et l'API pendant un certain temps. Le flux devrait ressembler à:
Your application (X Window System sees it as an "X Client")
↓ (sends requests defined by the X Window System Core Protocol)
X Server
↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
↓
Windows or 2D images on your screen
Notez que lorsque vous utilisez le système X Window, votre écran et l'ordinateur à partir duquel vous exécutez votre application peuvent ne pas être "directement" connectés, mais peuvent être connectés via un réseau.
Quatrième scénario: supposez que vous souhaitiez ajouter des rendus graphiques 3D fantaisistes à votre application X Client à partir de l'exemple précédent. Il me semble que le système X Window n'est pas capable à l'origine de le faire, ou du moins cela nécessiterait beaucoup de code alambiqué pour effectuer l'équivalent d'une fonction API OpenGL.
Heureusement, vous pouvez utiliser GLX pour ajouter la prise en charge des commandes OpenGL au système. Vous avez maintenant:
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
↓ (convert your request to OpenGL commands)
OpenGL
↓ (redirects function calls to implementation defined by)
...
Vous pouvez maintenant reconnecter cette dernière flèche à celle après "OpenGL" dans le premier scénario: vous pouvez obtenir des images 3D sur votre écran!
Enfin sur ce que je pense comprendre du DRI:
Il semble permettre à Mesa d'avoir accès au GPU, ce qui modifierait le flux de notre premier scénario en:
...
↓
Mesa
↓ (forwards OpenGL commands)
DRI
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
Et il semble également court-circuiter le flux lors de l'utilisation de GLX, étant donné que son serveur et son client sont sur le même ordinateur et que vous avez un GPU. Dans ce cas, le graphique de notre quatrième scénario deviendrait simplement:
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
↓
3D Images on your screen
C'est ça !
Maintenant, gardez à l'esprit que je ne suis pas un expert des environnements Unix, donc mon meilleur conseil est d'étudier la documentation de chacune de ces API pour savoir précisément ce qu'elles peuvent faire.
La combinaison du graphique précédent en un seul peut rendre les choses plus faciles à comprendre. Je vous laisse cela comme un exercice!
OpenGL est indépendant de la plate-forme; cela signifie que l'API OpenGL est indépendante de la plate-forme.
Les états et tampons OpenGL sont collectés par un objet abstrait, communément appelé contexte.
La plateforme d'hébergement est chargée de fournir une API pour créer le contexte OpenGL pour la plateforme sous-jacente. Sous Windows, il existe les routines wgl * (Windows pour GL), sous Unix, il existe des routines glX * (GL pour X).
En effet, GLX n'est rien d'autre qu'une API qui permet à une application de créer un contexte OpenGL, afin d'utiliser l'API OpenGL.
Les opérations WGL / GLX courantes sont la création d'une fenêtre, la création d'un tampon hors écran, l'actualisation du contexte OpenGL sur un thread, l'échange de tampons de tirage ...
DRI est plutôt une couche de noyau qui permet une communication directe avec la carte graphique, en contournant le XServer, accélérant en effet l'application à l'aide de routines OpenGL.
la source
http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
L'infrastructure de rendu direct, également connue sous le nom de DRI, est un cadre permettant un accès direct au matériel graphique sous le système X Window de manière sûre et efficace. Il inclut des modifications du serveur X, de plusieurs bibliothèques clientes et du noyau (DRM, Direct Rendering Manager). L'utilisation la plus importante pour le DRI est de créer des implémentations OpenGL rapides fournissant une accélération matérielle pour Mesa. Plusieurs pilotes 3D accélérés ont été écrits selon la spécification DRI, y compris les pilotes de chipsets produits par 3DFX, AMD (anciennement ATI), Intel et Matrox.
la source
Pour le dire simplement, OpenGL est le type et la spécification de la bibliothèque graphique. Mesa est une implémentation de base. DRI est un système d'interface matérielle.
Mesa se réfère essentiellement à l'ensemble du cadre. Cependant, je suppose que vous parlez du pilote matériel Mesa.
DRI est fondamentalement l'interface du noyau pour gérer le matériel. Techniquement, il pourrait être utilisé pour d'autres choses, mais il a été fait pour Mesa et est principalement utilisé pour Mesa.
GLX est la façon dont tout cela s'interface avec X !!
Pour comprendre ce qu'est chaque pièce, vous devez savoir comment elle s'emboîte.
Un programme est conçu pour s'interfacer avec n'importe quelle bibliothèque openGL.
GLX est un moyen d'interfacer OpenGL avec ou via X11. Selon que vous avez une interface "directe" ou une interface "indirecte", cela dépend si votre programme s'en souciera.
libGL est à peu près l'interface pour ceux-ci. Il est généralement fourni par Mesa si vous utilisez un pilote Mesa.
Dans une configuration indirecte, cela se déroule comme suit: Application Framework (c'est-à-dire application écrite en dur, moteur ou API d'abstraction) | LibGL | Pilote Mesa | DRI | Matériel
Dans cette configuration, GLX est juste utilisé sur le côté pour gérer l'interfaçage entre l'utilisation de votre programme GL et d'autres programmes. Hormis les appels spécifiques à GLX utilisés pour faire des choses qui nécessitent une communication, la pile X11 et ses programmes de support (tels que les gestionnaires de fenêtres) GLX est largement intact. dans cet arrangement.
De plus, le passage de commande et la mémoire partagée peuvent être utilisés pour optimiser davantage les couches de ce système. Tout cela réduit les latences et améliore la vitesse d'accès au matériel. C'est ce que vous voulez habituellement.
Pour une indirecte, c'est votre cadre d'application | LibGL (côté utilisateur) | LibGLX | LibGL (côté X11) | Pilote matériel Mesa | DRI | Matériel
L'avantage de ceci est que vous n'avez pas besoin d'un tampon de mémoire partagée directe avec le matériel pour utiliser cette configuration. (Permettant aux clients du réseau, ainsi qu'une plus grande robustesse et une configuration plus sécurisée.)
Cette configuration peut fonctionner sur plusieurs machines virtuelles partageant une seule carte vidéo ou même accéder à travers un réseau à cause de cela. Certaines formes de mémoire partagée ou de mémoire virtuelle partagée "clonée" peuvent être utilisées en raison de nouvelles extensions, mais ce n'est pas l'accès direct à la mémoire vidéo trouvé en mode de rendu direct.
L'inconvénient est que l'utilisation de canaux ou de sockets réseau pour interfacer avec X11 peut être lente, introduisant à tout le moins des latences sur des programmes bien optimisés et, au pire, une diminution drastique des taux de trame sur des programmes mal optimisés.
C'est le type de configuration qui convient le mieux aux clients en réseau, aux configurations nécessitant une sécurité plus robuste et aux configurations où plusieurs systèmes d'exploitation doivent partager le matériel en exécutant la même pile GL. C'est loin d'être optimal mais cela vous donne une certaine accélération matérielle.
la source