Ein erster Blick auf die G80-Technologie

28. Dezember 2006 / von aths / Seite 4 von 5

   Was nützt uns Direct3D10?

"Sollte man nicht erst einmal Direct3D9 ausnutzen, bevor man Direct3D10 nutzt?" ... "Hat der G80 überhaupt die Leistung für Direct3D10-Effekte?" ... Solche Fragen gehen noch vom Grafikeffekt-Denken aus Prä-Direct3D8-Zeiten aus.

In Direct3D10 stehen dem Entwickler viel mehr Ressourcen (Register, Konstanten, Texturen, usw.) zur Verfügung, was die Programmierung erheblich vereinfacht. Man sollte also natürlich nicht Direct3D9 erst einmal "ausnutzen", da bei komplexeren Effekten dasselbe Ergebnis mit Direct3D10-Technik schneller gerendert werden kann. Schon das Shader Model 3 bietet viele Möglichkeiten, gegenüber dem Shader Model 2 die CPU-Last zu senken. Das Shader Model 4 führt dies weiter und ermöglicht, dass sich die CPU noch mehr als bisher aus dem Rendering heraushalten kann.

Auch mit der Direct3D7-API ließen sich Programme schreiben, die einen G80 in die Knie zwingen – insofern ist die Frage, ob er für Direct3D10 "schnell genug" ist, unsinnig: Es hängt immer davon ab, was man machen möchte. Bei 3D-Shootern, die anno 2008 erscheinen und möglicherweise Direct3D10 nutzen, kann der G80 natürlich nicht mehr alles in voller Pracht bei höchsten Auflösungen anzeigen.

Allerdings darf man jetzt auch nicht die Vorstellung haben, dass die GPU "Direct3D9-Einheiten" und "Direct3D10-Einheiten" besitzen würde. Eine GPU hat Rechwerke, die Daten verarbeiten. Nicht alle der G80-Werke können in Direct3D9 genutzt werden – das ist aber eine Schwäche der API. DirectX führte leider immer wieder starre Gerüste ein; Erweiterbarkeit ist da Fehlanzeige. Man kann sagen, dass Direct3D10 einige Schwächen vom Vorgänger ausbügelt, ohne jedoch an grundlegenden Problemen zu rühren. Direct3D ist eine Definition, was der Chip können muss und wie mit dem Treiber kommuniziert wird, Direct3D bringt jedoch selber keine Features. Die Features bringt der Chip.

Da Microsofts neues Treibermodell mit verbesserter Sicherheit und verschnellerter Kommunikation nur in Windows Vista zur Verfügung steht und Direct3D10 strikt für das neue Treibermodell entwickelt wurde, bleibt es Windows-XP-Nutzern prinzipiell verwehrt. Das ist kein Problem der GPU, sondern ein Problem von Microsofts Produkt-Politik. Wer hier wem schadet, bleibt abzuwarten. Wäre das OpenGL-Konsortium weniger träge, könnte man diese alternative Grafik-Schnittstelle für "Direct3D10-Features" nutzen. Nvidia, die sich traditionell auf der OpenGL-Seite engagieren, hat natürlich schon neue Extensions vorgestellt (bislang war aus jeder GeForce in OpenGL mehr an Features herauszuholen als in der entsprechenden Direct3D-Generation).

Da es so aussieht, dass AMD/ATI hier mitziehen wird (und PowerVR mittelfristig sowieso), bleiben gute Gründe für die Existenz der OpenGL-API. Microsofts Marktmacht hin oder her – sowohl bei 3D-beschleunigten Kleingeräten als auch bei der neuen Playstation 3 spielt OpenGL eine tragende Rolle. Uns Anwendern eröffnet das die Möglichkeit, die neue Flexibilität mittelfristig auch in Windows XP zu sehen zu bekommen, ohne irgendwie Direct3D10 emulieren zu müssen.

Wir verzichten ganz bewusst darauf, jetzt Screenshots zu bringen, die zeigen sollen, was mit Direct3D10 nun möglich würde. Erstens wären praktisch alle Szenen auch mit Direct3D9 zu rendern, nur eben in geringerer Geschwindigkeit, und zweitens spiegeln Techdemos nicht das wieder, was wir dann in Spielen erwarten dürfen. Und wieder einmal – wie oft noch? – wird uns Displacement-Mapping versprochen. Hierbei gibt es allerdings eine Reihe an prinzipiellen Problemen, die den großflächigen Einsatz in frei begehbaren Spielwelten erschweren.

Unsere Bitte an den Leser: Das Effekte-Denken abgewöhnen – GPUs sind programmierbar. Der NV10 ist nur wenig programmierbar, der NV30 um Größenordnungen besser, der NV50 (G80) wäre bei einem entsprechenden Compiler schon in der Lage, einfachen C-Code laufen zu lassen. Der G80 ermöglicht (abgesehen von den neuen Bit-Operationen im Shader, die nur schwer zu emulieren sind) keinen einzigen neuen Effekt. Er erlaubt aber eine flexiblere Programmierung und höhere Berechnungsgeschwindigkeit als jede andere bisher dagewesenen Consumer-GPU. Das heißt, er erlaubt, komplexere Effekte als bisher in Echtzeit zu rendern.

Sofern man mehrere Lichtquellen hat und unterschiedlich glatte Oberflächen glaubwürdig darstellen möchte, kann man ganz schnell auf 11 (oder mehr) Einflüsse kommen, die pro Pixel berechnet werden müssen. Da benötigt man nicht nur die Rohleistung, sondern auch Hardware, welche die theoretische Leistung möglichst gut nutzen kann. Dazu gehen wir nun ein wenig mehr ins Detail.

   Pipeline-Details

