Was muss meine Grafikkarte können ? Was für Software gibt es ?

Ich gebe zu Bedenken, dass die Grundlagen dieser Arbeit aus den Jahren 1997 und 1998 stammen. Dadurch mag das ein oder andere etwas veraltet anmuten, im Prinzip dürfte aber nix falsches drinstehen ;-) Abgesehen davon ist es interessant, was vor über 5 Jahren prognostiziert wurde...

• Software zur 3D-Visualisierung
  • Einteilung der Grafikschnittstellen
  • Prozedurale Grafiksysteme
    • GKS und GKS-3D
    • PHIGS und PHIGS+
    • PEXlib und PEX
    • Direct3D
    • IRIS GL und OpenGL
    • QuickDraw 3D
    • Heidi
    • HP Starbase, Sun XGL
    • Deskriptive Grafiksysteme
    • HOOPS
    • Open Inventor
    • VRML
    • IRIS Performer
    • OpenGL Optimizer
    • Fahrenheit
• Hardware zur 3D-Visualisierung
  • Die Grafik-Pipeline
  • System-Klassifizierung
  • Ausbaustufen der Grafikhardware
    • Speicher
    • Spezialisierte Prozessoren
  • Performance der verfügbaren Hardware
    • Definierbarkeit der Grafikleistung
    • Realisierung durch spezialisierte 3D-Hardware

Software zur 3D-Visualisierung

Einteilung der Grafikschnittstellen

Gegenstand dieses Kapitels ist es, einen grundsätzlichen Überblick über den Markt der 3D-API’s (application programming interface: Schnittstelle zwischen Programmierer und Betriebssystem) zu geben. Dabei lassen sich im wesentlichen zwei Grundtypen unterscheiden: Das ist zum einen das prozedurale Grafiksystem, dem auf der anderen Seite das deskriptive (oder objektorientierte) Grafiksystem gegenübersteht.

Ein prozedurales Grafiksystem setzt eine explizite Beschreibung der Zeichenkommandos voraus. Der Programmierer muss hierbei die abzubildenden Objekte so beschreiben, dass sich diese mit den aus den [3D-Grundlagen] und der [3D-Mathematik] bekannten Methoden zeichnen lassen. Für die Darstellung eines Quaders heisst das, bekannte Primitive - z.B. Polygone - so zu verknüpfen, dass der Betrachter das Objekt eindeutig als Quader erkennen kann.

Im Gegensatz dazu bieten deskriptive Grafiksysteme die Möglichkeit, eine Szene abstrakter zu beschreiben: Ein Quader kann so zum Beispiel einfach durch den Befehl "Zeichne Quader" zur Abbildung gebracht werden, indem auf spezielle Grafikdatenbanken zurückgegriffen wird. Zur Ausführung der in diesen Datenbanken enthaltenen Anweisungen greifen deskriptive Grafiksysteme zwar auch auf prozedurale Grafiksysteme zurück, allerdings entzieht sich dem Programmierer die Kenntnis über die genaue Umsetzung der Befehle [6].

Ein prozedurales Grafiksystem bietet also prinzipiell den Vorteil der vollständigen Kontrolle über die Ausführung von Anweisungen und damit die Möglichkeit zu gezielten Veränderungen, während ein deskriptives System grundsätzlich eine einfache Modellierung auch komplexerer Szenen ermöglicht.

Im Zusammenhang mit der Unterscheidung von prozeduralen und deskriptiven Grafiksystemen stehen auch die Begriffe Immediate Mode und Retained Mode. Der Immediate Modus entspricht im wesentlichen der Beschreibung eines prozeduralen Grafiksystems, allerdings mit einer zusätzlichen Eigenschaft: Alle Befehle werden nach Ausführung sofort aus dem Arbeitsspeicher entfernt. Im Gegensatz dazu ist ein im Retained Modus betriebenes Grafiksystem in der Lage, sich einmal ausgeführte Befehlssequenzen zu merken. Für ein prozedurales Grafiksystem ergeben sich dadurch die Möglichkeiten, aufeinanderfolgende Befehle zu optimieren oder bei Datenübertragungen im Netzwerk (durch das Speichern lokaler Kopien) eine schnellere Darstellung zu erreichen. Deskriptive Grafiksysteme sind grundsätzlich im Retained Modus, da sie immer abstrakte und vollständig vorhandene Beschreibungen in konkrete Zeichenbefehle umsetzen müssen. Je nachdem, wie gut ein deskriptives auf ein bestimmtes prozedurales Grafiksystem abgestimmt ist, wird die Darstellung einer komplexen Szene dadurch ausgebremst oder beschleunigt.

Prozedurale Grafiksysteme

GKS und GKS-3D

Das Graphische Kernsystem (GKS) und die Erweiterung um 3D-Methoden durch GKS-3D wurde in seiner ursprünglichen Form 1985 und in seiner um die 3D-Fähigkeiten erweiterten Form 1988 als ISO-Standard verabschiedet [7], [8].

Im Gegensatz zur allgemein gehaltenen Beschreibung des vorangegangenen Kapitels kennt das GKS keine Modellkoordinatensysteme. Vielmehr müssen alle darzustellenden Objekte - und zwar von dem Anwendungsprogramm - in einem gemeinsamen Weltkoordinatensystem durch verschiedene Primitive (Punkte, Linien, Flächen und Text) dargestellt werden. Die Abbildung des WC auf die Bildschirmkoordinaten erfolgt dann ähnlich zum vorgestellten Weg mit Hilfe einer Projektionstransformation unter Berücksichtigung verdeckter Kanten. Da sich das GKS bzw. GKS-3D nur auf die Darstellung geometrischer Aspekte einschliesslich farbiger Flächen beschränkt, ist eine Modellierung von erweiterten Techniken, wie Smooth Shading oder Licht, nicht möglich. Darüber hinaus definiert das GKS nicht nur eine 2D- bzw. 3D-API, sondern auch den Umgang mit Eingabe- und Ausgabegeräten sowie ein einheitliches Datenformat für die berechneten Bilder [8].

