NV40-Technik im Detail
Teil 2: Die Ausnutzung der NV40-Möglichkeiten

28. Oktober 2004 / von aths / Seite 5 von 5

   Wer ist effizienter?

In früheren Artikeln haben wir den NV40 für weniger effizient als den R420 gehalten, weil der NV40 pro Takt nicht doppelt so viel tun kann wie der R420 – obwohl er doppelt so viel Shader-Einheiten mit sich bringt. Nun, da mehr Details bekannt sind, scheint der NV40 effizienter als der R420, da man die "beiden" Shader-Einheiten als ein Modell auffassen kann, welche die Abhängigkeiten zwischen der Recheneinheiten einer einzelnen vollen Shader-Einheit erklärt (der R420-Chip hat ebenfalls eine einzige volle Shader-Einheit pro Pipeline).

Doch das ist noch nicht die ganze Wahrheit. Die Texturformat-Konvertierungseinheiten im NVV40, die an der TMU hängen, bieten bestimmte Skalierungs-Operationen "kostenlos" (in der gleichen, versteckten Stage der normalen Formatumwandlung). Das ist möglich, weil die Skalierung um einen Faktor, der sich aus 2ⁿ ergibt, sehr einfach zu implementieren ist (auch für Gleitkomma). Solche Zusatz-Logik kann helfen, die Haupt-Einheiten der Pixelshader-Hardware zu entlasten. Natürlich haben diese Zusatz-Einheiten nicht in jedem Takt etwas zu tun, was dann wieder zur Ineffizienz führt. So weit wir wissen, kann die TMU vom NV40 z. B. den _bx2-Modifier ausführen, bietet jedoch nicht jede Skalierung im Bereich von _d8 bis _x8.

Übrigens wird der Shader-Code in die Pipeline mittels dem TMU-Speicherzugriff geladen. Das führt zur Frage, ob der Texturcache auch Pixelshader-Code puffern kann. Betreffs des NV40-Texturcaches gibt es ohnehin noch eine Reihe offener Fragen, welche allerdings in dieser Artikel-Serie kein Thema sind.

Was nicht länger geboten wird, ist im gleichen Takt zwei DP3-Instruktionen ausführen zu können. Seit der GeForce 256 hatte das jeder Nvidia Register Combiner beherrscht. Sogar die GeForceFX 5800 bietet das (dank ihrer Extra-Einheiten für Festkomma-Rechnungen). Die GeForce 6800 weicht von dieser Linie ab. Ebenso sind die Register Combiner auch nicht mehr schneller, als wenn man die gleiche Rechnung im Gleitkomma-Format ausführt (einfach weil jetzt alle internen Rechnungen von Gleitkomma-Einheiten berechnet werden). Wie gewohnt kann eine DirectX8-Texturoperation durchaus mehr als einen Takt in Anspruch nehmen. Das ist allerdings kein Nachteil, da der NV40 für DirectX 7/8 ohnehin schnell genug ist (und zwar etwa zweimal so schnell wie der NV35 bereits ist).

Vereinfacht gesagt, führt der NV40 Berechnungen unabhängig ihres Formates (FP32, FP16 und FX12) alle mit der gleichen Geschwindigkeit aus, weil für alle Formate die gleichen Einheiten (mit FP32-Genauigkeit) genutzt werden. Der Platz für temporäre Register, den die Hardware zur Verfügung stellt, ist aber nach wie vor begrenzt. Da ein solches Register nun entweder einen einzelnen FP32-, oder zwei FP16-Werte halten kann, wird FP32-Rendering langsamer, sofern das Temp-File voll ist, weil die Pipeline dann warten muss, bis einige Pixel fertigestellt sind und sie somit wieder Platz für neue Pixel freigeben. Interne Bandbreite ist unter bestimmten Umständen auch ein Problem, weshalb man alles, was mit FP16-Genauigkeit auskommt, auch mit diesem kleineren Format berechnen sollte.

DirectX7 Multitexturing-Setups and DirectX8 Pixelshader bekommen FP16 für Farb-Operationen und FP32 für Textur-Operationen. Festkomma-Berechnungen werden nicht länger angeboten (FX12 kann verlustfrei in FP16 umgewandelt werden).

