CineFX (NV30) Inside

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

   Die Zukunft von CineFX und CineFX II

Nachdem schon unsere Betrachtung von CineFX II (NV35) zu einem nicht unerheblichen Teil auf begründeten Spekulationen aufbaute, begeben wir uns nun völlig auf diese Gebiet. Darum können wir nun ab diesem Punkt überhaupt keine Garantie mehr geben, das wir in allen Punkten richtig liegen.

Werfen wir zuerst einen Blick auf die nähere Zukunft: Auf der Hardwareseite sind hier noch NV36 und NV38 im Gespräch. Aber darüber wird schon an anderer Stellen genügend spekuliert. Um aber dennoch eine Aussage in diese Richtung zu treffen, gehen wir davon aus, das alle neuen Chips der NV3X Serie, welche noch erscheinen werden, mit einer CineFX II Pixelengine ausgestattet sein werden.

Auf der Softwareseite erwartet uns noch der von vielen erwarte und schon als "Wundertreiber" titulierte Detonator 50. Gerüstet mit etwas mehr technischem Hintergrund zu CineFX und CineFX II wagen wir nun eine Spekulation, was dieser Treiber leisten könnte. Schauen wir zuerst einmal, was die derzeit verfügbaren Treiber der 4X.XX Reihe allem Anschein nach tun, wenn sie einen Pixelshader übergeben bekommen.

Bei den Shadern bis einschließlich 1.3 benutzt man im großen und ganzen die schon für die GF4 Ti verwendeten Verfahren. Shader, welche die GF4 Ti nicht beherrscht, werden anders behandelt. Gehört ein solcher Shader zu einer ausgewählten Gruppe von Programmen, die nVidia für wichtig hält, so wurde dafür im Treiber bereits eine optimierte Version hinterlegt welche dann zum Einsatz kommt. Alle anderen Shader müssen sich mit einer eins zu eins Übersetzung begnügen.

Hier kommt auch nun die erste Möglichkeit für nVidia, die Ausnutzung der ja nicht unbedingt großzügig vorhanden Shaderleistung zu verbessern. Versuche mit einem neuen Shadercompiler haben gezeigt, dass sich bei den meisten Shadern eine für CineFX günstigere Ausgangslage erreichen lässt. Im Gegensatz zur alten Version, welche nur das ATi-Shadermodel unterstütze, kommt der neue Compiler mit weniger Temp-Registern aus und erzeugt auch die von CineFX bevorzugte Instruktionsfolge welche Texturinstruktionen paarweise anordnet.

Auch CineFX II wurde bereits berücksichtigt, indem auf 2 Texturinstruktionen nach Möglichkeit mindestens immer eine Arithmetikinstruktion folgt. Von dieser Vorgehensweise profitiert aber auch so wie es scheint die CineFX I Einheit. Die Loopback-Steuerung des Shader Corse lässt sich also wahrscheinlich auch dazu benutzten, mehrer Shaderinstruktionen direkt hintereinander auszuführen, ohne auf den großen Loopback über die gesamte Pipeline angewiesen zu sein. Da dieser Loopback ja pro Quadgruppe immer mit mindestens einem zusätzlichen Takt bestraft wird, ist eine mögliche Reduktion der großen Loopbacks wünschenswert.

Als weiteren Service nutzt der neue Compiler auch die erweiterten Fähigkeiten von CineFX gegenüber Smartshader II, um den gleichen Effekt mit weniger Anweisungen zu erreichen. Der Praxistest mit einer frühen Version dieses neuen Compilers zeigte, dass alleine durch diese Maßnahmen ohne Veränderungen am Treiber in Einzelfällen eine bis zu 40% höhere Framerate erreicht werden konnte. Der Einsatz dieses Compilers ist allerdings eine Sache der Softwareentwickler, nVidia sollte da nicht immer auf Kooperation hoffen. Allerdings sollten sich ein Großteil der Techniken, welche dort zum Einsatz kommen, auch auf innerhalb des Treibers auf bereits nach dem ATi-Model kompilierten Shader anwenden lassen, um diese CineFX-freundlicher zu machen.