Als Zielplattform für das ursprüngliche GKS waren handelsübliche PC’s auf DOS-Basis genauso wie UNIX-basierte Workstations geeignet, wobei allerdings mit der Erweiterung um die 3D-Fähigkeiten der Einsatz auf leistungsfähigeren UNIX-Workstations eher in Betracht kam. Das Graphische Kernsystem ist auf modernen Systemen nicht mehr anzutreffen.[7]

PHIGS und PHIGS+

Zeitgleich zur Entwicklung des GKS-3D-Standards wurde in den USA ein anderes Grafiksystem, das Programmer’s Hierarchical Interactive Graphics System (PHIGS) eingeführt und 1992 als ISO-Standard übernommen [8], [10].

Dieses Grafiksystem arbeitet nach dem Prinzip, komplexere Szenen aus verschiedenen, in jeweils eigenen Modellkoordinatensystemen definierten Objekten zusammenzusetzen. Die restliche Funktionalität entspricht weitestgehend dem GKS; die Objekte werden also ebenfalls durch Primitive modelliert, die einzelnen MC’s in ein Weltkoordinatensystem transformiert und anschliessend mittels einer Projektions- und Ansichtstransformation auf dem Bildschirm dargestellt. Mit der Erweiterung PHIGS+ ist es darüber hinaus möglich, den Realismus einer Szene durch Licht, Shading, Depth Cueing sowie Hidden Line und Hidden Surface Removal zu erhöhen [8].

Den Anforderungen an die Hardware konnten die Ende der 80-er Jahre zeitgemässen PC’s nicht gerecht werden, so dass als zugrunde liegendes System nur UNIX-Workstations in Betracht kamen. PHIGS wird -in Verbindung mit PEX - auch noch von aktuellen Systemen unterstützt.[9]

PEXlib und PEX

Die 3D-Grafikbibliothek PEXlib ist ausschliesslich auf UNIX-basierten Systemen mit der grafischen Benutzeroberfläche X-Window anzutreffen und dort auch auf modernen Maschinen weit verbreitet. Die Leistungsfähigkeit dieser 3D-API umfasst die in [3D-Grundlagen] und [3D-Mathematik] genannten Methoden zur Modellbeschreibung und Abbildung (MC, WC, Projektion) genauso wie die Berücksichtigung von Licht, Shading und Texturen. Über die Erweiterung PEX (PHIGS extensions to X) sind PEXlib und auch PHIGS in der Lage, mit anderen Rechnern über ein Netzwerk zusammenzuarbeiten.

Ein entscheidender Nachteil von PEXlib/PEX ist über die Plattformbeschränkung hinaus das Konzept des frei wählbaren Umfangs der unterstützten Funktionen. Damit kann die Lauffähigkeit eines Programms nur auf einem bestimmten System garantiert werden, eine Portierung auf verschiedene UNIX-Systeme ist somit nicht problemlos durchführbar [11].

Direct3D

Die bisher vorgestellten 3D-API’s sind im Laufe der 80-er Jahre entwickelt worden und deshalb auch im wesentlichen auf leistungsfähigere UNIX-Workstations zugeschnitten. Hauptsächlich für den Spielebereich konzipiert und darüber hinaus ausschliesslich auf Microsoft Windows Systemen zu finden ist die DirectX-Schnittstelle mit ihrer speziellen 3D-API Direct3D. Allerdings kann die Leistungsfähigkeit eines modernen PC’s mit einer Direct3D-basierten Anwendung unter Umständen an die einer etwas älteren UNIX-Workstation heranreichen, weshalb auch diese API kurz beschrieben werden soll.

Update 2003: Mittlerweile sind die normalen PC's einer Workstation durchaus gewachsen und Direct3D hat sich als 3D-Schnittstelle unter MS-Systemen durchgesetzt...

Die MS Windows Erweiterung Direct3D ist konzeptionell entsprechend den Ausführungen aus den anderen Abschnitten aufgebaut: Modellierung im MC, Transformation in das WC und in das DC, Realitätsnähe durch Nebel, Transparenz und Texturen [12]. Der entscheidende Nachteil dieser API ist der häufige, zum Teil nicht abwärts kompatible Versionswechsel. Dadurch kann die Konzeption von DirectX/Direct3D den Anforderungen an eine kommerziell bzw. langfristig nutzbare 3D-API nicht genügen.

IRIS GL und OpenGL

Die Grafikbibliothek IRIS GL ist eine von der Firma Silicon Graphics Inc. (SGI) ab 1982 entwickelte 3D-API, deren Funktionsumfang über die bereits vorgestellten Möglichkeiten hinaus geht. Aufgrund der Bindung an das X-Window-System konnte die IRIS GL auch spezifische Funktionen für das Fenstermanagement und Benutzereingaben zur Verfügung stellen. Das damit verbundene Ziel, eine möglichst weit verbreitete grafische Schnittstelle für das X-Window-System zu schaffen, konnte allerdings auch mit dieser Grafikbibliothek nicht erreicht werden.

Ausgehend von der Situation, dass die IRIS GL nicht über den Stand "einer von vielen" herstellergebundenen API’s hinaus kam und ausser UNIX-Systemen auch noch andere Betriebssysteme mit grafischen Oberflächen existierten (OS/2, MacOS, MS DOS/Windows), begann SGI, die Idee eines von Hardware und Betriebssystem unabhängigen Standards, der Open Graphics Library (OpenGL), zu entwickeln. Mit dem in der vorläufigen OpenGL Spezifikation von 1990 skizzierten Funktionsumfang initiierte SGI 1991 eine erste Zusammenkunft namhafter Hersteller von Hard- und Software (DEC, IBM, Intel, Microsoft, SGI), die "OpenGL Architectural Review Board" (ARB) [6].

