CineFX (NV30) Inside

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

   CineFX II

Mit dem NV35 änderte nVidia den Namen der Shader-Technologie in CineFX II. Da man das CineFX beibehalten hat, sind also keine großen Änderungen zu erwarten. Das größte Problem, das nVidia lösen musste, war die schwache Rohleistung bei der Verwendung von Pixelshader der Versionen 1.4 oder höher. Da uns zu CineFX II derzeit leider kein Patent bekannt ist und es auch fraglich ist, ob es den eines gibt oder geben wird, verlassen wir jetzt den weitgehend auf Fakten aufbauenden Teil und begeben uns in das Land der Spekulationen.

nVidia erwähnt an mehreren Stellen in den Beschreibungen, dass man die Fließpunktleistung im Vergleich zum Vorgänger (NV30) verdoppelt hätte. Im "NVIDIA GEFORCE FX 5900 PRODUCT OVERVIEW" wird zudem noch erwähnt, dass der Chip nun in der Lage sei, 12 Instruktionen pro Takt auszuführen. Diese Angaben lassen nun nur den Schluss zu, dass der NV35 neben der Universal FPU in Form des Shader Cores noch eine zweite FPU erhalten hat, welche 4 Instruktionen pro Takt verarbeiten kann. Zusammen mit den 8 Texturinstruktionen erreicht man so die angegeben 12 Instruktionen.

Die zusätzliche FPU wurde mit sehr hoher Wahrscheinlichkeit im Combiner Bereich angesiedelt. Die 5 Millionen zusätzlichen Transistoren dürften für eine FPU dieser Komplexität nicht ausreichen. Also musste nVidia auch etwas entfernen, um mehr Transitoren zu bekommen. Da die neue FPU in der Lage ist, die Aufgaben der Integer ALUs zu übernehmen, darf angenommen werden, dass diese entfernt wurde. Da Tests mit dem NV35 zeigen, dass dieser bei der Verwendung von PS 1.1 - PS 1.3 nur minimale Einbrüche erleidet, darf man davon ausgehen, dass die FPU nahezu alle Funktionen der Integer-ALUs Taktgleich nachbildet. In einigen Ausnahmen-Fällen scheint dies aber nicht möglich zu sein und die neue FPU braucht für die gleiche Aufgabe mehr Takte als die alte Integer-ALU.

Bleibt nun noch die Frage, mit welchen Formaten die neue FPU zurecht kommt. Als Basis darf davon ausgegangen werden, dass die FPU für das fp32 Format (s23e8) ausgelegt ist. Die Mantisse von 23 Bit erfordert nun, dass die FPU über ein 23 Bit Addierer und Multipliziere verfügt. Erweitert man diese um 1 Bit auf 24 Bit, und erlaubt eine Auftrennen in der Mitte, erhält man zwei 12 Bit Addierer und Multipipizier. Genau das, was man braucht, um die beiden Integer-ALUs des NV30 zu ersetzten. Dieser Schritt erscheint logischer, als nur eine der beiden Integer-ALUs zu ersetzten, da hierfür in Summe eine viel kleinere Transistorenanzahl anzusetzen ist als für eine reine fp32 FPU und eine Int12 ALU.

Die Frage, ob die FPU auch in zwei fp16 (s10e5) Units teilbar ist, wollen wir vorerst noch offen lassen, weil sich aufgrund bisheriger Tests nicht eindeutig sagen lässt, ob Performancegewinne aufgrund einer höheren fp16 Rechenleistung oder dem kleineren Datenformat herrühren. Zudem kann man davon ausgehen, dass wenn 2 fp16 Operationen pro Takt möglich wären, die Marketingabteilung dies sicherlich dazu genutzt hätte, von 16 und nicht nur von 12 Instruktionen pro Takt zu sprechen.

Auch würde unser Ansatz erklären, warum die PS 1.1 - PS 1.3 Leistung etwas leiden musste. Die Integer ALUs im NV30 waren wie es scheint in Reihe verbaut und daher unanfällig gegenüber gegenseitigen Abhängigkeiten. Das oben erwähnte Model würde aber zwei parallelen Einheiten entsprechen, wodurch es nicht mehr möglich wäre, zwei Instruktionen, die eine gegenseitige Abhängigkeit haben, in einem Durchlauf zu berechnen.

Diese angenommenen CineFX II Änderungen haben nun natürlich auch einen Einfluss auf die Rohleistung und die Abhängigkeiten. In erster Annäherung bringt uns die zusätzliche FPU 4 zusätzliche Arithmetik Operationen pro Takt ein. Der NV35 erreicht also nun 8 Textur plus 4 Arithmetik Operationen oder 8 Arithmetik Operationen als Maximum. Damit ist die maximale Pro-Takt-Leistung immer noch unter der des R350, welcher die 8 Textur plus 8 Arithmetik Operationen pro Takt von seinem Vorgänger übernommen hat.

Blicken wir nun wieder auf die Gesamtleistung: nVidia hat die Taktrate beim Wechsel auf NV35 gesenkt, ATi dagegen hat die Taktrate des R350 gegenüber dem R300 erhöht. Damit ergeben sich nun beim R350 3040 MTO/s + 3040 MAO/s = 6080 MI/s. Beim NV35 haben wir es aufgrund der immer noch vorhandene Universal FPU mit einem Mischmodel zu tun, welches ein Maximum von 3600 MTO/s + 1800 MAO/s = 5400 MI/s und ein Minimum von 0 MTO/s + 3600 MAO/s = 3600 MI/s erreicht. Die Steigerung der Taktrate beim R350 sichert ATi auch hier wieder die Krone der höchsten Rohleistung. Hätte nVidia die Taktrate nicht abgesenkt, wäre der Sieg von ATi mit 1,3% nur sehr knapp ausgefallen. So liegt der Unterschied aber nun bei stolzen 12,6%.