Tauchen wir nun noch tiefer, findet sich eine weitere Leistungsquelle, die der Treiber unter Umständen noch anzapfen könnte. nVidia folgte beim Design von CineFX einer Kombination aus VLIW (Very Large Instruction Word) und SIMD (Single Instruction Multiple Data). Auf viele Daten (hier 4 Pixel) wird in einem Schritt eine große Anzahl von einzelnen Rechenoperationen auf vielen Recheneinheiten durchgeführt. Für eine Grafikkarte auf Pixelshader 2.X-Level ohne dynamisches Branching ist dieser Ansatz geradezu ideal.

Der SIMD-Anteil des Designs spart Transistoren dadurch, dass eine Verdoppelung der Steuerlogik für jedes einzelne Datenpaket, welches durch die Pipelines läuft, entfällt. Der VLIW Anteil macht einen Instruction Sequencer überflüssig. Wenn man bedenkt, dass bei modernen Chips alleine dieser Sequenzer oft mehr als die Hälfte des Transistoren innerhalb der Executions-Pipeline braucht, dürfte verständlich sein, warum man diesen Teil einer modernen CPU nicht in eine GPU übernehmen wollte.

Natürlich wären die Vorteile eines Instruction Sequencer auch für eine GPU eine schöne Sache. Die Gewissheit, dass sich der Chip selbst um eine möglichst hohe Auslastung aller seiner Recheneinheiten kümmert, würde den Treiberentwicklern sicherlich weniger schlaflose Nächte bereiten. Aber die Frage, ob man für diese Sache bereit ist, auf die Hälfte der Shaderleistung zu verzichten (will man die Transistoren dafür ja einsparen), dürfte leicht zu beantworten sein.

Neben den Vorteilen wollen wir hier auch nicht die Nachteile unerwähnt lassen. Bei SIMD verliert man immer dann Rechenleistung, wenn nicht alle Daten innerhalb eines Blocks genutzt werden können. So kann es am Rand eines Dreiecks durchaus vorkommen, dass nur einer der vier Pixel wirklich genutzt werden kann, womit uns das SIMD einen direkten Verlust von 75% der Rechenleistung beschert.

Bei einer VLIW-Architektur wird man mit zwei Problemen konfrontiert: Zum einen ist ein Compiler unerlässlich, welcher im Vorfeld die ideale Nutzung der Recheneinheiten ermittelt und dafür den richtigen Steuercode erzeugt. Die Möglichkeit einer CPU, schlechten Code einfach etwas umzusortieren, um die Auslastung zu verbessern, hat man bei einer reinen VLIW-Architektur nicht. Als weiteren Punkt muss man noch aufführen, dass sich das "Very large" auch auf die Größe des Programmcodes auswirkt.

Möglicherweise ist das auch der Grund, warum nVidia den Pixelshadercode im RAM der Grafikkarte speichert. Über den breiteren Datenbus lässt sich ein Programm viel schneller einladen. Hierzu noch ein kleines interessantes Detail: Zum Einladen von Pixelshaderprogrammen wird die bereits über die TMUs vorhandene Verbindung der Pixelpipeline zum Speicher benutzt. nVidia wollte scheinbar für diese relative selten durchgeführte Operation des Programmwechsels keine eigene Einheit verbauen, um Transitoren zu sparen. Interessant dabei ist sicherlich noch die Frage, ob der Texturencache auch für Pixelshaderprogramme benutzt wird.

Diese ausführliche Erklärung hatte natürlich einen Grund. Den SIMD-Aspekt kann kein noch so guter Treiber zur Performancesteigerung nutzen, aber beim VLIW Teil sehen die Möglichkeiten besser aus. VLIW braucht wie erwähnt einen guten Compiler und dieser scheint den 4X.XX Treiber vollkommen zu fehlen. Allen Anschein nach wird derzeit einfach eine Pixelshaderanweisung in ein oder mehrere Instruktionswörter umgesetzt. Die einzige Ausnahme bilden Texturenoperationen, von denen zwei zu einem Instruktionswort zusammengefasst werden können.