Als Ergebnis dieser ARB-Zusammenkünfte konnten 1992 die ersten verfügbaren OpenGL-Versionen von DEC und SGI angeboten werden. Die Grundlage bildete die OpenGL Spezifikation 1.0, die vom Funktionsumfang eine reine 3D-API, entsprechend der von IRIS GL, ohne Abhängigkeiten vom Betriebssystem (Fenstermanagement) beschreibt [13].

QuickDraw 3D

Obwohl die 3D-Schnittstelle der Firma Apple nicht auf die Macintosh-Plattform beschränkt ist, reicht weder ihre Verbreitung noch ihr Bekanntheitsgrad an OpenGL, Direct3D oder PEX heran. Prinzipiell liegt die Leistungsfähigkeit dieser API auf einem vergleichbaren Level, kann allerdings aufgrund der Objektorientierung (Vererbung) auch Funktionen der deskriptiven Grafiksysteme wahrnehmen.

Da nur eine grössere (anwendende) Softwarebasis den Bestand einer API sichern kann, ist QuickDraw 3D keine sinnvolle Wahl für Neuentwicklungen [14].

Heidi

Nicht alle Entwickler von Anwendungsprogrammen haben sich auf die Unterstützung der bis jetzt genannten 3D-API’s konzentriert. Ein Beispiel dafür stellt die 3D-API mit dem Namen "Heidi" dar. Diese wurde von der Firma Autodesk für die NT-Version der Programme 3D Studio Max und AutoCAD 13 entwickelt und stellt den dafür benötigten Funktionsumfang bereit. Wie auch Apples QickDraw 3D ist Heidi objektorientiert und stellt insofern nicht nur eine prozedurale API dar. Nach den Angaben von Autodesk soll Heidi in einer späteren Version in der Lage sein, auf eine vorhandene OpenGL-API aufzusetzen [14], [15].

Aufgrund der wenigen, auf diesem Grafiksystem aufbauenden Programme ist Heidi als reine 3D-API mit den Möglichkeiten von OpenGL, Direct3D oder PEX nicht zu vergleichen und somit für die meistens Neuentwicklungen auch nicht sinnvoll.

HP Starbase, Sun XGL

Starbase und XGL sind firmeneigene 3D-API’s von Hewlett Packard bzw. Sun Microsystems GmbH, deren Leistungsfähigkeit auf dem Niveau der anderen modernen API’s liegt.

Deskriptive Grafiksysteme

Die im vorhergehenden Abschnitt vorgestellte OpenGL hat sich durch das konsequente Engagement der Firma SGI zu einem de facto Industriestandard entwickelt. Obwohl fast alle der noch vorzustellenden deskriptiven Grafiksysteme von SGI (zumindest mit-) entwickelt worden sind, stellen diese aufgrund der OpenGL-Basis auch die am weitesten verbreiteten 3D-Modellingwerkzeuge dar.

HOOPS

Das Grafiksystem HOOPS ist als ein objektorientiert arbeitendes Werkzeug zur Vereinfachung von Designerstellung, Entwicklung und Weiterentwicklung für bzw. von Grafikanwendungen konzipiert. Es definiert - zusätzlich zu den üblichen Primitiven - Kreise, Ellipsen und Gitter. HOOPS wird in den Bereichen CAD/CAM/CAE und in der Medizin eingesetzt. Zur Umsetzung der beschriebenen Szenerie kann HOOPS auf die API’s OpenGL, Direct3D, HP Starbase, Sun XGL und PEXlib zurückgreifen. HOOPS ist darüber hinaus auf fast alle Plattformen portiert [16].

Open Inventor

Der Open Inventor ist ebenfalls ein objektorientiert arbeitendes Werkzeug und auch auf mehrere Plattformen portiert. Im Gegensatz zu HOOPS wird nur OpenGL als darunterliegendes Grafiksystem unterstützt, was allerdings auch die Möglichkeit der gezielten Optimierung bietet. Zur abstrakten Beschreibung einer Szene kann man unter anderem auf Quader, Kegel, Zylinder und Kugeln zurückgreifen. Darüber hinaus stellt die ASCII-Version des Inventor-Dateiformats eine einfache Möglichkeit zur Verfügung, auch ohne Zugriff auf einen Modeller selbst komplexere Szenen aufzubauen [17].

VRML

Die Virtual Reality Modeling Language stellt kein eigenständig arbeitendes Programm dar, sondern definiert ein Dateiformat (*.wrl) für das World Wide Web (WWW), mit dem sich dreidimensionale Szenen in einem Browser darstellen lassen. Browser sind dabei eigenständige Programme oder auch nur Programmerweiterungen, mit denen sich Informationen aus dem WWW abrufen lassen. 1997 wurde VRML als ISO-Standard VRML97 festgeschrieben [18].

Das Dateiformat von VRML 1.0 entsprach im wesentlichen der ASCII-Version des Open Inventor-Dateiformats. In Bezug auf den Abstraktionsgrad, das heisst der Beschreibung geometrischer Körper durch bestimmte Schlüsselbegriffe, trifft das auch auf VRML97 zu [19], [20].

Da VRML97 nur ein standardisiertes Dateiformat zur Beschreibung dreidimensionaler Szenen beschreibt, muss ein entsprechender Browser nicht plattformunabhängig sein. Dadurch steht es jedem Anbieter eines solchen Programmes frei, ob und welche prozeduralen 3D-Grafiksysteme er unterstützt.