Für FP16 steht nun noch zusätzliche Hardware zur Verfügung, welche erlaubt, pro Takt ein zusätzliches NRM auszuführen (wobei die Operation eine Latenz von zwei Takten zu haben scheint). Da nun kein Mensch pro Takt ein NRM_PP braucht, sieht das vielleicht wie Overkill aus. Auf der anderen Seite sollte Bumpmapping immer mit normalisierten Vektoren arbeiten, und FP16 liefert gegenüber FX8 eine sehr gute Auflösung.

FP16-Normalmaps liefern ein viel besseres Detail als herkömmliche, oder 3Dc-komprimierte Normalmaps. Denormalisierte FX8-Normalmaps bieten gegenüber 3Dc ebenfalls eine feinere Auflösung bestimmter Winkel, da 3Dc-Maps nur normalisierte Normalen speichern können. Außerdem belastet 3Dc den Pixelshader. Anstatt 3Dc zu nutzen, kann man Normalmaps auch mit DXT5 komprimieren. Durch die sehr schnelle Ausführung von NRM_PP bietet der NV40 hochwertiges Bumpmapping bei sehr guter Performance – so denn der NV40 auch entsprechend ausgenutzt wird.

Jedenfalls, dieses "kostenlose" NRM_PP ist ein Vorteil, ob das nun auf den Transistorcount bezogen effizient ist oder nicht. _PP heißt zwar nur Partial Precision, für Shader Model 3 gilt allerdings auch FP24 noch als Partial Precision. Wenn ATI von sich sagt, alles in Full Precision zu rechnen, gilt das nur für den SM2-Standard.

Dieselbe Einheit im NV40, die NRM_PP bietet, kann alternativ ein Fog-Blending durchführen. Auch dies entlastet die Pixelshader-Haupteinheiten. Es gibt weitere Hardware-Einheiten, die dem Pixelshader Arbeit abnehmen können. Mehr dazu gibt es im dritten Teil unserer Artikel-Serie zur NV40-Technik.

   Unser Vergleichs-Ergebnis

Die Schlussfolgerung ist: Mit dem NV40 bietet Nvidia sowohl die Crossbar-Logik für eine effiziente Nutzung, aber stattet die Pipesline auch mit genügend Recheneinheiten und hilfreichen Mini-FPU-Stages aus, um die rohe Leistung zu bieten, nach der zukünftige Spiele verlangen werden. Obwohl eine NV40-Pipeline weniger theoretische Rechenkraft hat als eine NV35-Pipeline, führt sie in der Praxis pro Takt bis zu doppelt so viele Operationen aus. Die Rechenkraft einer R300/R420-Pipeline wird ebenso einfach übertrumpft – sofern der Optimizer gut arbeitet.

Doch wir müssen ebenfalls sagen, dass die NV40-Pipeline einen Kompromiss darstellt. Beim Design war zwischen "Flexibilität" und "was kann innerhalb des Transistor-Budgets realisiert werden" abzuwägen. Die hohe "Packungsdichte" der Befehle ist dafür optimiert, dass bestimmte oft genutzte Operationen wie DIV (RCP, MUL), SQRT (RSQ, RCP), NRM (DP, RSQ, MUL) und einige andere besonders schnell ausgeführt werden. Um Transistoren zu sparen, ist die Crossbar und das Readport-Limit jedoch begrenzt. Es gibt Fälle, in denen der Chip rein für Daten-Rangierung Extra-Takte benötigt. Es gibt auch Fälle, in denen der R420 pro Takt mehr rechnen kann als NV40, diese sind allerdings recht selten.

Der NV40 ist auf einen sehr guten Optimizer angewiesen, um seine schnelle Shader-Ausführung auch in der Praxis zu bringen. Zum Glück hat das genutzte Shader-Profil keine Auswirkung auf die Performance mehr, wie früher noch bei der GeForceFX. Würde der Pixelshader-Code, der für Radeon 9700 oder X800 optimiert ist, so ausgeführt wie er genau vorliegt, würde das den NV40 ausbremsen. Doch der Optimizer transformiert den Code in einen anderen, der aus Performance-Sicht für den NV40 besser geeignet ist. Übrigens darf ein WHQL-Treiber dabei nicht eigenmächtig ein _PP-Flag setzen, selbst wenn es am Resultat nichts ändern würde.

