Welche Beziehung besteht zwischen OpenGL, GLX, DRI und Mesa3D?


17

Ich beginne mit der einfachen 3D-Programmierung unter Linux. Ich habe viel Erfahrung mit der übergeordneten Grafik-API OpenInventor.

Ich weiß, es ist nicht unbedingt notwendig zu wissen, wie all diese Dinge zusammenpassen, aber ich bin nur neugierig. Ich weiß, dass OpenGL nur ein Standard für Grafikanwendungen ist. Mesa3D scheint eine Open-Source-Implementierung dieses Standards zu sein.

Wo passen GLX und DRI? Bei Wikipedia und all diesen Websites habe ich noch keine Erklärung dafür gefunden, wie das alles zusammenpasst. Wo findet die Hardwarebeschleunigung statt? Was haben proprietäre Treiber damit zu tun?

Antworten:


15

Mit Ausnahme von OpenGL habe ich diese Bibliotheken nie benutzt, aber ich werde versuchen, durch Lesen von Wikipedia-Seiten zu erraten, wie Sie es getan haben.

Sie scheinen recht mit Mesa zu haben. Hier sind die zusätzlichen Informationen, die wir haben:

"Das X-Window-System ist ein Computersoftwaresystem und ein Netzwerkprotokoll, das eine Basis-GUI für vernetzte Computer bereitstellt. Es erstellt eine Hardwareabstraktionsschicht."

"Mit GLX können Programme OpenGL in einem vom X Window System bereitgestellten Fenster verwenden.
GLX besteht aus drei Teilen:
- Eine API, die OpenGL-Funktionen bereitstellt.
- Eine Erweiterung des X-Protokolls, mit der der Client 3D senden kann Rendering-Befehle - Eine Erweiterung des X-Servers, der die Rendering-Befehle vom Client empfängt und an die installierte OpenGL-Bibliothek
weiterleitet. Wenn Client und Server auf demselben Computer ausgeführt werden und eine beschleunigte 3D-Grafikkarte verfügbar ist, können die beiden vorherigen Komponenten werden von DRI umgangen. Das Client-Programm kann dann direkt auf die Grafikhardware zugreifen. "

"Direct Rendering Infrastructure (DRI) ist eine Schnittstelle, die im X Window System verwendet wird, um Benutzeranwendungen den Zugriff auf die Video-Hardware zu ermöglichen, ohne dass Daten über den X-Server übertragen werden müssen."

"Open Inventor ist eine C ++ 3D-Grafik-API, die eine höhere Programmierschicht für OpenGL bietet."

Stellen wir uns zur Vereinfachung einen vereinfachten Datenfluss (und Befehlsfluss) vor, der an den Ein- und Ausgängen jeder dieser APIs stattfindet. Ganz am Anfang haben wir Ihr Anwendungsprogramm (kompilierter Code), das Sie von Ihrem Computer ausführen. Am Ende haben wir Bilder, die auf Ihrem Bildschirm angezeigt werden.

Es gibt mehrere Fälle, die ich auf die Antworten auf diese Fragen beschränken werde: -
Verfügt Ihr Computer über eine Grafikkarte (GPU) oder nur über eine CPU, um Grafikfunktionen zu verarbeiten?
- Ist Ihre Anwendung in ein Fenster des X-Window-Systems eingebettet?
-wenn Sie das x-Window-System verwenden, wird der "x-Server" auf Ihrem Computer oder einem anderen Computer im Netzwerk ausgeführt?
Ich gehe davon aus, dass Sie die Treiber für Ihre GPU haben, wenn Sie einen haben, und dass Sie Mesa für das Software-Rendering haben.

Erstes Szenario: Sie führen eine mit OpenInventor geschriebene Grafikanwendung aus, ohne das X Window System zu verwenden, und Sie haben keine Grafikkarte. Der Programmablauf würde ungefähr so ​​aussehen:

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

Was hier passiert, wird als "Software-Rendering" bezeichnet: Die Grafikbefehle werden nicht von Grafikhardware verarbeitet, sondern von Ihrer normalen CPU, dem Prozessor, auf dem normalerweise Software ausgeführt wird.

Zweites Szenario: Stellen Sie sich jetzt vor, dass Sie unter den gleichen Bedingungen wie oben eine Grafikkarte haben. Der Ablauf würde ungefähr so ​​aussehen:

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