IRIS Performer

Der IRIS Performer ist hochspezialisiertes Optimierungswerkzeug von SGI, welches auf IRIS GL oder OpenGL aufsetzt. Obwohl auch der Performer einen hohen Abstraktionsgrad durch geometrische Objekte (z.B.: Fläche, Quader, Zylinder) bietet, unterscheidet er sich wesentlich von deskriptiven Systemen wie dem Open Inventor.

Durch die konsequente Optimierung auf SGI-Grafikhardware ist dieses Werkzeug in der Lage, auch extrem leistungsfähige Architekturen, unter anderem das Grafiksubsystem InfiniteReality, optimal auszunutzen [21]. Dem Leistungsgewinn steht allerdings die Plattformabhängigkeit gegenüber.

OpenGL Optimizer

Der OpenGL Optimizer ist eine neue (1997), von SGI entwickelte API für die effektive Visualisierung umfangreicher Datenmengen. Das Konzept des Optimizers beruht darauf, eine Zwischenschicht zwischen einer CAD/CAE Anwendung und OpenGL zu bilden. Wahlweise werden die Daten des CAD-Programms so verändert, dass das aktuelle Ziel - hohe Abbildungsqualität oder Darstellungsgeschwindigkeit - am effektivsten erreicht werden kann. Darüber hinaus können die Geometriedaten auch noch durch erweiterte Möglichkeiten, wie zum Beispiel Materialeigenschaften oder Texturen, ergänzt werden.

SGI will durch die Verfügbarkeit auf allen Plattformen und geringen Anschaffungskosten eine ähnliche Akzeptanz wie der von OpenGL selbst erreichen [22].

Fahrenheit

Das Projekt Fahrenheit zielt auf die Entwicklung eines neuen Grafikstandards hin, der die zugrunde liegenden Techniken des Open Inventors (Grafikdatenbank) mit den Optimierungsalgorithmen des OpenGL Optimizers zusammenfassen soll. SGI, als Hersteller des Open Inventors und des OpenGL Optimizers, verzichtete zugunsten einer schnellen Entwicklung auf die Einbindung der ARB-Mitglieder und konnte statt dessen Microsoft für eine Mitarbeit gewinnen [23], [24].

Fahrenheit umschreibt ein dreischichtiges System :

• Die unterste Schicht ist die LLAPI (Low Level API), welche der Ebene OpenGL bzw. DirextX/Direct3D im Immediate Modus entspricht,
• die mittlere Schicht ist die SGAPI (Scene Graph API) als Ersatz der gleichnamigen Grafikdatenbank des Open Inventors bzw. von DirextX/Direct3D im Retained Modus,
• die obere Schicht ist die LMVAPI (Large Model Visualisation API), welche auf dem OpenGL Optimizer aufbauen soll.

SGI ist hinsichtlich der Ablösung von DirectX/Direct3D durch OpenGL bzw. Fahrenheit zwar etwas zu optimistisch, prinzipiell bietet eine Kooperation zwischen den Entwicklern der den PC-Markt beherrschenden MS Windows Oberfläche und dem Hersteller von marktführenden Grafikworkstations aber einen erfolgversprechenden Ansatz.

Hardware zur 3D-Visualisierung

Der letzte Abschnitt Deskriptive Grafiksysteme hat gezeigt, dass die 3D-API OpenGL zumindest durch Software in grossem Umfang unterstützt wird. Deshalb werden die folgenden Betrachtungen die Möglichkeiten von OpenGL besonders berücksichtigen. Soweit machbar, werden die Aussagen allerdings allgemein gehalten.

Die Grafik-Pipeline

Um eine Ausgabe einer Grafik auf Computersystemen realisieren zu können, ist die Abarbeitung bestimmter Zwischenschritte notwendig [3]. Im folgenden werden für die einzelnen Stufen dieser Grafik-Pipeline die in [6] vorgestellten Bezeichnungen verwendet. Die Stufen im einzelnen sind:

Generation (G):
Erzeugen der darzustellenden Informationen durch die Applikation, zum Beispiel durch das Einlesen von Punktkoordinaten aus einer Datenbank.

Umwandlung (T):
Darstellung der Informationen durch die API-spezifischen Befehle. Für die OpenGL heisst das, die Koordinaten eines Punktes durch den Befehl glVertex3f(x, y, z) anzugeben.

Transformation (X):
Dieser Schritt umfasst die in Kapitel 2 genannten Methoden zur Ausführung der durch den Schritt T vorgegebenen Anweisungen. Das sind beispielsweise die Objekttransformation MC WC, die Berechnung der Reflexion, Farben und Texturkoordinaten, das Clipping und die Projektion.

Rasterisation (R):
Die Rasterisation wertet alle bis jetzt berechneten Informationen aus und schreibt die endgültigen Farbwerte für jeden Bildpunkt in den Framebuffer. Mit Framebuffer wird ein Speicherbereich - meist auf der Grafikkarte - bezeichnet, der das aktuell darzustellende Bild enthält.

Darstellung (D):
Mit der Durchführung des letzten Schrittes der Grafik-Pipeline wird der Inhalt des Framebuffers ausgelesen und auf dem Ausgabegerät, üblicherweise einem Monitor, dargestellt.

Ein prozedurales Grafiksystem wie die OpenGL umfasst die Schritte X, R und D, während deskriptive Grafiksysteme der Stufe T oder auch den Stufen G und T entsprechen.

System-Klassifizierung

Eine OpenGL-Implementierung muss alle in der Spezifikation genannten Funktionen unterstützen. Es wird allerdings keine Aussage darüber gemacht, welche dieser Funktionen durch den Prozessor ("in Software") und welche durch die Grafikhardware ("in Hardware") des genutzten Computers ausgeführt werden.

