Dank

An dieser Stelle sei mir ein Dank an all jene Menschen erlaubt, die mir dieses Review der Vivid ermöglichten. Zuerst möchte ich unbedingt David Harold, PR Manager der Firma Imagination Technologies, nennen, durch seine Unterstützung durch die Auslieferung einer Vivid! ist diese Arbeit erst möglich geworden. Genauso muß aber unbedingt Matt Crawford, ebenfalls ImgTec, erwähnt werden. Nur durch die sehr gute Zusammenarbeit mit ihm wurden alle Probleme mit Treibern oder dem BIOS oder auch besonderen Spielen immer wieder in wenigen Stunden gelöst! Ein ganz großer Dank geht aber auch an Lukas Jaskiewicz, der sich spontan entschloß mir bei den Benchmarks und auch sonst bei allen Problemen zu helfen. Ohne ihn wäre das Review sicher nie so gut und umfangreich geworden.

Vorgeschichte + Technik

Seit der Entwicklung der Computergrafik und der Darstellung dreidimensionaler Objekte mit Hilfe von Computern hat sich eigentlich nicht viel verändert. Alle Firmen die 3D Hardware produzieren verfolgen mit ihren Produkten immer den gleichen Weg, die sogenannte Grafikpipeline.

Alle Objekte werden über ihre Oberflächen in Polygone (Dreiecke) zerlegt, deren Position im Raum über entsprechende Matrixoperationen berechnet werden. Anschließend wird die Beleuchtung für die Dreiecke berechnet und die Dreiecke mit einer bzw. mehreren Texturen belegt, die natürlich auch noch untereinander in Wechselwirkung treten können (z.B. Durchsichtigkeit u.a.). Diese Dreiecke werden so wie sie von der CPU kommen auf dem Bildschirm dargestellt. Da nicht bekannt ist, ob das Dreieck, das gerade Ausgegeben werden soll vor oder nach anderen schon vorhandenen Dreiecken liegt, wird für jeden Bildschirmpixel ein Tiefenpuffer, der sogenannte Z-Buffer, eingerichtet, über diesen Tiefenpuffer kann jetzt entschieden werden, ob der entsprechende Pixel des Dreiecks überhaupt gezeichnet wird oder ob er vielleicht durch andere Dreiecke, die schon in der Szene sind, verdeckt wird. In modernen Spielen ist es nun oft so, dass sehr viele Objekte ständig durch andere verdeckt werden, wobei dann immer alle diese Objekte völlig umsonst berechnet werden.

Man stelle sich zum Beispiel vor, man steht in einer Stadt auf dem Marktplatz und schaut auf ein Haus auf einer Marktseite. Dann sehen wir natürlich nur dieses Haus, wissen aber, dass hinter dem Haus viele weitere Häuser stehen. Wenn wird diese Szene mit Hilfe eines Computers dreidimensional Darstellen wollen, geben wir natürlich die Koordinaten allen Häuser ein, denn es soll ja dem Anwender des Programmes später überlassen werden, welche Ansicht er wählt. Die virtuelle Stadtführung kann beginnen! Für den Rechner, und damit die Grafikhardware beginnt jetzt ein fast unlösbares Problem. Wie oben beschrieben wird die gesamte 3D Szene durch den Computer berechnet und dargestellt, d. h. auch alle Häuser hinter den Häusern auf dem Marktplatz! Hoffen wir, dass es eine Kleinstadt ist! Es werden also hunderte von Objekten gezeichnet, die alle gar nicht zu sehen sind!
Daran scheitert momentan jede Grafikhardware! Moment fast jede!

Hier beginnt die Geschichte einer "kleinen" englischen Firma mit Namen Imagination Technologies (Videologic). Dieses Unternehmen hatte die Idee, bei der Computergrafik etwas ganz anders zu machen. Wenn man die Grafikpipeline so verändern könnte, dass vor dem Zeichnen bekannt wäre welche Teile sichtbar sind, dann könnte man sehr viel Rechenzeit und Arbeit für die Hardware sparen. Die Idee selbst ist zwar nicht von Videologic, aber mit der PowerVR Technologie sind sie das erste Unternehmen, das eine marktreife Technologie entwickelte.
Wie funktioniert jetzt eigentlich diese Technologie?
Man sollte vielleicht mit dem Begriff Displaylist Renderer anfangen. Die Grundidee besteht darin, alle Dreiecke der Szene in einer Liste zu sammeln. Wenn man alle Dreiecke hat, ist es natürlich leicht möglich diese so zu sortieren, das bestimmt wird welches Dreieck am weitesten vorn liegt. Da nun aber eine Szene in der Regel doch aus mehreren tausend Dreiecken, wenn nicht gar hunderttausend Dreiecken, besteht ist dies auch schon wieder recht zeitaufwendig.

