Phillip Ross Inhalt |
Zusammenfassung:
Der Autor stellt den 3D Chipsatz von 3Dfx Interactive vor, der wohl als
Erster qualitativ hochwertige 3D Grafik zu einem akzeptablen Preis auf den PC brachte.
Vor ungefähr einem Jahr stellte eine Firma namens 3Dfx Interactive ihren neuen 3D Chipsatz vor, der die Einstatzmöglichkeiten des PCs im 3D Bereich grundlegend änderte. Vor dem Chipsatz von 3Dfx gab es keine finanzierbare High-End 3D Systeme im Heimbereich. Einzig teure Workstations von Sun oder SGI boten hochwertige 3D Grafik mit teurer Spezialhardware an. Zwar gab es PC-Grafikkarten von Number Nine, Diamond Multimedia oder Matrox, die gewisse Fähigkeiten im 3D Bereich aufwiesen, jedoch konnten sie in keiner Weise einem Vergleich mit der teuren 3D Hardware einer SGI oder anderen Workstations standhalten.
Mit dem Erscheinen des 3Dfx Chipsatz, mit dem Namen Voodoo 3Dfx, wurde High-End 3D Grafik auch für den durchschnittlichen Computerbenutzer erschwinglich. Die Leistung dieses Chipsatzes stellt zweifellos einen Wendepunkt in dem ewigen Versuch dar, hochwertige 3D Grafik auf den heimatlichen PC zu bringen. Bisher beschränkten sich die 3D Fähigkeiten der Chipsätze auf Z-Buffering und Gourad Shading (einige weiter fortgeschrittene Karten unterstützten auch begrenzten Einsatz von Texturen), und sie waren meist nur unter bestimmten Bildauflösungen und Farbtiefen einsetzbar. Leider war allzu häufig die CPU genötigt, diese Fähigkeiten einer Anwendung zu ermöglichen.
Man werfe mal einen Blick auf die Grafikkarten und ihre begrenzten Fähigkeiten im 3D Bereich. Betrachtet man zum Beispiel die Unterstützung von Z-Buffering, so werden häufig die Z Koordinaten von Punkten durch den Grafiktreiber nur im Grafikspeicher der Karte gehalten, der nicht andersweitig verwendet wird. Dieses Z-Buffering ist dann häufig nur in niedrigeren Auflösungen verfügbar, da höhere Auflösung mehr Grafikspeicher in Beschlag nehmen und so nicht mehr genügend Speicher für die Z-Koordinaten exisitiert. Aber auch mit der Speicherung der Z-Koordinaten im Videospeicher müßte ein Programm immer noch auf die CPU zurückgreifen, um die Z-Koordinaten von neuen Pixeln mit denen im Videospeicher zu vergleichen. Da diese Vergleiche einen Großteil der CPU Leistung verbrauchen, fällt durch die Unterstützung seitens der Grafikkarte immernoch nicht der klassische Flaschenhals des Z-Bufferings weg. Sollte dies dem Leser ein wenig zu komplex sein, so ist das nicht weiter tragisch, ist doch diese technische Erklärung nicht wirklich notwendig, um die Unterschiede zwischen Grafikkarten mit 3D Unterstützung und dem 3Dfx Chipsatzes zu erkennen.
Man wird feststellen, daß der Vodoo 3Dfx Chipsatz vieles an 3D Funktionalität besitzt, was andere Grafikkarten im selben Preissegment nicht vorweisen können. Der Chipsatz bietet allgemeine 3D Fähigkeiten, wie Gouraud Shading, Z-Buffering und W-Buffering, Alpha Blending, Nebel, Dithering, usw. Desweiteren unterstützt er perspektivisch korrekte Texturen, trilineares Mipmapping, Beleuchtung von Texturen, Sub-Pixel Korrektur und Dekompression von Texturen. All dies wird von der Hardwre erledigt, ohne daß die Anwendung allzu sehr oder gar überhaupt nicht darin involviert ist.Gegenwärtig unterstützt der Voodoo keine Koordinatenbildung, allerdings sollte dies kein großes Problem sein, da die modernen Prozessoren genügend Rechenleistung für solche Berechnungen bieten. Dennoch wird der Nachfolger dieses 3Dfx Chipsatzes, der Voodoo2, dies und noch weitere Fähigkeiten aufweisen. Die bereits getesteten Karten mit Voodoo2 Chipsatz stellen immer höhere Geschwindigkeitsrekorde auf! Jedoch ist das Preis-Leistungsverhältnis des aktellen Voodoo Chipsatzes dessen herausragendes Feature.
Leider hat auch der Voodoo 3Dfx seine Grenzen. Hauptbschränkung des Chipsatzes ist, daß er nur im Vollbild rendern kann. Desweiteren kann eine Karte mit diesem Chipsatz nur zusätzlich zu einer normalen Grafikkarte betrieben werden. Dabei wird die andere Karte für den normalen Einsatz genutzt, sobald eine Anwendung die 3Dfx Karte für Rendering nutzen will, greift sie auf die 3Dfx Treiber zu, um die Karte zu initialisieren. Der 3Dfx Chipsatz springt dann ein und fängt, entsprechend den von der Anwendung aufgerufenen Glidefunktionen, an, zu rendern.
In einem normalen System ohne 3Dfx Karte hat die Grafikkarte einen eigenen Slot auf dem Mainboard und ist direkt mit dem Monitor verbunden, auf dem die Ausgabe angezeigt wird. 3Dfx Karten, wie die Monster3D oder die Pure3D "schleifen" das Videosignal der normalen Grafikkarte durch, wodurch beide Karten an einem Monitor betrieben werden können. Hierbei sitzen beide Karten in jeweils einem Slot des Mainboards, die normale Grafikkarte ist jedoch mit einem Eingang der 3Dfx Karte verbunden, mittels einem Kabel, das den 3Dfx Karten beiliegt. Der Monitor ist ebenfalls an die 3Dfx Karte angeschlossen. Im normalen Betrieb erzeugt die Grafikkarte die Bildausgabe, welche über die 3Dfx Karte direkt an den Monitor geht. Greift eine Anwendung nun aber auf die 3Dfx Karte zu und initialisiert diese, so wird diese Weiterleitung unterbrochen und die eigene Ausgabe an den Monitor weitergegeben, bis die Anwendung die 3Dfx Karte über den Treiber de-initialisiert. Dadurch wird wieder das Signal der anderen Grafikkarte weitergereicht.
Dummerweise ist in dieser Konfiguration die Ausgabe der Grafikkarte nicht immer zu sehen, was zu Problemen bei Programmen führen kann, die ein Fenstersystem wie X benutzen und in einem Fenster rendern wollen. Es gibt eine weitere Möglichkeit, jedoch erfordert sie einen weiteren Monitor. Wenn zwei Monitore verfügbar sind, kann auf dem einen die Ausgabe der Grafikkarte, auf dem anderen die der 3Dfx Karte dargestellt werden. Dazu wird jeweils einer der Monitore an eine der Karten angeschlossen. Der Monitor der Grafikkarte zeigt immer deren Ausgabe an, während der an der 3Dfx Karte dunkel bleibt, bis diese initialisiert wird. Sobald dann die 3Dfx Karte anspringt, kann der eine Monitor weiter für die normale Ausgabe des Fenstersystemes benutzt werden, der andere bietet die Vollbilddarstellung der 3Dfx Karte.
Es gibt einen weiteren Chipsatz von 3Dfx, 3Dfx RUSH genannt, der in der Lage ist, im Fenster zu rendern. Grafikkarten mit diesem Chipsatz haben noch einen 2D Chipsatz, der neben dem Rush läuft und mit diesem einen gemeinsamen Bildspeicher hat. Da momentan diese Karten nicht von Linux unterstützt werden, werden sie hier nicht näher vorgestellt. Es sei aber angemerkt, daß an einer Linuxunterstützung gearbeitet wird.
Eine weitere Begrenzung des 3Dfx Chipsatzes ist die maximale Auflösung, die unterstützt wird. Während die heutigen Grafikkarten Auflösungen von 1280x1024, 1600x1200 oder noch höher erlauben, findet die 3Dfx Karten ihre Grenze bei 640x480. Allerdings ist dies nicht so sehr eine Beschränkung, wie man meinen mag. Die guten Anti-Aliasing und Texture Filtering Möglichkeiten des Chipsatzes erlauben es, eine Menge Objekte in eine 640x480 Auflösung zu quetschen, ohne daß diese "bröslig" wirken. Es ist bei einer 3DfX Karte teilweise wirklich schwer aufgrund eines Blickes auf den Schirm zu bestimmen, welche Auflösung momentan dargestellt wird!
Die normalen 3Dfx Karten, wie etwa die Monster3D, erreichen nur eine Bildschirmauflösung von 640x480. Es kann sein, daß einige Karten noch bis auf 800x600 gepusht werden können, jedoch sollen diese Karten dann keine Tiefen- und kein Alpha-Buffering mehr realisieren können, da der Speicher für diese Operationen für die höhere Auflösung gebraucht wird. Bessere 3Dfx Karten von Quantum 3D unterstützen auch 800x600 mit diesen Operationen.
3Dfx Interactive ist der Hersteller dieses Hochleistungs-Chipsatz. Jedoch bauen sie keine Beschleunigerkarten. Vielmehr sind es Firmen wie Diamond Multimedia, Orchid Technology und Canopus Corporation, die Grafikkarten mit dem 3Dfx Chipsatz produzieren. Diamond baut die Monster3D, Orchid die Righteous3D und Canopus die Pure3D. Eine Firma namens Quantum 3D, ein unabhängiger Sproß von 3DfX, bietet Beschleunigerkarten an, die die erweiterte Version des Voodoo (mehrere PixelFX und TexelFx Einheiten, größerer Bild- oder Texturenspeicher, usw.) benutzen. Diese Modelle sind unter der Bezeichnung Obsidian3D bekannt. Auf den 3Dfx Interactive WWW Seiten (www.3dfx.com) ist eine komplette Liste von Herstellern zu finden, die Karten mit dem 3Dfx Chipsatz bauen.
Man kann sich den Voodoo Chipsatz als eine fortschrittliche, flexible Rendermaschine vorstellen, die aus einer Anzahl von einzelnen Voodoo Subsystemen besteht. Diese können auf viele verschiedene Arten kombiniert werden, die einfachste Konfiguration besteht jedoch aus einem Subsystem. Jedes dieser Subsysteme besteht aus separaten Render-Prozessoren, den PixelFX und TexelFX Einheiten. Die TexelFX Einheit ist zuständig für Pixeloperationen, wie Gourad Shading oder Tiefenpufferung (Z-Buffering, W-Buffering). Die TexelFX Einheit hingegen kümmert sich um Texture-Operationen, wie Texture Filtering und Projektion. Zusammen können beide Einheiten Effekte, wie beleuchtete Texturen generieren. Jede der Einheiten hat ihren eigenen Grafikspeicher, der für ihre speziellen Operationen verwendet wird. Der PixelFX speichert in seinem Speicher Pixel für den Bildspeicher, der TexelFX benutzt seinen Speicher für Texturen.
Jede Konfiguration eines Voodoo Subsystemes besteht aus einer PixelFX Einheit, die Zahl der TexelFX Einheiten kann zwischen einer und dreien liegen, wodurch die Geschwindigkeit der Texturenverarbeitung erhöht werden kann. Eine Voodoo Rendermaschine kann sogar mit mehreren Subsystemen konfiguriert werden und mittels "Scanline Interleaving" effektiv die Berechnungsgeschwindigkeit verdoppeln. Diese skalierbaren Konfigurationen übertreffen in ihrer Leistung sogar High-End SGI Workstations, was in Tests nachgewiesen worden ist. Natürlich sind solche Konfigurationen allerdings ein wenig teurer, als eine einfache Konfiguration auf den gängigen Karten und können durch die meisten Benutzer eh nicht ausgereizt werden.
3Dfx Interactive stellt keine Dokumentation der Programmierung ihres Chipsatzes auf Registerebene zu Verfügung, aus Angst, "Reverse Engineering" ihrer Hardware einfacher zu machen (also die Funktionsweise zu ergründen). Stattdessen publizieren sie ein Software Development Kit (SDK) genannt Glide, welches als Software "Microlayer" direkt über der Hardware liegt. Glide ist eine Bibliothek, die die registerspezifischen Details verbirgt und eine API für die einfache Programmierung des 3Dfx Chipsatzes, ohne allzu großen Overhead zu verursachen. Die Bibliothek wird auf die Plattformen (inklusive Linux) portiert, die von 3Dfx unterstützt werden, für die Bibliothek gibt es detailierte Dokumentation. Entwickler können die API als Schnittstelle zwischen ihren 3D Programmen und dem 3Dfx Chipsatz nutzen. Glide ist eine recht hardwarenahe Bibliothek, im Gegensatz zu OpenGL und Direct3D. Sie bietet keine High-Level 3D Grafikfunktionen, wie Darstellungslisten oder geometrische Transformationen. Vielmehr stellt sie eine recht bescheidene Abstraktion von den Registern des Chipsatzes dar und stellt nur Software-funktionen zu Verfügung, die direkt in der Hardware des 3Dfx implementiert sind. Ich habe mit dem Menschen gesprochen, der Glide nach Linux portiert hat. Er meinte, daß die Bibliothek recht einfach sei. Im Prinzip übergibt man die richtigen Parameter an die Glide Funktionen,welche diese in die Register der Karte schreibt und dann den Chipsatz anweist, mit dem Rendern zu beginnen.
Dies bedeutet nicht, daß OpenGL und Direct3D Entwickler nicht 3Dfx Anwendungen schreiben könnten. Es sind OpenGL und Direct3D Treiber entwickelt worden, welche Glide benutzen, so daß diese Bibliotheken genutzt werden können, ihre High-Level Funktionen dann in Glide spezifische Operationen umgesetzt werden und so den 3Dfx nutzen. Dies ist eine recht schnelle und effiziente Art der Entwicklung.
Es wurde ein Treiber geschrieben, der als Schnittstelle zwischen Mesa (eine freie Implementierung von OpenGL, die unter vielen verschiedenen Betriebssystemen läuft) und Glide fungiert und so Hardwareunterstützung für OpenGL Anwendungen unter Windows95 und Linux bietet. Linux ist frei erhältlich, die Compiler für Linux sind frei erhältlich, Mesa ist frei und das Glide SDK von 3Dfx ist frei, prinzipiell bietet diese Kombination ein sehr kosteneffektives und leistungsfähiges System für die Entwicklung unter OpenGL! Leider gibt es das Glide SDK unter Linux nicht für Alpha oder Sparc Prozessoren, also ist dies auf die x86 Plattform beschränkt.
Als dieser Artikel geschrieben wurde, war die letzte Version von Mesa die 2.5, Beta Versionen von 2.6 werden getestet. Der Mesatreiber ist recht fortgeschritten, unterstützt die Beschleunigung von Punkten, Linien und Polygonrendering mit Flat und Gourad Shading, sowie Texturen, Z-Buffering, Nebel und Blending. Obwohl, wie schon erwähnt, der Voodoo 3Dfx Chipsatz, nur Vollbilddarstellung erlaubt, kann man, dank einer kleinen Routine in Mesa, auch im Fenster rendern. Durch diese Routine werden nämlich die Daten des Bildspeichers des 3Dfx über den Speicher in den Videospeicher der Grafikkarte transferiert. Auch wenn dies langsamer ist als die Berechnungen in der Vollbilddarstellung, ist es immer noch schneller, als das alleinige Software Rendering unter Mesa.
Mesa kann von dem Mesa FTP Server unter ftp://iris.ssec.wisc.edu/pub/Mesa bezogen werden. Die Bibliothek wird in zwei separaten Paketen verbreitet. Das eine beinhaltet die Hauptbibliothek und Includedateien. Ihr Name fängt mit "MesaLib" an. Die andere Datei enthält nur Demodateien. Deren Name sollte mit "MesaDemos" anfangen. Für die Installation entpackt man einfach die Pakete und wechselt dann in das Verzeichnis. Nun stehen einem mehrere verschiedene Möglichkeiten zur Verfügung, Mesa zu kompilieren. In der Version 2.5 wurden einige Transformationen aus Leistungsgründen in 386 Assembler neu geschrieben. Leider sind sie ein wenig fehlerhaft, aber dies sollte in den 2.6 Beta Versionen korrigiert worden sein. Mesa mit 3Dfx Unterstützung und ohne die Assembler Routinen wird durch "make linux-glide" erzeugt (natürlich ohne Anführungszeichen). Sollen die Optimierungen mit einkompiliert werden: "makelinux-386-glide". Mit Version 2.6 wurden einige Optimierungen für den Compiler in die Make Datei eingeführt, wodurch Mesa für den Einsatz mit den populären Spielen GlQuake und Quake II optimiert wird. Die GlQuake Optimierungen werden mittels "make linux-386-quake-glide" in Mesa einkompiliert.
Nachdem Mesa kompiliert worden ist, gibt es verschiedene Möglichkeiten der Installation. Alternativ können die Dateien des include und lib Verzeichnisses nach /usr/include und /usr/lib oder aber auch /usr/local/include und /usr/local/lib kopiert werden. Prinzipiell können sie überall hin kopiert werden, wo sie der dynamische Linker finden kann. Die Verzeichnisse, die der Linker durchsucht, stehen in der Datei /etc/ld.so.conf. Da Mesa sich sehr schnell weiterentwickelt, teste ich immer wieder die Betaversionen aus, sobald sie erhältlich sind. Für jede Version habe ich ein separates Verzeichnis. Je nachdem, welche Version eingesetzt werden soll, wird dann die Datei ld.so.conf modifiziert und enthält dann das jeweilige Verzeichnis, welches die Dateien der gewünschten Version enthält. Gegenwärtig habe ich das Verzeichniss /usr/local/Mesa-2.5 für Version 2.5 mit den Bibliotheksdateien in /usr/local/Mesa-2.5/lib und den Includedateien in /usr/local/Mesa-2.5/include. Für die 2.6 Betas dann noch die Verzeichnisse /usr/local/Mesa-2.6b1 oder /usr/local/Mesa-2.6b2. Allerdings bleibt dies jedem selbst überlassen. Wichtig ist, daß ein Schritt nicht vergessen wird: Jedes Mal, wenn eine neue Bibliothek installiert oder eines der Verzeichnisse in /etc/ld.so.conf geändert wurde, muß das Werkzeug ldconfig gestartet werden. Dieses setzt in den Verzeichnissen die richtigen symbolischen Verweise (Links) und tut noch ein paar ander Dinge. Mit der Option -p kann angezeigt werden, welche Bibliothek der Linker momentan kennt. Will man wissen, welche Version von Mesa eine Anwendung verwenden wird, gibt man folgendes ein:
ldconfig -p | grep MesaNachdem Mesa installiert worden ist, kann es losgehen. Eine Mesa Anwendung, die den 3Dfx nutzen soll,muß als "root" ausgeführt werden. Außerdem muß der X Server mit 16 Bit Farbtiefe laufen. Sind die Demos mit heruntergeladen und entpackt worden, so sollten sie bei der Übersetzung von Mesa mit kompiliert werden. Es gibt drei Möglichkeiten, eine Mesa Anwendung auszuführen. Zuerst können alle Berechnungen softwaremäßig durchgeführt werden, ohne 3Dfx. Das ist die normale Vorgehensweise. Damit die Anwendung den 3Dfx Chipsatz nutzt, muß eine Umgebungsvariable gesetzt werden. Für die Vollbilddarstellung mit 3Dfx Unterstützung muß
MESA_GLX_FX=fullscreenDadurch wird das Programm den 3Dfx Chipsatz benutzen. Allerdings ist es ein wenig trickreich, ein Mesa Programm innerhalb eines Fensters laufen zu lassen. Wird eine Mesa Anwendung gestartet, so weiß der X Server nicht einmal, daß die 3Dfx Karte existiert. Was nun passiert, ist, daß ein Fenster initialisiert und geöffnet wird, die 3Dfx Karte initialisiert wird und mit dem Rendern anfängt. Verläßt der Mauspointer das Fenster unter dem X Server, so wird das Mesa Programm keine Tastatureingabe und keine Mausaktionen mehr empfangen. Deswegen sollte man eine interaktive Fensterpositionierung des Windowmanagers wählen, wenn möglich, falls man nur einen Monitor hat. Andernfalls wird man nicht in der Lage sein, den Desktop des Windowmanagers zu sehen und den Mauszeiger wieder in das Fenster zurückzubewegen, sobald die 3Dfx Karte anspringt. Es ist möglich, ein Mesa Programm zu schreiben, in welchem der Mauszeiger nicht mehr aus dem Fenster bewegt werden kann, sobald man in ihm drin ist. Sollte der Mauszeiger die Fenstergrenze erreichen, so wird er zurück in die Fenstermitte gebracht (bekannt als "Mouse Warp").
Damit das Programm den 3Dfx Chipsatz benutzt, um in dem Fenster zu rendern, müsen einige andere Umgebunsvariablen gesetzt werden:
SST_VGA_PASS=1Dann muß MESA_GLX_FX=window gesetzt werden. Nun sollte ein Mesa Programm besser in einem Fenster laufen, als wenn nur mittels Software gerendert wird.
This website is maintained by Miguel Angel Sepulveda © Phillip Ross 1998 LinuxFocus 1998 |