Wir fassen zusammen: Es reicht nicht aus, schnelle Hardware zu entwickeln. Gute Pixelshader-Performance fragt ebenso nach ausgereifter Software-Technik.

   Was ist in Zukunft zu erwarten?

Offensichtlich werden zukünftige Shader-Implementierungen im Vergleich zum NV40 noch flexibler sein. Die zunächst drängendere Frage ist: Wird der nächstfolgende Grafikchip mehr Pipelines oder mehr Einheiten pro Pipeline haben? Wir halten eine zusätzliche MAD-Einheit mit Co-Issue-Fähigkeit (eine zusätzliche Shader-Einheit #2, jedoch ohne SFUs), also insgesamt drei Shadereinheiten pro Pipeline, für ein Optimum für zukünftige Pixelshader-Anforderungen.

Auf der anderen Seite ist es natürlich einfacher, bereits fertig entwickelte Quad-Pipelines zu nehmen und davon lediglich mehr auf einen Chip zu packen. Eine tiefere Pipeline mit immerhin drei Shader-Einheiten wäre auch schwieriger zu optimieren, als das jetzt beim NV40 der Fall ist. Insofern wagen wir derzeit nicht, großartig über zukünftige Designs zu spekulieren.

   In ASM zu programmieren ist schlecht

Lowlevel-"Handoptimierung" für einen bestimmten Chip ist keine gute Idee. Ein schlechtes Compiler-Ergebnis sollte dazu führen, dass der Compiler verbessert wird und nicht zur Rückkehr zur Assembler-Programmierung bewegen. Nehmen wir an, wir haben einen Vertexshader 1.1, der noch kein SINCOS beherrscht. Sinnvollerweise sollte man Shader grundsätzlich in einer Highlevel-Sprache schreiben. Diese Programmiersprache kann ein SINCOS in jedem Fall anbieten, und das Funktionsergebnis dann mit anderen mathematischen Operationen annähern.

Der Vertexshader 2.0 bietet eine solche SINCOS-Instruktion, allerdings auch nur als Makro. Jedoch gibt es heute VS-Implemementierungen, die diesen Befehl "wirklich" können, indem sie eine viel schnellere Ausführung bieten (was dank interner Lookup-Tabellen möglich ist und die herkömmliche Näherungsreihe mit einer langen Sequenz durch andere Operationen einspart).

Steht nur der Assembler-Code zur Verfügung, ist es schwierig, im nachhinein festzustellen, dass eine bestimmte Instruktions-Sequenz den SINCOS annähern soll. Wenn die neue Hardware den alten Code zwar noch ausführen kann, so ist das doch langsamer als es die Ausführung eines neu kompilierten Highlevel-Shaders wäre.

Nvidia wird die Pipelines, basierend auf dem NV40, weiter entwickeln, das ist sicher. Vielleicht werden bestimmte Limits wegfallen, vielleicht werden dafür andere Abhängigkeiten hinzukommen, was bei Nutzung einer alten Optimierung der Performance abträglich wäre. Der Entwickler sollte nicht versuchen, eine Hand voll Takte zu sparen, in dem er Assembler nutzt, da die Portabilität eines Codes wichtiger ist. Jede Pipeline hat ihre Schwächen und Flaschenhälse, welche sich negativ auf die Leistung auswirken können. Solche "Don‘t Do"-Sachen sollten dem Entwickler natürlich bekannt sein, damit er gegebenenfalls einen Workaround implementieren kann.

Da wir nun HLSL (und Cg) haben, sollte Assembler jedenfalls keine Option für einen DirectX9-Shader darstellen. Nvidia ist für guten Entwickler-Support bekannt und hilft, die Performance ohne Nutzung von Steinzeit-Techniken zu verbessern. Da wir gerade von DirectX9-Shadern reden: Im letzten Teil dieser Artikel-Serie zur NV40-Serie werfen wir einen Blick auf das Shader Model 3.