Verfügt ein Computersystem über keine Beschleunigung der 2D- bzw. 3D- Grafikausgabe, so wird ein solches System im folgenden als GTXR-D Architektur bezeichnet [25]. D.h. die Schritte GTXR werden durch den Prozessor (CPU) bearbeitet und ausschliesslich die endgültige Darstellung D durch die Grafikkarte verwirklicht. Die PC-Architekturen der 90er Jahre waren allerdings oft mit 2D-Beschleunigern ausgestattet, d.h. die Grafikkarte übernimmt zumindest zum Teil den Schritt der Rasterisierung (Linien zeichnen und Flächen ausfüllen). Das entspricht damit einer GTX-RD Architektur.

Ist die Grafikkarte darüber hinaus in der Lage, einen Teil der Transformationsstufe zu übernehmen, liegt im Sinne der Grafik-Pipeline eine GT-XRD Architektur vor. In diesen Bereich fallen 3D-Beschleuniger aus dem PC-Bereich für unter 100 EURO genauso wie High-End-Systeme für fünf- oder sechsstellige Summen. Diese generalisierte Einordnung muss deshalb im nächsten Abschnitt noch genauer unterteilt werden.

Es existieren auch Rechner mit einem G-TXRD Aufbau, deren Anwendungsgebiet allerdings sehr spezialisiert ist. Ein Beispiel sind die ESIG-4500 Maschinen der Firma Evans & Sutherland, die für komplexe Fahr- und Flugsimulationen genutzt werden [6], [26].

Ausbaustufen der Grafikhardware

Im folgenden soll anhand einiger Beispiele das Spektrum einer GT-XRD Architektur umrissen werden. Noch nicht vorgestellte Techniken werden näher erläutert.

Speicher

Für die endgültige Abbildung auf dem Monitor wird für jeden Bildpunkt ein Farbwert in dem Color-Buffer gespeichert. Am Beispiel einer für professionelle Arbeitsplätze üblichen Bildschirmauflösung von 1280x1024 (Bildpunkten = Pixel in der Form Breite x Höhe) und den üblichen Farbtiefen von 8, 16, 24 oder 32 Bit (diese entsprechen den gleichzeitig darstellbaren Farbwerten 2ⁿ, d.h. 8 Bit = 2⁸ = 256) muss die Grafikkarte deshalb auf einen ausreichend grossen Speicher zurückgreifen können (Tabelle 1).

Die erste Anforderung an ein GT-XRD System besteht in der zusätzlichen Verfügbarkeit eines Z-Buffers. In diesem Speicherbereich soll die Tiefeninformation des aktuellen Bildpunktes möglichst exakt gespeichert werden. Um einen möglichst präzisen Vergleich von einzelnen Bildpunkten zu ermöglichen, wird hierfür eine Auflösung von mindestens 16 Bit, bei professionellen Systemen überwiegend 32 Bit gewählt. Damit ergibt sich für 1280x1024 Bildpunkte ein zusätzlicher Speicherbedarf von 5 MB (Tabelle).