Beim Vergleich der Worstcase Situationen konnte nVidia mit dem NV30 gegenüber dem R300 ja einen kleinen (aber in der Praxis irrelevanten) Erfolg erzielen. Schauen wir uns einmal an, wie sich die Situation hierbei verändert hat: Aufgrund der zusätzlichen FPU beim NV35 ergeben sich auch neue Anforderungen an den Shadercode, um die Rohleistung auch komplett nutzen zu können. Neben der bekannten Problematik, dass Textureanweisungen paarweise auftreten müssen, kommt nun noch eine weitere Bedingung hinzu. Den beiden Textureanweisungen muss mindestens eine Arithmetik Operationen folgen, sonst würde die neue FPU keine Aufgabe haben.

Bei einem entsprechenden Shadercode sollte es in der Regel kein Problem sein, diese Forderung zu erfüllen, da Texturwerte, bevor sie den Pixelshader verlassen, eigentlich immer noch irgendwie miteinader verrechnet werden. Das PS 1.4 Model sowie das 2.0 Model nach der ATi Empfehlung sehen nun aber vor, dass man zuerst einmal viele Texturen einlädt und dann erst mit den Berechnungen beginnt. Hier bekommt die nVidia Architektur also leider wieder ein Problem. Bei den 2.0 Shadern lässt sich das mit einem neuen Compiler lösen, bei den 1.4 Shadern wird dieser Aufbau aber so vorgeschrieben. Hier muss nVidia etwas im Treiber tun. Schauen wir uns aber nun einmal die neuen Kurven an:

Beim R350 haben wir die bekannte Kurvenform, welche aufgrund der höheren Taktraten aber nun noch oben verschoben ist. Ein Maximum von 6080 MI/s beim 1:1 Verhältnis und jeweils ein Minimum von 3040 MI/s, wenn nur Textur oder Arithmetik Operationen enthalten sind.

Die Kurven des NV35 haben sich im Verhältnis zum Vorgänger aber verändert. Betrachten wir zuerst die Kurve des Idealfalls (2 Texturoperationen gefolgt von mindestens einer Aritmetikoperation). Die Kurve beginnt auf der Seite, die für Shader steht welche nur Texturoperationen enthalten, bei 3600 MI/s. Das Maximum erreicht sie bei 5400 MI/s an dem Punkt, an welchem der Shader aus 66,7% Textureanweisungen und 33,3% Aritmetikanweisungen besteht (2:1 Verhältnis). Von diesem Punkt haben wir dann einen Abfall bis zu einem reinem Aritmetikshader mit 3600 MI/s.

Die zweite NV35 Kurve zeigt uns einen Shader, welcher keine paarweisen Texturinstruktionen benutzt. Beim reinen Textureshader beginnt die Kurve auf einem Level von 1800 MI/s, um dann bis auf einem Wert von 3600 MI/s bei einem 1:1 Verhältniss zu steigen. Ab diesem Punkt bleibt die Leistung dann konstant bei 3600 MI/s bis zum reinen Aritmetikshader.

In der letzten Kurve überprüfen wir noch, wie sich der NV35 bei der direkten Benutzung von 1.4 und 2.0 PixelShadern in der von ATi bevorzugten Form verhält. Da in diesem Fall entweder 8 Textur oder 8 Aritmetik-Operationen pro Takt durchgeführt werden können, haben wir eine konstante Linie bei 3600 MI/s. Ab einem Verhältnis von 1:6 ist der NV35 nun also auch in ungünstigen Situationen in der Lage, den R350 zu schlagen.

Werden beide Chips mit an ihre Architektur angepassten Shadercode betrieben steht der NV35 auch wesentlich besser als sein Vorgänger da. Bis zu einem Verhältnis von 2:1 kann der NV35 hier seine höhere Taktrate ausspielen. Ab einen Verhältnis von 1:3 kommt dann der Vorteil der Universal FPU in Verbindung mit dem höheren Takt zum tragen. In dem Bereich dazwischen hilft dem NV35 aber auch der höhere Takt nicht mehr, um mit 8 FPUs gegen die 16 FPUs den R350 anzukommen.

Die zum Vergleich eingefügte R300 Kurve zeigt, daß sogar dieser im Bereich um das 1:1 Verhältniss den NV35 noch schlagen kann. Berücksichtigen wir nun noch den im Vergleich zum NV35 größere Einbruch des R350 bei "dependent reads", kann man davon ausgehen, dass wir es beim NV35 und R350 mit gleichwertigen Konkurrenten zu tun haben, solange beide mit dem ihrer Architektur angemessenen Shadercode laufen können.

nVidia wird aber der Tatsache ins Auge sehen müssen, das sie nicht immer damit rechnen können, dass die Anwendung diesen Code liefert (im Falle der PS 1.4 ist dies sogar eine Gewissheit). Deswegen können wir hier unsere Forderung nur wiederholen, dass nVidia im Treiber eine Möglichkeit einbauen muss, die Shader für ihre Ansprüche umstrukturiert, ohne allerdings die Funktion zu ändern. Das Verfahren, das die aktuellen Treiber benutzen, mag als Übergangsnotlösung noch akzeptabel sein, solange die Anzahl der Applikationen überschaubar ist, welche für CineFX ungünstigen Pixelshadercode enthalten. Mit zunehmender Anzahl von Titeln, welche die neue Technologie nutzen, kann es jedoch nicht angehen, dass Nutzer von GeForceFX Karten jedes Mal erst auf Treiber warten müssen, die entsprechende Austauschshader enthalten.