Deshalb die zweite Idee! Wenn ich sowieso alle Dreiecke kenne, kann ich doch auch den Bildschirm in kleinere Teile aufteilen, sogenannte Tiles, und bestimme für die Displayliste nur noch welche Dreiecke in welchen Tiles liegen. Da ein Dreieck meistens doch nicht den ganzen Bildschirm bedeckt, ist die Liste für so ein Tile natürlich (in der Regel) sehr viel kleiner. Diese Tiles bestehen zum Beispiel aus 32x16 Pixel und sind damit so klein, dass alle Daten die für so ein Tile gebraucht werden ständig in einem Cache Speicher des Grafikchips gehalten werden können.

Wenn jetzt für ein Tile bekannt ist, welche Dreiecke überhaupt in diesem liegen, beginnt der eigentliche Prozess zur Bestimmung der Farbwerte der Pixel dieses Tiles. Durch Ray Casting wird für jeden Pixel das Dreieck bestimmt, das am weitesten vorn liegt und den Farbwert bestimmt. Ray Casting für ein Pixel ist natürlich recht schnell erledigt, aber für hunderttausende? Das ist kein Problem, da ein Tile ja einen in sich abgeschlossenen Teil des Bildschirms darstellt, ist es leicht möglich dieses Ray Casting massiv parallel durchzuführen. Wir wissen nicht genau wie viele Pixel parallel berechnet werden, aber ImgTec sagt, das dieser Algorithmus so schnell ist, dass er eigentlich nie ein Problem für die Geschwindigkeit des Chips darstellt. Wenn anschließend im Tile für alle Pixel das jeweils farbbestimmende Dreieck gefunden wurde wird mit diesen Pixeln die Renderpipelin fortgesetzt. Hier kommt jetzt der dritte Begriff ins Spiel, das deferred Rendering. Das hat zur Folge, dass wirklich nur die Pixel der einzelnen Dreiecke gerendert werden, die auch sichtbar sind. Wenn also ein Dreieck vollständig von anderen verdeckt wird, wird es auch niemals gerendert werden. Diese Technologie vermeidet also jeglichen Overdraw.
Hier entstehen drei wesentlich Vorteile:

1. Es werden wirklich nur die Dreiecke bearbeitet, die auch sichtbar sind.
2. Auf den Z-Buffer kann verzichtet werden, da dieser Test im Chip erfolgt.
3. Dadurch das sehr viel der Rechenarbeit komplett im Grafikchip ohne Verwendung externer Speicher durchgeführt wird, ist es möglich sehr viel Datentransport vom bzw. zum Speicher einzusparen.

Klingt einfach, nicht? Ist aber natürlich gar nicht so einfach, denn sonst hätte es schon jeder getan! ImgTec hat für die Probleme dieser Technologie eine Lösung gefunden, deren Ergebnisse ihre Grafikchips sind!

Mit dem PowerVR1 (PCX1) brachten sie 1996 einen eigentlich recht erfolgreichen Chip auf den Mark, der durch die Grafikkarten Apocalypse 3dx und Matrox m3d bekannt geworden ist. Der Nachfolger dieses Chips, der PowerVR2, wurde wenigstens in der Spielekonsole Dreamcast seit 1998 eingesetzt. Ich erinnere mich noch gut an die Aufregung, die dieser Chip auch im PC Bereich verursachte. Leider kam er erst im Herbst 1999 in der Neon250 auf den Markt.

Vor uns liegt jetzt die dritte Generation, die Serie3 bzw. KYRO. Der KYRO ist eine Serie von 3D Chips, die in Zusammenarbeit von ImgTec mit STMicroelectronics entstehen. Die hier getestete Karte mit Namen Vivid! von VDO basiert auf dem ersten Marktreifen KYRO Chip.