Was jetzt passiert, wird als "Hardwarebeschleunigung" bezeichnet und ist normalerweise schneller als das erste Szenario.

Drittes Szenario: Lassen Sie uns nun anhand der wenigen von mir gelesenen Wikipedia-Zeilen den Ablauf des X-Window-Systems vorstellen, oder zumindest, wie ich denke.
Vergessen wir die Grafikhardware und die API für eine Weile. Der Ablauf sollte wie folgt aussehen:

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

Beachten Sie, dass bei Verwendung des X Window-Systems Ihr Bildschirm und der Computer, auf dem Sie Ihre Anwendung ausführen, möglicherweise nicht "direkt" verbunden sind, sondern über ein Netzwerk verbunden sein können.

Viertes Szenario: Angenommen, Sie möchten Ihrer X Client-Anwendung aus dem vorherigen Beispiel ausgefallene 3D-Grafik-Renderings hinzufügen. Es scheint mir, dass das X Window System dies ursprünglich nicht kann, oder es würde zumindest viel verschlungenen Code erfordern, um das Äquivalent einer OpenGL-API-Funktion auszuführen.
Glücklicherweise können Sie GLX verwenden, um dem System Unterstützung für OpenGL-Befehle hinzuzufügen. Sie haben jetzt:

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)
 ...

Jetzt können Sie diesen letzten Pfeil wieder mit dem Pfeil nach "OpenGL" im ersten Szenario verbinden: Sie können 3D-Bilder auf Ihrem Bildschirm erhalten!

Abschließend zu dem, was ich unter DRI verstehe:
Es scheint Mesa den Zugriff auf die GPU zu ermöglichen, sodass sich der Ablauf unseres ersten Szenarios ändern würde in:

...
  ↓
Mesa
  ↓ (forwards OpenGL commands)
DRI
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

Außerdem scheint es den Datenfluss bei der Verwendung von GLX kurzzuschließen, vorausgesetzt, Server und Client befinden sich auf demselben Computer und Sie haben eine GPU. In diesem Fall würde das Diagramm unseres vierten Szenarios einfach wie folgt aussehen:

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

Das ist es !
Denken Sie jetzt daran, dass ich kein Experte für Unix-Umgebungen bin. Daher ist es mein bester Rat, die Dokumentation jeder dieser APIs zu studieren, um genau zu wissen, was sie können.
Wenn Sie das vorherige Diagramm zu einem einzigen Diagramm kombinieren, wird das Verständnis möglicherweise erleichtert. Ich lasse dir das als Übung zu!


1
Es ist nur eine Theorie, die auf dem Abzug aus wenigen Sätzen beruht. es ist nicht die wahrheit.
KawaiKx

8

OpenGL ist plattformunabhängig. Dies bedeutet, dass die OpenGL-API plattformunabhängig ist.

Die OpenGL-Zustände und -Puffer werden von einem abstrakten Objekt gesammelt, das allgemein als Kontext bezeichnet wird.

Die Hosting-Plattform ist dafür verantwortlich, einige APIs bereitzustellen, um den OpenGL-Kontext für die zugrunde liegende Plattform zu erstellen. Unter Windows gibt es die wgl * -Routinen (Windows for GL), unter Unix gibt es glX * -Routinen (GL for X).

Tatsächlich ist GLX nichts anderes als eine API, mit der eine Anwendung OpenGL-Kontext erstellen kann, um die OpenGL-API zu verwenden.

Häufige WGL / GLX-Vorgänge sind das Erstellen eines Fensters, das Erstellen eines Off-Screen-Puffers, das Aktualisieren des OpenGL-Kontexts in einem Thread, das Austauschen von Zeichenpuffern ...

DRI ist stattdessen eine Kernel-Schicht, die die direkte Kommunikation mit der Grafikkarte unter Umgehung des XServers ermöglicht und die Anwendung mithilfe von OpenGL-Routinen beschleunigt.


3

http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html

Die Direct Rendering-Infrastruktur, auch als DRI bezeichnet, ist ein Framework, mit dem auf sichere und effiziente Weise direkt auf Grafikhardware unter dem X Window-System zugegriffen werden kann. Es enthält Änderungen am X-Server, an mehreren Client-Bibliotheken und am Kernel (DRM, Direct Rendering Manager). Die wichtigste Verwendung des DRI ist die Erstellung schneller OpenGL-Implementierungen, die eine Hardwarebeschleunigung für Mesa ermöglichen. Mehrere 3D-beschleunigte Treiber wurden in die DRI-Spezifikation geschrieben, darunter Treiber für Chipsätze von 3DFX, AMD (ehemals ATI), Intel und Matrox.