Mit 5 MB je für den Color-Buffer, den Z-Buffer und die gleiche Menge nochmal (für die übliche Doppel-Pufferung sowie ein paar Reserven für den Stencil-Buffer erreicht man schon mehr als 20 MB Bedarf, ohne dass bis hierhin Texturen berücksichtigt wurden. Damit werden die grossen Grafikspeicher von 64 MB und mehr schon eher nachvollziehbar...
Zum Zeitpunkt der Originalversion dieses Abschnitts waren 8 MB noch state of the art...

Die nächste Speicheranforderung ergibt sich aus der Verwendung eines Stencil-Buffers (einer Art Schablone). Soll beispielsweise eine Fahrbahnmarkierung gezeichnet werden, kann die Genauigkeit des Z-Buffers nicht mehr genügen: Der weisse Streifen liegt ja exakt auf der gleichen Höhe wie die Fahrbahnoberfläche. Reserviert man aber für jeden Bildpunkt noch ein weiteres Bit (Wert 0 oder 1), kann eine zusätzliche Abfrage realisiert werden: Zeichne den neuen Farbwert nur dann, wenn das Stencil-Bit gleich Null ist. Beginnt man zudem mit dem Zeichnen der Fahrbahnmarkierung und setzt die entsprechenden Stencil-Bits zu Eins, so kann für diesen Bildbereich der aufwendige Depth-Test entfallen. Übliche Stencil-Buffer haben eine Tiefe von 1 bis 8 Bit je Pixel, so dass nach Tabelle 4.1 bis zu 1,25 MB weiterer Speicher veranschlagt werden muss.

Verwendet man eine aus geometrischen Objekten zusammengesetzte Szene zur Nachbildung realer Gegebenheiten, so ist das Ergebnis aufgrund der exakten Körperkanten oftmals recht wirklichkeitsfremd. Zur Verbesserung des Realitätsempfindens greift man deshalb auf das Antialiasing, Depth Cueing oder Motion Blur zurück (Motion Blur bezeichnet das mehrfache, immer leicht zueinander versetzte Zeichnen eines Objektes zur Erzeugung einer Bewegungsunschärfe). Allen drei Verfahren gemeinsam ist die Farbwertmodifizierung bestimmter Bildpunkte, die durch Rechenoperationen (z.B. Addition, Multiplikation) realisiert wird. Diese Rechenoperationen werden im Accumulation-Buffer ausgeführt, der zur Sicherstellung exakter Ergebnisse üblicherweise die doppelte Tiefe des Color-Buffers besitzt.

Ebenfalls für die Computeranimation benötigt werden die Techniken Double Buffering und Stereo Buffering: Das Zeichnen einer komplexen Szene ist nicht "auf einen Schlag" möglich, sondern beansprucht eine gewisse Zeit. Wird das Zeichen unmittelbar im Front-Buffer ausgeführt, so kann der Betrachter unter Umständen den schrittweisen Aufbau der Szene verfolgen. Das wäre für eine Simulation nicht tragbar und ist für eine flüssige Animation zumindest nicht erwünscht. Deshalb definiert man einen zusätzlichen Back-Buffer, in welchem die aktuelle Szene gerendert wird. Diesen erhält man meistens durch Teilen des Framebuffers in zwei Bereiche gleicher Farbtiefe (ein 24 Bit Buffer in zwei 12 Bit Buffer). Ist die komplette Szene berechnet, wird einfach der Front- gegen den Back-Buffer ausgetauscht. Eine annähernd perfekte Illusion lässt sich erreichen, wenn die Szene zudem noch aus zwei verschiedenen Blickwinkeln, dem rechten bzw. linken Auge entsprechend, berechnet wird. Für jedes Auge existiert dann ein eigener Front- und Back-Buffer. Während das Double Buffering fast immer eingesetzt wird, stellt das Stereo Buffering eine selten genutzte Technik dar.

Die Grösse des Textur-Speichers hängt nicht unmittelbar von der gewünschten Auflösung und Farbtiefe ab. In diesem Speicherbereich sollen alle, für die Darstellung der aktuellen Szene benötigten Texturen (also Bilder) abgelegt werden können. Je nach Einsatzzweck sind dafür Grössen von 2 MB bis hin zu 64 MB üblich.

Update 2003: Bei Speichergrössen von 128 und teilweise sogar schon 256 MB ist natürlich der Anteil des Textur-Speichers noch grösser.

Spezialisierte Prozessoren

Wie bereits angesprochen, ist die einfachste Art der Hardwarebeschleunigung durch die 2D-Beschleuniger in GTX-RD Systemen gegeben.

Bild 1: Aufteilung eines Dreiecks in waagerechte Linien (Spans), Quelle: [6]

Die vom Chip zur Verfügung gestellten Funktionen können zum Beispiel eine Span-Engine zur Zerlegung von Dreiecken in - den Monitorzeilen entsprechende - waagerechte Linien und/oder Iterationsroutinen für den Farbverlauf sein (Bilder 1 und 2).

Bild 2: Span-Iteration für Farbverlauf und Tiefe (Extrudieren), Quelle: [6]

Lassen sich die vom Grafikchip zur Verfügung gestellten Iterationmechanismen auch für andere Berechnungen verwenden, entspricht das System bereits einer einfachen GT-XRD Architektur. In Abhängigkeit von der Leistungsfähigkeit des Grafikchips ist es möglich, dass dieser selbständig noch weitere Berechnungen durchführen kann, ohne dass ein zusätzlicher Eingriff durch das steuernde Grafiksystem notwendig wird. Verbreitet ist die Unterstützung unter anderem für die Berechnung von Nebel, Reflexion (specular highlights) und Transparenz [27]. Ebenfalls möglich ist es, die Verwaltung der im vorangegangenen Abschnitt vorgestellten Buffer durch spezielle Grafikchips durchzuführen (Vergleichsoperationen, direktes Verändern der Inhalte ohne Zugriff auf die CPU) oder die Berechnung der Transformationen auszulagern.

Als grundsätzliche Ausführungsvarianten für derartige Grafikchips lassen sich zwei Philosophien unterscheiden: Das "Verdrahten" der auszuführenden Zwischenschritte in der Hardware und das Programmieren über einen Mikrocode. Vorteil der ersten Ausführung ist eine höhere Geschwindigkeit, Nachteil die nicht vorhandene Flexibilität. Aufgrund der eingeschränkten Wiederverwendbarkeit solcher Chips sind diese zudem noch teurer. Lohnend ist der Einsatz in der generell gleich ablaufenden Rasterisationsstufe, also als Span-Engine. Für die Berechnung der Transformationen ist ein programmierbarer Chip die bessere Wahl [6].

Eine weitere Option bei der Gestaltung der Hardware besteht im Hintereinander - und/oder Parallelschalten (Pipelining, Parallelismen) mehrerer Prozessoren. Eine gezielt eingesetzte Kombination beider Verfahren ermöglicht eine - allerdings wesentlich von den abzuarbeitenden Befehlen abhängige - Steigerung der Geschwindigkeit. Für den Fall, dass die aufrufende API geeignete Befehlssequenzen generieren kann (IRIS Performer), lassen sich auch mehrere der programmierbaren Chips durch den gleichen Microcode-Speicher steuern. Diese als SIMD (Single Instruction Stream for Multiple Data Streams) bezeichneten Ausführungen ermöglichen gegenüber eigenständig arbeitenden MIMD Prozessoren (Multiple Instruction Stream for Multiple Data Streams) eine kostengünstigere Herstellung.

Performance der verfügbaren Hardware

Um eine Aussage über die Leistungsfähigkeit der Grafik-Pipeline treffen zu können, sollen zuerst einmal die dafür benötigten Massstäbe und Messverfahren vorgestellt werden. Der darauffolgende Abschnitt gibt anhand einiger Beispiele eine Übersicht über den verfügbaren Leistungsrahmen.

Definierbarkeit der Grafikleistung

Ein wesentlicher Massstab für die Grafikleistung ist mit Sicherheit die Geschwindigkeit. Für den Nutzer einer 3D-API heisst das: Welche Zeit benötigt der Rechner, um die ihm gestellte Aufgabe zu lösen? Dieser Ansatz ist für die Beurteilung der Leistungsfähigkeit einer Hardware / Software-Kombination allerdings nicht genau genug. Vielmehr sollten die Massstäbe so gewählt werden, dass man zumindest die einzelnen Stufen der Grafik-Pipeline und nach Möglichkeit auch noch die Ausbaustufe eines GT-XRD Systems erfassen kann [6].

Die Rasterisationsstufe beschreibt das Auffüllen des Framebuffers. Deren Leistungsfähigkeit lässt sich deshalb an der Füllrate, also der erreichbaren Frequenz für das Setzen aller Pixel des Framebuffers festmachen. Die Leistungsgrenze (engl. Fill Limit) wird in den erreichbaren Pixel je Sekunde (Pixel/s) angegeben.

Das Fill Limit hängt wesentlich von den verwendeten Methoden zur realistischeren Darstellung ab: Durch das Nutzen des Z-Buffers muss für jeden Pixel eine logische Abfrage (zeichnen: Ja/Nein) erfolgen. Ausserdem lässt sich zwar ein Farbverlauf durch die Grafikhardware berechnen, bei der Verwendung von Texturen wird allerdings oft auf die CPU zurückgegriffen. Auch eine sehr detaillierte Darstellung der Szene kann ein Fill Limit verursachen, da die Span-Engine ständig nur kurze Linien berechnet, insgesamt also wesentlich mehr Rechenoperationen ausführen muss.

Die Transformationsstufe umfasst sämtliche Modifikation an den Primitiven. Vor der Übergabe der Primitive an die Rasterisationsstufe werden diese noch in ein der Span-Engine verständliches Format (z.B. Dreiecke) gebracht. Deshalb wird die erreichbare Leistung (engl. Transformation Limit) für diesen Bereich meist in Polygonen je Sekunde (Polygone/s) angegeben.

Einfluss auf die Zahl der in einer Sekunde darstellbaren Polygone haben zum Beispiel alle für die geometrische Transformationen, das Berücksichtigen von Lichtquellen oder das Clipping notwendigen Berechnungen.

Gemäss diesen Beispielen lassen sich bei einem auftretendem Fill oder Transformation Limit zwar gezielt Gegenmassnahmen treffen, allerdings müssen diese auch schon bei der Erzeugung der Grafikbefehle durch die Anwendung ansetzen. Ebenfalls möglich ist es, dass die Leistungsgrenze gar nicht durch die Grafikhardware, sondern durch die steuernde Anwendung verursacht wird. Diese, als Host Limit bezeichnete Leistungsgrenze kann während der Umwandlungsstufe auftreten, wenn beispielsweise für die Darstellung eines Crash-Tests zuerst eine aufwendige Berechnung der Koordinaten notwendig ist.

Allgemein üblich ist die Beurteilung der Leistungsfähigkeit durch Benchmarks. Das sind Programme, welche die benötigte Zeit für die Ausführung bestimmter Befehlssequenzen messen. Der Anwender erhält als Ergebnis eines Benchmarktests entweder einen speziell definierten Wert (z.B.: XStones) oder die Anzahl der berechneten Bilder je Sekunde (Frames/s). Diese Angaben lassen allerdings kaum einen Schluss auf das zugrunde liegende Limit zu, weshalb ein herkömmlicher Benchmark nur einen groben Anhalt für die Eignung eines Systems in Bezug auf einen bestimmten Einsatzzweck bietet. Sind die bewerteten Funktionen eines Benchmarks bekannt, ermöglicht die Angabe der damit erreichbaren Leistung aber eine gezielte Auswahl des Grafiksystems (als Hard- und Softwarekombination). Eine Übersicht über verbreitete 3D-Benchmarks liefert [28].

Realisierung durch spezialisierte 3D-Hardware

Wie bereits angesprochen, bieten preisgünstige, auf den Spielemarkt ausgerichtete 3D-Grafikkarten auf den ersten Blick einen Leistungsumfang, der vergleichbar mit wesentlich teureren Geräten aus dem professionellen Workstation-Bereich ist. Bei etwas näherer Betrachtung und Berücksichtigung der jetzt angesprochenen Möglichkeiten einer 3D-API wie OpenGL lässt sich dieser Vergleich aber nicht halten.

Für eine echte 3D-Beschleunigung müssen zwei Bedingungen gegeben sein: Das Grafiksystem muss auf sehr schnellen und darüber hinaus noch ausreichenden Speicher zugreifen können und es sollten möglichst viele der 3D-typischen Berechnungen durch speziell dafür konzipierte Hardware ausgeführt werden.

In dem Preisrahmen unter 1.000,- DM sind zur Zeit viele Grafikkarten mit "3D-Beschleunigung" zu finden. Fast allen gemeinsam ist dabei die Ausbaugrenze des Grafikspeichers von 8 MB. Obwohl ausdrücklich auch als OpenGL-fähig eingestuft, ermöglicht eine derartige Ausstattung kaum eine ausreichende Unterstützung der GT-XRD Möglichkeiten (1280x1024 mit 32 Bit Farbtiefe und 16 Bit Z-Buffer benötigt schon 7,5 MB). Verringert man die Ansprüche allerdings (800x600, 16 Bit jeweils für Double Buffer und Z-Buffer), so lässt diese Speichergrösse auch noch genügend Platz für Texturen. Die genutzten Grafikprozessoren werden meist mit beeindruckenden Daten (3Dfx Voodoo: 350.000 Polygone/s und 45 Mio. Pixel/s, [5]) angegeben, die aber aufgrund fehlender Zusatzangaben (z.B. Farbfüllung mit Flat oder Gouraud Shading) keine genügende Grundlage für eine Beurteilung bieten.

Professionellere Systeme verfügen dagegen über einen ausreichend grossen Speicherausbau: Mindestens 16 MB für Double Buffer, Z-Buffer und Stencil-Buffer, zusätzlich einen ähnlich grossen Texturspeicher sowie einen als Accumulation-Buffer nutzbaren Hauptspeicher. Ausserdem ermöglichen mehrere Grafikprozessoren mit speziellen Aufgabenbereichen (Rasterisation, Transformation) eine wesentliche Entlastung der CPU und damit eine erhöhte Leistungsfähigkeit des Gesamtsystems (akkurate Berechnung der Fahrzeugbewegung oder Steuerung anderer Fahrzeuge). Auf anerkannten Benchmarks aufbauende Leistungsangaben verschiedener Systeme bietet zum Beispiel [30].

Update 2003: Mittlerweile ist die Unterscheidung von Spiele- und Profi-Karten anhand nackter Zahlen nicht mehr möglich. Der Unterschied liegt jetzt eher in den Tiefen des Designs verborgen: Bei Spiele-Karten zählt Geschwindigkeit und Optik, bei Profi-Karten dagegen die exakte Darstellung, z.B. von feinen Linien bei CAD-Programmen (was liegt vor, was hinten, wo genau schneiden sich die Kanten). Das kann sogar mit ähnlichen Chips realisiert werden, die per Micro-Code feingetunt werden (was meines Wissens bei ATI der Fall sein dürfte).
Die Preise für die "besseren" Systeme liegen übrigens immer noch um die 500 EUR...

Im High-End-Bereich anzutreffen sind auf sehr hohe Grafikleistung ausgerichtete Systeme. Die dafür notwendige Hardware wird dafür oftmals in einem eigenen Grafiksubsystem mit skalierbarem Aufbau zusammengefasst. Ausserdem bieten spezielle Busarchitekturen (Verbindungen zwischen CPU, Hauptspeicher und Grafikkarte) eine wesentlich höhere Bandbreite, können also entscheidend mehr Informationen (bezogen auf einen Zeitraum) als herkömmliche Systeme übertragen. Dadurch kann zum Beispiel ein schneller Hauptspeicher die Aufgaben des Grafikspeichers übernehmen oder eine vollständige Entkopplung der Grafikausgabe (G-TXRD) erfolgen. Bei den leistungsfähigsten Systemen stellen getrennt voneinander arbeitender Grafikprozessoren für jeweils wenige Hundert Bildpunkte eine hohe Systemgeschwindigkeit sicher [31], [32].

Für die Anwendung im Bereich Virtual-Reality, echtzeitgesteuerter 3D-Animation oder für Fahr- und Flugsimulatoren reicht die Beschränkung auf ein schnelles Grafiksystem nicht mehr aus, sondern es muss auf ein ausreichend schnelles Gesamtsystem zurückgegriffen werden können. Speziell hierfür konzipiert ist beispielsweise das von SGI hergestellte Onyx 2-System mit der InfiniteReality (Grafiksubsystem). Damit unter allen Umständen ein ununterbrochener Simulationslauf sichergestellt werden kann, lässt sich dieses System mit bis zu 16 CPU’s, 8 GB Hauptspeicher, speziellen Grafikprozessoren, einem Framebuffer von 320 MB und 64 MB Texturspeicher aufrüsten. Zur Verhinderung einer Überlastung (Fill oder Transformation Limit) stehen zudem Kontrollstrukturen zur Verfügung, die auf verschiedenen Wegen (IRIS Performer, Mechanismen der InfiniteReality) in die Grafik-Pipeline eingreifen können [33]. Allerdings muss eine derartige Leistungsfähigkeit auch mit sehr hohen Investitionskosten erkauft werden.

Bild 3: automatischer Eingriff in die Grafik-Pipeline, Quelle: [33]

Bild 3 zeigt die Eingriffsmöglichkeit der InfiniteReality in die Grafik-Pipeline: Grundsätzlich wird jedem Bildschirm ein bestimmter Bereich des Framebuffers zugewiesen, in den die Ausgabe der berechneten Szene erfolgt (vorstellbar ist eine Aufteilung zum Beispiel in Frontscheibe, Seitenscheiben und einem Aussenspiegel). Erreicht die InfiniteReality ihre Leistungsgrenze (Fill Limit), so wird automatisch die Auflösung in dem entsprechendem Abschnitt des Framebuffers reduziert und gleichzeitig eine gleichbleibende Bildgrösse durch Interpolation sichergestellt.

Update 2003: SGI baut Supercomputer mit ATI-Grafikkarten (Heise-Newsticker vom 14.07.2003)
"SGI bestückt schon seine Grafik-Workstations mit PC-Grafikchips und ersetzt jetzt auch in seiner neuen Highend-Linie Onyx4 UltimateVision die betagte Infinite-Reality-Grafik durch eingekaufte Technik. Der Markt für Highend-Visualisierung ist zu begrenzt, sodass sich für SGI die inzwischen mehrere 100 Millionen US-Dollar teure Entwicklung eigener Grafikprozessoren nicht mehr lohnt. Auch die Leistungsfähigkeit von PC-Grafik ist mittlerweile den Eigenentwicklungen weit überlegen. Während InfiniteReality4 lediglich 3 Millionen Polygone/s verarbeitet, erreicht ein ATI-Grafikchip rund 10 Millionen Polygone/s (immediate mode) oder gar 75 Millionen Polygone/s bei lokal gespeicherter Geometrie (display list mode). Zudem ist die Technik programmierbarer Funktionseinheiten -- so genannter Vertex- und Fragment-Shader -- für eine unbegrenzte Anzahl grafischer Effekte bei PC-Grafikchips am weitesten fortgeschritten. Dass SGI sich nicht für Nvidia-Grafikchips entschied, erklärt sich wohl mit der frühen Verfügbarkeit des Radeon 9700 und dessen besserer Antialiasing-Qualität, die für großflächige Projektionen wichtig ist."