CineFX (NV30) Inside

31. August 2003 / von Demirug / Seite 4 von 7

   Das Shader Backend

In der Backend-Einheit werden die unterschiedlichem Datenpfade wieder synchronisiert, so dass alle Daten, die zu einem Pixelquad gehören, die Einheit wieder zusammen durchlaufen können.

CineFX Shader Backend

Nach erfolgter Synchronisation werden noch einige Berechungen durchgeführt (Interpolation eines Vertexfarbwerts, Nebel, Pixeltiefe) und die Texturesamples bei Bedarf in eines der internen Formate (fp32, fp16, int12) konvertiert. Diese Daten können dann noch mit Werten aus dem Registerspeicher ergänzt werden, bevor sie als Paket in die Combiners gehen.

   Combiner

Wie bereits oben geschrieben, schweigt sich das Patent in diesem Punkt aus. Es wird darauf verwiesen, dass jede allgemein bekannte Technik für Combiner hier zum Einsatz kommen kann. Es ist es aber unbedingt erforderlich, dass man Ergebnisse der Combiner wahlweise wieder zurück in den Registerspeicher schreiben oder zu den ROPs (Raster Operatoren) weiterleiten kann. Benötigt der entsprechende Pixel einen weiteren Lauf durch die Pipeline, so wird dies den ganzen Weg zurück an den Shader Core gemeldet, damit dieser weiß, dass das Quad am Ende der Pipeline auf eine erneute Bearbeitung wartet.

   Der Torwächter und die Loopback-Steuerung

Der Torwächter (Gatekeeper) steht zwar eigentlich am Anfang der Pipeline. Das er dennoch erst jetzt erläutert wird, hängt damit zusammen, dass sich seine Funktion erst erschließen lässt, wenn man den Rest der Pipeline kennt (welche er ja bewacht). Die Entscheidungen des Torwächters haben direkten Einfluss auf die Wahl der Datenquelle in der ersten Stufe des Shadercores. In dem Fall, dass ein Pixelshader so einfach aufgebaut ist, dass er keinen Loopback über die komplette Pipeline braucht, wird sich der Torwächter einfach auf die faule Haut legen und alle Quads, die vom Rasterisier kommen, einfach in die Pipeline einlassen.

Werden aber Loopbacks gebraucht, entscheidet der Torwächter, wann ein Quad vom Rasterizer die Pipeline betreten darf. Zuerst wird er so viele Quads in die Pipeline lassen, bis diese voll ist. Ab diesem Zeitpunkt wird er die am Ende der Pipeline auf den nächsten Durchlauf wartenden Quads für den nächsten Durchlauf freigeben. Sobald alle diese Quads wieder am Anfang in die Pipeline eingegeben wurden, prüft der Torwächter, ob noch Platz für zusätzliche Quads in der Pipe vorhanden ist. Falls ja, wird er wieder neue Quads vom Rasterizer einlassen, bis die Pipeline vollständig gefüllt ist.

Freie Plätze werden dadurch geschaffen, dass einzelne Quads, nachdem sie ihr Shaderprogramm vollständig durchlaufen haben, die Pipeline in Richtung ROPs verlassen. Bisher sprachen wir einfach von einer gefüllten Pipeline, aber wie viele Quads passen den nun in die Pipeline, bis diese gefüllt ist? Hier hat nVidia einen variablen Ansatz gewählt. Die maximale Anzahl von gleichzeitig in der Pipeline vorhandenen Quads ergibt sich, wenn man die Größe des Speichers für die Register (siehe Shader Backend) durch die durch einen Quad beanspruchte Speichermenge teilt. Die Speichermenge pro Quad berechnet sich aus der Anzahl und dem Datenformat der Temp-Register im Shader.

   Leistungsbetrachtung der CineFX Architektur

Früher war alles viel einfacher :-). Man schaute, wieviele Pipelines ein Chip hatte und multiplizierte das mit der Anzahl der TMUs in einer Pipeline und dem Chiptakt. So hatte man die Texelfillrate berechnet, welche der Leistungsindikator für einen Chip war. Schon für die letzte Generation von Grafikchips (NV2X und R(V)2XX) war diese Rechenregel schon nicht mehr die letzte Weisheit. Da aber bis zum heutigen Zeitpunkt die Pixelshader dieser Chips eher als bessere Multitextur Einheit herhalten müssen, spiegelt die Texelfillrate nach wie vor das Leistungspotenzial eines solchen Chips gut wieder.

Als Leistungsindikator für einen moderne Pixelshaderpipeline ist die Texelfillrate aber nicht mehr gut geeignet. In der Programmierbarkeit nähern sich GPUs ja immer mehr den CPUs an. So macht es dann auch Sinn, ein bei den CPUs gebräuchlichen Leistungsindikator auf die GPUs zu übertragen. Es geht hier um die Instruktionen pro Sekunde gemessen in MIPS. Auch ein Pixelshader führt wie eine CPU Instruktionen aus. Neben der Fließpunkt- und Integerleistung (welche bei >= PS 2.0 keine Rolle mehr spielt) gibt es als dritte wichtige Instruktionsart noch die Textureninstruktionen.

Die Pixel/s, welche mit einem bestimmten Shader erzeugt werden können, ergeben sich also aus der zur Verfügung stehen Rechenleistung geteilt durch die Rechenleistung, die pro Pixel gebraucht wird. Beim NV30 bleibt als aktive Recheneinheit beim Verarbeiten von 2.0er Pixelshadern nur der Shader Core. Die Combiner sind aufgrund des Datenformats (nur Integer) in dieser Disziplin nicht zum Start zugelassen.

Da wir nun einen Shader Core haben, welcher 4 Pixel (ein Quad) bearbeiten kann, kommen wir auf 4 Micro-Instruktionen pro Takt. Micro-Instruktionen aus dem Grund, weil der Shader-Core nicht in der Lage ist, jede PS-Instruktion in genau einem Takt auszuführen. Zum einen gibt es Instruktionen, welche mehr als einen Durchlauf durch den Core benötigen, auf der anderen Seite können aber 2 Textureanweisungen gleichzeitig bearbeitet werden. Damit kommen wir also auf eine Leistung von 8 Texturinstruktionen oder 4 Arithmetik-Operationen. An diesem Punkt ist es nun wichtig darauf hinzuweisen, dass eine Texturanweisung nicht identisch mit dem Auslesen und Filtern einer Textur ist. Die Anweisung erzeugt nur das Kommando, welches dann an eine TMU weitergegeben wird.

Stellen wir nun unseren NV30 seinen Konkurrenten aus dem Hause ATi gegenüber, wird er von der Pro-Takt-Leistung erst einmal überfahren. ATi kommt hier mit 8 Textureinstruktionen und zusätzlichen 8 Arithmetik Operationen angerauscht. Durch den höhren Coretakt kann der NV30 zwar etwas Boden gut machen, aber selbst damit kommt er zum Beispiel nur auf 2600 MTO/s + 700 MAO/s oder 2000MTO/s + 1000 MAO/s.

Die Universal FPU, welche der Shader Core darstellt, erlaubt es Texturops gegen Arithmetikops im Verhältnis 2:1 einzutauschen (siehe nachfolgendes Diagramm). Der R300 Chip als Radeon 9700 Pro kommt aber auch ohne diese Balance-Option auf 2600 MTO/s + 2600 MAO/s. Von dieser Rohleistung kann nVidia nur träumen (oder versuchen, einen NV30 auf 1 GHz hochzutakten). Neben dem Preis für die bessere Pro-Takt-Leistung geht nun auch der Preis für die bessere Gesamt-Rohleistung an den R300.