Vorschau auf die nVidia GeForce 6800 Ultra: Auf NV30 folgt NV40

Renderarchitektur, Teil 2

16 Pixelpipelines mit jeweils zwei FP-Shadereinheiten - das klingt zunächst einmal ziemlich eindrucksvoll. Doch schon der Vorgänger, der NV3x, wollte teils mit acht Pipelines auftrumpfen können. Im Gegensatz zur ersten DirectX9-Generation ist der NV40-Chip in der Lage, auch wirklich 16 Pixel pro Takt in den Framebuffer zu schreiben, sprich 16 dieser Shader-Einheiten arbeiten parallel nebeneinander.

Wie auf dem Diagramm zu sehen, gibt es neben den doppelten Shader-Einheiten noch ein weiteres Leckerli in der Pixelpipeline: Floating-Point Texture Filtering, doch dazu später im Abschnitt HDR mehr.

	NV30	NV35/8	NV40
Anzahl FP-Einheiten	4	8	32
Max. Instruction Slots	512	512	>511
Max. Instructions	512	512	65535
Interpolated Reg.	2+8	2+8	10
Temporary Registers	22	22	32
Constant Registers	32	32	224
Dynamic Flow Control	Nein	Nein	Ja

Auf den ersten Blick ist die Anzahl der FP-Einheiten im NV40 schlicht überwältigend. Hier ist allerdings ein wenig Vorsicht geboten, denn es ist nicht alles Gold, was glänzt - manchmal ist auch ein wenig unedleres Metall darunter gemischt. Bestanden die Floating-Point Einheiten beim NV30 noch ausschließlich aus dem Shadercore, der für alle FP-Operationen herhalten musste, wurde das Ganze beim NV35/8 etwas unübersichtlicher, denn die zweite FPU konnte nicht alle Operationen des Shadercore übernehmen. Dies ist im Übrigen auch ein Grund, warum man beispielsweise in nVidias FX Composer auch mit CineFX I Chips eine deutlich höhere interne Auslastung erhält, als mit CineFX II - der Shader-Compiler im Treiber ist schlicht nicht in der Lage, das volle Potential der GPU nutzbar zu machen.

Der NV40 hat nun laut nVidia zwei recht indifferente FP-Shader-Einheiten pro Pipeline, wobei nur die Shader-Unit 1 in der Lage ist, neben ihrer Vektor4-Funktion auch ein TMU-Kommando abzugeben. Die zweite FPU ist hierzu nicht in der Lage. Die Fähigkeit, eine zweite TMU pro Takt anzusprechen, ist der Shader-Unit 1 im Vergleich zum nV30/5/8 genommen - angesichts nur einer TMU pro Pipeline kein großer Verlust.

Allem Anschein nach verbirgt sich hinter der Shader-Unit 1 der ehemalige Shader-Core, dem allerdings ein paar Möglichkeiten fehlen, die dafür der zweiten FPU zugeteilt wurden. Neu ist hingegen, dass das Splitting der Vektor4-Einheit nun sehr flexibel gelöst wurde. nVidia nennt dies "dual-issue" und "co-issue". Die beiden Shader-Units mit zusammen zwei Vektor4-Möglichkeiten lassen sich nun nicht nur in Vektor3 und Skalar-Operation aufteilen, sondern auch 2:2 in Vektor2-Operationen und beispielsweise eine Texturoperation. Darin liegt auch ein Grund, warum wir in unserer Tabelle auf die Angabe von Shader-Leistungswerten verzichteten. Der andere Grund ist, dass die möglichen Werte noch nicht gesichert erscheinen. Theoretisch kann der NV40 durch Kombination von Co-Issue und Dual-Issue von zwei Vektor4-Operationen über zwei Vektor3 plus zwei Skalar-Operationen bis hin zu vier Vektor2-Operationen durchführen. Daraus ergibt sich zwar eine große Flexibilität, aber gleichzeitig lässt sich diese Leistung kaum noch in einer Tabelle übersichtlich darstellen.

Wie hier zu sehen ist, befindet sich in jeder der sechzehn verbauten ROP-Pipelines neben der Color-Compare-Einheit nochmals eine separate Z-Compare Einheit. Der Tatsache, dass diese Color-Compare Einheit ohne Textureinsatz parallel als zweite Z-/Stencileinheit fungieren kann, verdankt der NV40 (und auch schon NV30, 35 und 38) seine - gegenüber der Pixelfüllrate - verdoppelte Z-/Stencilleistung. Außerdem hat man die ROP, Raster Operators, am NV40 an die neue Situation angepasst.

Wie auf diesem Bild zu sehen ist (GeForce3 - FX unten, Radeon 9700 Pro oben), haben die ROPs bei nVidia teilweise Probleme mit Color-Banding bei gewissen Blending-Operationen gehabt, während ATi bei Alpha-Blending so ihre liebe Müh' und Not hatte. Zumindest das Problem bei nVidia sollte mit dem NV40 der Vergangenheit angehören.