Die dritte Dimension

GLX vs. DRI

Abbildung 1: Wie kommen 3D-Anweisungen von der Applikation auf den Bildschirm? Netzwerktransparent mit GLX oder performant mit DRI. (Bild: Bernhard Kuhn)

Als Mitte der 90er Jahre die ersten Grafikkarten mit speziellen 3D-Hardware-Beschleunigungs-Funktionen zu einem erschwinglichen Preis auf den Consumer-Markt kamen, waren Software-basierte 3D-Render-Lösungen noch an der Tagesordnung: Anwendungen, in denen 3D-Objekte gezeichnet werden sollten, mussten einen Software-Renderer damit beauftragen, eine Lösung zu berechnen, wie sich die 3D-Objekte mit den auf der Grafikkarte vorhandenen 2D-Funktionen möglichst gut darstellen lassen.

Kein Wunder, dass damit bei 3D-Grafiken nur äußerst geringe Frame-Raten möglich waren. Die 3D-Hardware-Unterstützung kam unter Linux nur langsam in Schwung, unter anderem weil zunächst ein Modul fehlte, welches eine Verbindung zwischen der OpenGL-Schnittstelle und den freien XFree86-Servern herstellen konnte: GLX.

An der University of Utah wurde eine freie GLX-Implementierung (http://utah-glx.sourceforge.net/) vorangebracht, allerdings beschränkt auf einige wenige unterstützte Grafikkarten. Der Durchbruch gelang unter Linux erst, nachdem SGI sein vormals kommerzielles GLX-Modul unter eine Open-Source-Lizenz gestellt hatte und die Firma Precision Insight damit beauftragte, an einer neuen Infrastruktur für das XFree86-Projekt zu arbeiten, mit der nicht nur ein indirekter (über den X-Server und das GLX-Protokoll vermittelter Zugriff), sondern (mittels eines ausgelagerten 3D-DRI-Treibers) ein direkter Zugriff auf die 3D-Hardware-Funktionen möglich sein sollte.

Diese Treiber-Infrastruktur trägt den Namen "Direct Rendering Infrastructure" (http://dri.sourceforge.net/) und erlaubt seit dem Erscheinen von XFree86 4.0 einen direkten (nur noch über einen Kernel-Treiber vermittelten) Zugriff auf die 3D-Hardware-Register von neueren Grafikkarten möglich. Eine Auswahl der DRI-Treiber für Kernel 2.4 finden Sie auf der Heft-CD.

Direkt oder indirekt?

Der größte Vorteil der Direct Rendering Infrastructure liegt für Grafik-Chip-Hersteller darin, dass sie dank der aus dem XFree86-Server ausgelagerten 3D-Treiberarchitektur auch proprietäre Treiber-Software beisteuern können, ohne damit die GPL-Lizenzbedingungen zu verletzen. Der 3D-Anwender profitiert dadurch theoretisch auch unter Linux in vollem Umfang von den 3D-Fähigkeiten seiner Grafikkarte.

Allerdings erkauft man sich diese direkte 3D-Unterstützung als Anwender mit der größeren Gefahr von Systemtotalabstürzen und dem Verlust der sogenannten Netzwerktransparenz. Dadurch, dass die 3D-Grafikbefehle nämlich nicht mehr über das X11-Netzwerkprotokoll an die Grafik-Hardware übertragen, sondern (über den DRI-Kernel-Treiber) auf direktem Wege übermittelt werden, bleibt im Falle eines Programmfehlers nicht nur der X-Server hängen, sondern im schlimmsten Fall das gesamte Betriebssystem.

Im klassischen Falle einer über den X-Server vermittelten Kommunikation mit der Grafik-Hardware besteht jederzeit die Möglichkeit, eine Anwendung auf einem anderen Rechner darzustellen, als auf demjenigen, von dem sie gestartet wurde. Dies ist auf der DRI-Architektur (momentan) nicht möglich, da die 3D-Befehle an die Grafikkarte nicht mehr über das X11-Netzwerkprotokoll vermittelt werden können.

Momentan hat man als 3D-Anwender also die Wahl zwischen direktem, aber zum Teil noch etwas instabilen 3D-Hardware-Rendering über die DRI-Treiber einerseits und indirektem (netzwerktransparent vermittelten) 3D-Software-Rendering (Mesa) andererseits. Für 3D-Spiele, die auf einem Einzelplatzrechner laufen, empfiehlt sich demnach der Einsatz von DRI-Treibern, während der Einsatz des Mesa-Renderers überall da sinnvoll erscheint, wo es auf größtmögliche Stabilität und Netzwerktransparenz ankommt. Das DRI-Projekt hat aber die Absicht bekundet, Mesa durch eine andere Lösung zu ersetzen, mit der dann auch indirektes 3D-Hardware-Rendering möglich sein soll.