2

Einfach ausgedrückt ist OpenGL der Typ und die Spezifikation der Grafikbibliothek. Mesa ist eine Basisimplementierung. DRI ist ein Hardware-Schnittstellensystem.

Mesa bezieht sich grundsätzlich auf das gesamte Framework. Ich gehe jedoch davon aus, dass Sie vom Mesa-Hardwaretreiber sprechen.

DRI ist im Grunde die Kernel-Schnittstelle für die Hardware. Es könnte technisch für andere Dinge verwendet werden, aber es wurde für Mesa hergestellt und wird hauptsächlich für Mesa verwendet.

GLX ist wie es alle Schnittstellen zu X !!

Um zu verstehen, was ein Teil ist, muss man wissen, wie es zusammenpasst.

Ein Programm kann mit jeder OpenGL-Bibliothek verbunden werden.

GLX ist ein Mittel, um OpenGL mit oder über X11 zu verbinden. Je nachdem, ob Sie eine "Direct" -Schnittstelle oder eine "Indirect" -Schnittstelle haben, hängt es davon ab, ob sich Ihr Programm darum kümmert.

libGL ist so ziemlich die Schnittstelle für diese. Es wird normalerweise von Mesa bereitgestellt, wenn Sie einen Mesa-Treiber verwenden.

In einer indirekten Konfiguration sieht dies wie folgt aus: Anwendungsframework (dh hartgeschriebene Anwendung, Engine oder Abstraktions-API) | LibGL | Mesa-Treiber | DRI | Hardware

In dieser Konfiguration wird GLX nur an der Seite verwendet, um die Schnittstelle zwischen der GL-Verwendung Ihres Programms und anderen Programmen zu handhaben. Abgesehen von GLX-spezifischen Aufrufen, die für Aufgaben verwendet werden, die eine Kommunikation des X11-Stacks und seiner Unterstützungsprogramme (wie z. B. Window Manager) erfordern, bleibt GLX weitgehend unberührt. in dieser Anordnung.

Darüber hinaus können Command Passthrough und Shared Memory verwendet werden, um die Ebenen in diesem System weiter zu optimieren. Dies alles reduziert die Latenzen und beschleunigt den Zugriff auf die Hardware. Dies ist, was Sie normalerweise wollen.

Für einen indirekten Benutzer ist dies Ihr Anwendungsframework LibGL (Benutzerseite) | LibGLX | LibGL (X11-Seite) | Mesa Hardware Treiber | DRI | Hardware

Dies hat den Vorteil, dass Sie keinen direkten gemeinsam genutzten Speicherpuffer mit der Hardware benötigen, um dieses Setup zu verwenden. (Ermöglicht Netzwerkclients sowie mehr Robustheit und eine sicherere Einrichtung.)

Dieses Setup kann auf mehreren VMs ausgeführt werden, die eine einzelne Grafikkarte gemeinsam nutzen, oder es kann aus diesem Grund sogar über ein Netzwerk zugegriffen werden. Einige Formen von gemeinsam genutztem Speicher oder virtuellem gemeinsam genutztem "geklontem" Speicher können aufgrund neuerer Erweiterungen verwendet werden, es handelt sich jedoch nicht um den direkten Videospeicherzugriff, der im direkten Rendermodus zu finden ist.

Der Nachteil ist, dass die Verwendung von Pipes oder Netzwerk-Sockets für die Schnittstelle mit X11 langsam sein kann. Dies führt zumindest zu Latenzen bei gut optimierten Programmen und im schlimmsten Fall zu einer drastischen Senkung der Frameraten bei schlecht optimierten Programmen.

Dies ist die Art der Einrichtung, die für Netzwerkclients besser ist, Einrichtungen, die eine robustere Sicherheit erfordern, und Einrichtungen, bei denen mehrere Betriebssysteme Hardware gemeinsam nutzen müssen, indem sie denselben GL-Stapel durchlaufen. Es ist alles andere als optimal, bietet Ihnen jedoch ein gewisses Maß an Hardwarebeschleunigung.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.