NV40-Technik im Detail
Teil 1: Geheimnisse der Pixelshader-Einheit

23. August 2004 / von aths / Seite 1 von 5

   Vorwort

Die vergangenen 10 Jahre in der Entwicklung von 3D-Hardware für den Consumer-Markt brachten uns Meilensteine wie Voodoo Graphics, GeForce3 und Radeon 9700. Doch Computer-generierte Echtzeitgrafik sieht noch immer sehr "synthetisch" aus: Oberflächen erscheinen zu glatt, die Geometrieauflösung ist zu grob, Flüssigkeiten wirken noch nicht realistisch genug. Doch wir sahen auch dramatische Fortschritte auf dem Weg zum endgültigen Ziel: Die Berechnung fotorealistischer Grafik in HDTV-Auflösung, und das in Echtzeit.

Der NV40 ist die höchstentwickelte GPU, die es momentan gibt. Das nehmen wir zum Anlass, um auf verschiedene Aspekte dieser GPU einen Blick zu werfen. Dafür haben wir unseren Artikel in drei Folgen unterteilt. Heute geht es darum, wie die NV40-Pipeline arbeitet – und warum Nvidia sie ausgerechnet so designte. Teil 2 wird erklären, wie man diese Pipeline voll ausnutzen kann. Teil 3 diskutiert das Shader Model 3.0 und andere Features. Beginnnen wir mit der Entwicklungsgeschichte, die letztlich zum NV40 führte.

   Wie die Vergangenheit die Zukunft bestimmt

Was Nvidias GPUs angeht, werden die Richtungentscheidungen von David Kirk getroffen. Seine hervorstechendste Charaktereigenschaft ist sein pragmatischer Realitätssinn. Was kann man in einer gegebenen Entwicklungzeit mit einer begrenzten Zahl von Transistoren anfangen? Er setzt die Schwerpunkte und stellt sicher, dass heutige Hardware den Weg für zukünftige Features bereitet. Da nun sowohl Entwickler als auch Anwender jeweils sehr viel verlangen, muss er auch entscheiden, was in einer gegebenen Generation noch nicht geboten werden kann.

David Kirk stieß zum Entwickler-Team, als Nvidia noch ein Startup-Unternehmen war. Als erstes ließ er die Entwicklung des NV2 einstellen und entschied, dass NV3 flache Dreiecke als Basis-Objekt nutzt. Verglichen mit Bezier-Quads sind Dreiecke eine weniger flexible, dafür aber bewährte Technik. NV3 wurde gebaut, um die Anforderungen des OEM-Markts zu erfüllen, weshalb der Chip und seine Hardware-Konfiguration billig sein mussten. So unterstützte Riva 128 kein 2x AGP und kam mit gerade mal 4 MB RAM.

Das erste Bemühen von Nvidia, wirklich mitmischen zu wollen, zeigte sich im NV4 (auch bekannt als Riva TNT) bzw. im Nachfolger NV5 (der Riva TNT2). Die Nutzer waren zufrieden mit den 32 MB RAM und Unterstützung von 4x AGP sowie 32-Bit-Rendering, der NV5 wurde damit ein ziemlicher Erfolg. Schon der originale NV4 kam mit einem recht starken Combiner, der zwei MULs und ein ADD pro Pipeline und Takt schaffte. Nicht zuletzt sei erwähnt, dass auch schon zwei Pipelines statt nur einer geboten wurden.

NV10 (GeForce 256) kam mit einem "programmierbarem" Register Combiner, der Dot3 Bumpmapping beherrscht (Doom 3 nutzt diese Technik kräftig aus, um so pixelgenaue Beleuchtung zu bieten) oder auch nette Spiegel-Effekte mit maskiertem Enviroment Mapping anbot. Andere Grafikchips jener Zeit waren auf eine Textur pro Stage limitiert, jede GeForce kann pro Stage auf mindestens zwei Texturen zugreifen.

NV20 (GeForce) kam dann endlich mit dependent reads. Diese Technologie erlaubt Enviromental Bumpmapping (erfunden von den Bitboys, dann an Matrox lizensiert und in DirectX integriert seit DirectX6) und wurde zu jener Zeit auch schon von ATIs Radeon angeboten. Wenn auch 3dfx' Rampage in einigen Belangen der GeForce3 voraus war, schaffte es der Rampage doch nie bis zum Nutzer. Obwohl Radeon und Radeon 8500 seinerzeit einen fortschrittlicheren Pixelprozessor hatten, war eine bessere Karte von Nvidia nie weit.

   Entscheidungen

Zu jeder Zeit begrenzt der Fertigungsprozess die Zahl der Transistoren, die auf einen Chip passen. Da sowohl ATI als auch Nvidia exzellente Entwickler beschäftigen, sollte man jeweils vergleichbare Performance und Features erwarten. Nun ist jeder existierender Chip ein Kompromiss, so hat der NV30 (GeForceFX 5800) natürlich sehr gute Shader-Features, bietet aber nur armselige DirextX9-Leistung. Die CineFX-Engine vom NV30 war vor allem für Entwickler gedacht. NV35 (GeForceFX 5900) hat zwar viel mehr Pixelshader-Leistung, kann aber trotzdem nicht zu ATIs Meisterstück namens Radeon 9700 aufschließen. Wie wir wissen ist der R300-Chip ebenfalls ein Kompromiss: Er bietet nur geringe Filter-Präzision und die Shader unterliegen vielen Beschränkungen.