Ein Skalar ist einfach eine Zahl, ein Vektor ist eine Gruppe aus mehreren Zahlen. Insofern kann man den Skalar auch als Vektor mit nur einer Komponente verstehen. Ein Pixel wird traditionell mit einem 4D-Vektor ("Vec4") dargestellt, davon drei Komponenten für die Farbe im RGB-System und einer weiteren Komponente für Zusatzinformationen, Alpha genannt. Alpha wird dabei häufig für abgestufte Transparenz genutzt. Weil ein Pixel als Vektor dargestellt wird, hat man lange Zeit entsprechende Vektor-ALUs gebaut.

Der G80 hat nun "skalar" genannte ALUs, aber immer für 16 Pixel zusammen. Man kann deshalb auch von einer Vec16-ALU sprechen, die für 16 Pixel jeweils eine einzelne Vektor-Komponente, sprich einen Skalar berechnet. Im Klartext: Der G80 hat keine 128 skalaren Pipelines. Ebensowenig hat der G70 24 Pixel-Pipelines – es sind sechs Quadpipes. Der G80 hat acht Vec16-Pipelines, die aber effizienter genutzt werden als die G70-Rechenwerke.

Angenommen, im Shadercode folgen drei skalare Operationen aufeinander. Diese drei Operationen benötigen im NV40 und G70 (oder in einer aktuellen Radeon-GPU) zwei Takte, weil dort pro Takt maximal zwei unterschiedliche Operationen "nebeneinander" ausgeführt werden können. Dabei gibt es noch weitere Einschränkungen, die uns hier aber im Detail nicht interessieren. Wie schon gesagt berechnet die Quadpipeline pro Takt vier Pixel. Der G80 benötigt für drei skalare Operationen natürlich drei Takte, und nicht nur zwei – aber berechnet dies dann auch für die vierfache Pixelmenge (16 statt vier Pixel)! "Effektiv" benötigt er also 0,75 statt zwei Takte.

Die DP-Operation (das Skalar-Produkt) wird im G70 noch direkt ausgeführt und muss im G80 in skalare Rechnungen aufgedröselt werden. Somit lässt sich das DP allerdings effizienter berechnen. Einfach gesagt deshalb, weil weniger ADD-ALUs verschwendet werden. Während der G70 neben seinen zwei MULs auch noch zwei ADDs hat, besitzt der G80 auf seine zwei MULs nur ein ADD.

Die G80-Architektur berechnet somit pro Takt pro Pixel weniger als der G70, dafür mehr Pixel gleichzeitig. Dass der G80 pro Pipe und pro Takt nur die halbe ADD-Leistung des G70 hat, ist durch die verbesserte Effizienz und der deutlichen Taktsteigerung bei ohnehin breiterer Architektur kein Hemmschuh.

Interessanterweise kommt die neue Architektur auch mit Vereinfachungen daher: Die Möglichkeit im NV40 und G70, in einer Shader-Unit bis zu zwei Operationen nebeneinander ausführen zu lassen, benötigt entstprechend flexible – also auch entsprechend lange – Befehlsinstruktionen (Befehle werden bei GeForce-Karten seit CineFX mit VLIWs, Very Large Instruction Words, durch den Speicherzugriff der TMU in die Pipeline eingespeist).

Im G80 hingegen führen alle ALUs des Vec16-Rechenwerkes dieselbe Instruktion aus und müssen nicht separat konfiguriert werden können. Das verkürzt die Wortlänge vom VLIW – allerdings steigt durch die skalare Aufteilung die Zahl der benötigten VLIWs an, um einen Shader abzuarbeiten. Da das Registerfile nur noch Skalare speichert (natürlich entsprechend der ALU-Breite immer für 16 Pixel gleichzeitig), wird dieses effizienter genutzt als in bisherigen Architekturen.

Interessanterweise gibt es bei den G80-Pixelshadern einen Overhead bei den ALUs, der allerdings bei Multitexturing-Shadern aufgrund der Zeit, in der die TMUs ohnehin beschäftigt sind, keine Rolle mehr spielt. Vielleicht werden bestimmte ehemalige festverdrahtete Funktionen nun auch von den Pipeline-ALU übernommen – ob es mehr ist als die Perspektiv-Korrektur, wissen wir nicht. Wie schon gesagt hat diese Eigenschaft keine praxisrelevanten Auswirkungen, da andere Stellen limitieren.

   Spezialfunktionen

Wie bereits gesagt, bestehen Shader zum größten Teil aus MUL- und ADD-Operationen. Doch für bestimmte Berechnungen sind zusätzliche mathematischen Funktionen sehr nützlich. Im Prinzip könnte man diese auch über einen Textur-Lookup realisieren, welcher jedoch zulasten der Performance ginge. Deshalb sind bestimmte Spezialfunktionen (SFUs) direkt in die ALU-Pipeline integriert:

Diese SFUs kosten beim G80 soweit wir wissen jeweils vier Takte. Die meisten SFUs gab es auf dem G70 noch für jeweils einen Takt. Damit ist trotzdem keine verlangsamte Berechnung verbunden, denn eine SFU berechnet jeweils nur einen Skalar. Die 24 "Pixelpipelines" des G71 können also bei 650 MHz pro Takt 24 SFUs berechnen. Die 128 "skalaren Pipelines" des G80 können bei 1350 MHz pro Takt 32 SFUs berechnen – es steht also fast die 2,8-fache SFU-Leistung im Vergleich zum G71 zur Verfügung.