X-Server mit OpenGL
XGL ist ein vor allem von David Revemann (Novell) geschriebener X-Server, der die Grafikausgabe über OpenGL realisiert. Wenn ein Programm XGL anweist eine Linie zu zeichnen, übergibt XGL die Endpunkte (Vertices) an das OpenGL-Subsystem, das die entsprechenden Befehle an die Grafikkarte richtet.
Trotz OpenGL bleibt bei XGL das Protokoll gleich, mit dem Applikationen sich an den X-Server wenden, es müssen also keine Programme umgeschrieben werden. Außerdem beschleunigt XGL eben nicht die Ausführung von OpenGL-Programmen, wie oft behauptet wird.
Im Gegenteil: Aus technischen Gründen ist zurzeit überhaupt nur indirektes Rendering möglich. Alle OpenGL-Befehle werden also über das GLX-Protokoll an XGL geschickt und erst dort an die Grafikhardware übergeben. Indirektes Rendering ist bei Programmen mit hoher Polygonzahl (Spiele) oder hohem Texturaufkommen (Video) deutlich langsamer als direktes Rendering.
Derzeit kann XGL (noch) nicht nativ auf die Hardware zugreifen, es muss also auf ein System aufsetzen, das den Framebuffer initialisiert und eine OpenGL-Schnittstelle zur Verfügung stellt. Aktuell ist das der gewohnte X-Server von X.org, das heißt, XGL öffnet - ähnlich wie Xnest - auf dem X.org-Server ein Fenster, das den gesamten Bildschirm bedeckt. Danach können sich X-Applikationen mit XGL verbinden, der Standard-X-Server hat hingegen während der gesamten Sitzung XGL als einzigen Client.
Die vom Server zu bearbeitenden X11-Befehle sind teilweise relativ komplex, deshalb kapselt eine Zwischenschicht die Anweisungen an OpenGL. Diese Bibliothek namens Glitz ist im Wesentlichen das OpenGL-beschleunigte Backend von Cairo, einem System für auflösungsunabhängige Grafikoperationen.
Sobald ein Composite-Manager ins Spiel kommt, verkompliziert sich der übliche Aufbau der Grafikpipeline. Wie Abbildung 1 zeigt, leitet der X-Server zuerst alle Fensterausgaben in nicht sichtbare Bereiche des Framebuffers um. Ein solcher Speicherbereich entsteht mit Hilfe eines »pBuffer« oder Framebuffer-Objekts (FBO). In diesen Speicherbereich werden alle X11-Befehle der Applikation umgeleitet und mit Hilfe von OpenGL gezeichnet. Dies passiert für alle Programme getrennt.

|
Abbildung 1: Pixelpipeline eines Composite-Managers unter XGL. Der Composite-Manager setzt die im nicht sichtbaren Speicherbereich gerenderten Fensterinhalte zu einem sichtbaren Desktop zusammen.
|
Danach zeichnet der Composite-Manager Compiz alle Fensterinhalte als Texturen auf OpenGL-Objekte. In der Regel sind dies Rechtecke, es können aber - etwa für Übergangseffekte - auch komplexere und dreidimensionale Objekte sein.
Compositing
XGL ist also nicht selbst für die atemberaubenden Effekte verantwortlich, von denen in letzter Zeit häufig die Rede war. Es erlaubt aber einen Composite-Manager zu schreiben, der selbst OpenGL-Befehle für die Darstellung der Fenster benutzt. Für den normalen X-Server ist das nicht ohne weiteres möglich, da OpenGL nicht mit dem zugrunde liegenden Fenstersystem verknüpft ist, also nicht auf die mit Hilfe von X11-Befehlen gezeichneten Fensterinhalte zugreifen kann.
Da XGL intern OpenGL benutzt, kann es die Fensterinhalte dem externen Composite-Manager mit Hilfe der Erweiterung »GLX_EXT_texture_from_pixmap« zugänglich machen. Diese Extension stellt nicht der OpenGL-Treiber, sondern XGL selber zur Verfügung. Der reguläre X.org-Server bietet diese Erweiterung im CVS seit der Implementation der AIGLX-Erweiterung ebenfalls an (siehe folgenden Artikel), allerdings fehlen noch die Unterstützung für Xvideo und OpenGL auf Anwendungsebene sowie Teile der beschleunigten Grafikbefehle.
Wie erwähnt muss der Composite-Manager den Desktop mit Hilfe von indirektem Rendering zeichnen, es werden also alle OpenGL-Kommandos über das GLX-Protokoll an XGL geschickt und erst dort an die Grafikhardware übergeben. Nur auf diese Weise kann ein anderer Prozess die Texturen einsetzen, die ja im Adressbereich von XGL liegen.
Das gleiche Problem betrifft auch alle OpenGL-Anwendungen, da sie in einen nicht sichtbaren Bereich des Framebuffers zeichnen müssen, der ebenfalls im Adressbereich des X-Servers liegt. Einzelheiten dazu finden sich in [4].
| Whitepaper |
|
Daten Migration - Eine Publikation von Bloor Research
Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele
Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|