Gerade bei reinen Skalaroperationen bleibt dabei der größte Teil der Rechenleistung ungenutzt. Wir wollen hiermit nun keine falschen Hoffnungen wecken, weil uns keinerlei verlässliche Informationen darüber vorliegen, wie flexibel der VLIW-Aspekt der CineFX Pipeline wirklich ist. Möglicherweise bezog sich aber die Andeutung eines nVidia Mitarbeiters, das man noch viele Möglichkeiten hätte, die Shaderperformance zu steigern, ohne dafür geringere Genauigkeit gehen zu müssen, auf genau diesen Punkt. Damit wollen wir unsere Überlegungen zum Performancesteigerung durch den Treiber auch beenden und noch einen Blick in die weitere Zukunft werfen.

   CineFX und NV40

nVidia hat zwar bereits groß angekündigt, der NV40 würde über eine völlig neue Architektur verfügen, aber wir glauben ja schon lange nicht mehr alles, was die IHVs erzählen. Darum lautet das Thema unseres letzen Gedankenspiels: "Hat CineFX eine Zukunft in der NV4X-Reihe?"

Um diese Frage zu beantworten, ist es wichtig, die Zielvorstellungen von nVidia für die NV4X Chips zu kennen. Trotz der durchaus dünnen Informationslage zu diesem Thema darf mit hoher Wahrscheinlichkeit angenommen werden, dass man Pixelshader 3.0 Konformität erreichen möchte. Im wesentlichen fehlt CineFX dafür die Möglichkeit, den Programmablauf bedingt durch aktuelle Rechenwerte (oder Konstanten) zu verändern.

In dem Patent wird der Pipeline nun die Fähigkeit zugesprochen, das einzelne Quads zu jeder Zeit die Pipeline verlassen können und durch neue ersetzt werden. Im Zusammenhang damit wird auch erwähnt, dass für unterschiedliche Quads unterschiedliche Programme oder unterschiedliche Teile des gleichen Programms gerade aktiv sein können. Es scheint nur noch eine Möglichkeit zu fehlen, an einer Stelle innerhalb der Pipeline die Programmzeiger gezielt zu verändern. Damit würden Sprünge innerhalb des Programms möglich.

Ein solcher bedingter Programmsprung stellt dabei die Grundlage für die von der Pixelshader 3.0 Spezifikation geforderten Möglichkeiten zur Schleifenbildung, Entscheidungen und Unterprogrammaufrufen dar. Da aber unter diesen Bedingungen nicht mehr gewährleistet werden kann, dass alle 4 Pixel eines Quads den gleichen Weg durch den Programmcode nehmen, wird man sich wohl von dem SIMD Ansatz lösen und für jeden Pixel eine unabhängige Pipeline benutzen.

Die technische Machbarkeit ist also durchaus gegeben, aber der Begriff CineFX wird in Verbindung mit dem NV40 wohl trotzdem nicht mehr genutzt werden. Die Grundtechnik hat aber nach unserer Meinung eine gute Chance, es in die nächste Runde zu schaffen.

Wir sind nun am Endes unseres Trips durch die Welt von CineFX angekommen und es bleibt uns nur noch ein paar Danksagungen auszusprechen. Zunächst einmal all den Lesern die es bis hierher geschafft haben. Dann natürlich all denen die in irgendeiner Form zu diesem Artikel beigetragen haben. Es waren zu viele als das man sie einzeln aufzählen könnte. Weitere Danksagungen: nVidia dafür, dass sie CineFX entwickelt haben, so dass wir darüber schreiben konnten. Und ATi für das R300 Design, dass nVidia zum nachlegen mit CineFX II gezwungen hat.