NV30 ist in erster Linie ein NV25 (GeForce4 Ti) mit zusätzlichen DirectX9-Einheiten. Beim NV35 verschwimmt die Trennung zwischen "alten" und "neuen" Shadereinheiten, was Transistoren spart, aber auch die DirectX8-Pixelshader-Leistung drückt. Dies wurde mit gesteigertem Takt und anderen Verbesserungen ausgeglichen. Der DirectX9 Pixelshader-Leistungsschub kommt von einer zusätzlichen FPU, welche einige häufig genutzte Operationen ausführen kann (während der Shadercore nach wie vor jede Instruktion beherrscht). Wenn der NV35 mit CineFX2 auch deutlich mehr Leistung bietet als NV30 mit CineFX1, ist eine Optimierung auf die neue Engine noch schwieriger.

Die große Herausforderung für die CineFX3-Engine vom NV40 bestand nun darin, die Pixelshader-Leistung bedeutend zu steigern und dabei die Transistorzahl so niedrig wie möglich zu halten. ATIs Beispiel, geringere Präzision und ein begrenzteres Feature-Set anzubieten war keine Möglichkeit, da weniger Fähigkeiten als schon der NV30 hatte vom Anwender nicht mehr akzeptiert würden. Mehr Leistung durch zusätzliche Recheneinheiten (wie wir das im NV35 sahen) würde in einer nicht mehr handhabbaren Chipgröße resultieren. Damit war Nvidia gezwungen, ein neue Pixelshader-Pipeline zu entwickeln. Um diese neue Pipeline soll es nun gehen.

   Was man von einer Pipeline erwartet

Verglichen mit dem direkte Vorgänger hat NV40 eine viel schlankere Pipe. Um das auszugleichen, kommt der Chip nicht nur mit mehr Pipelines, sondern kann jede einzelne auch besser ausnutzen. Nvidia behauptet, dass die neue Pipeline gleich zwei Shader-Units hat. Dieses Bild zeigten wir schon einmal in einem älteren Artikel:

NV40 bietet zwei Shader-Units pro Pipe, jede ist in ihrem Funktionsumfang eingeschränkt.

Ein Bild für richtig oder unzutreffen zu halten hängt davon ab, wie viele Feinheiten man berücksichtigen will. Zunächst interessieren wir uns nicht für die Mini-FPU (oder "Mini-ALU"), weil jede normale Architektur solche Hilfs-Einheiten hat, natürlich auch schon DirectX7- und DirectX8-Hardware. Solche Mini-Einheiten machen Modifier wie In- oder Output-Skalierung und/oder Verschiebung "kostenlos". Mit "Verschiebung", im Originaltext "biasing", ist hier die Addition oder Subtraktion von bestimmten Konstanten gemeint, z. B. -0,5.

Traditionell ist jeder Combiner (bereits im ersten Voodoo Graphics Chipsatz) in einen Vektor3-Farbcombiner und einen skalaren Alphacombiner unterteilt. Der Grund ist einfach, dass sich Alpha-Operationen (für Transparenz und andere Effekte) von den erforderlichen Farb-Berechnungen unterscheiden. Nun haben NV30 und NV35 aber nur Vektor4-Einheiten für Gleitkomma-Rechnungen. Auf der anderen Seite kann der DirectX9-Pixelshader der Radeon eine Vektor3 und eine weitere skalare Operation im gleichen Takt ausführen. Dennoch zählen wir dieses Einheiten-Paar als eine einzige Einheit, da bestimmte Befehle alle vier Datenkanäle zeitgleich brauchen.

Herkömmliches Co-Issue.

Wie wird überhaupt ein Pixel "geshadet"? Um Texturen nutzen zu können, braucht man eine Textur-Einheit. Weiterhin werden alle Lichtwerte für ein gegebenes Pixel addiert, der Ergebniswert mit der Textur multipliziert. Deshalb brauchen wir ADD und MUL. Um die Lichtintensität zu bestimmen, kommt das Skalarprodukt (englisch dot product) ins Spiel, also DP3 (oder "Dot3"). Um die Normalenvektoren (nur pro Eckpunkt verfügbar) über das gesamte Dreieck zu interpolieren, brauchen wir lineare Interpolation.

Da dies eine sehr häufig gefragte Operation ist, hat jeder 3D-Chip dafür spezielle Hardware. Doch jeder Pixelshader bietet lineare Interpolation (LRP) auch als arithmetische Instruktion an, welche wieder mal ADD- und MUL-Einheiten nutzt. Um Werte zu re-normalisieren (was Block-Artefakte vermeidet), wird auch ein passender Befehl gebraucht – das NRM verlangt allerdings zusätzliche Funktionen wie Quadratwurzel und Reziproke.

Dies im Hinterkopf können wir nun anfangen, eine Pipeline in ihre Einheiten aufzubrechen.