Ein erster Blick auf die R520-Architektur

5. Oktober 2005 / von aths / Seite 1 von 3

16 Pipelines, Shader Model 3: Das sind seit längerem bekannte Eckdaten des R520. Wir versuchen heute, etwas tiefer zu blicken, im Wissen dass sich einige interessante Details erst durch spätere Tests ermitteln lassen.

Auf den ersten Blick müsste der R520 etwa gleich stark wie der G70 sein: Was der G70 mehr an Pipelines hat, gleicht der R520 durch den Mehrtakt wieder aus. Allerdings kommt es natürlich nicht nur auf die Zahl der Pipes an, sondern darauf, was der Chip ingesamt berechnen kann. Zunächst soll die Pixelpipeline im R520 besprochen werden, danach betrachten wir die Effizienz – um uns anschließend dem wichtigsten zuzuwenden, der Bildqualität.

   Die Pixelpipeline

Zur Begriffsklärung: Ein Quad besteht aus 2x2 Pixeln. Seit Jahren berechnen 3D-Karten keine einzelnen Pixel mehr, sondern immer Quads, also vier Pixel gleichzeitig. Das gilt auch für Karten, die nur zwei Pixelpipes haben: Dort dauert eine Operation auf das Quad eben zwei Takte.

"R520" – die Ähnlichkeit im Namen zum R420 ist nicht ohne Grund: Der R520 lässt deutlich seine R420-Verwandschaft erkennen. Dies betrifft nicht nur die Anzahl der Pixel-Pipes (weiterhin vier Quadpipes, die einzeln abschaltbar sind) sondern auch den Aufbau der ALU. Die ALU übernimmt die arithmetischen Rechnungen im Pixelshader, verrechnet also Farben und andere Daten.

Über die Performance entscheidet insbesondere die MAD-Leistung (Multiply-Add). Eine Pipeline im R520 kann nach wie vor nur ein MAD4 (also MAD mit jeweils 4 Kanälen Input und Output) pro Takt berechnen. Falls eine Vektor-Operation mit bis zu drei Komponenten und eine skalare MAD-Operation (mit nur einem Kanal) auftreten, können diese beiden im gleichen Takt ausgeführt werden – der berühmte Color:Alpha-Split im Combiner. Nach wie vor gibt es also den Vektor-Combiner (vor allem für Farb-Rechnungen) und den getrennten skalaren Combiner (für andere Rechnungen), welcher übrigens auch die SFUs übernimmt.

SFUs sind "Special Functions" wie zum Beispiel Sinus. Im Gegensatz zum R420 sind zumindest einige SFUs, wie zum Beispiel der Sinus, beschleunigt worden, so dass sie keine acht Takte mehr benötigen sollten. Details hierzu werden in der Zukunft sicherlich noch herauskommen. Die CineFX-Architektur der GeForce-Karten bietet von vornherein einen Sinus für 2-3 Takten. Denkbar ist im R520 eine Beschleunigung auf einen Takt, doch hier müssen wir erst unabhängige Benchmarks abwarten.

Die Combiner im NV40 und G70 sind nicht wie in der Radeon vertikal getrennt, können aber im gleichen Takt trotzdem bis zu zwei Befehle abarbeiten, solange die Anzahl der Kanäle der gebündelten Befehle höchstens vier beträgt. Das heißt, dass der NV40 und G70 auch ein 2:2-Paar (z. B. DP2, DP2 oder ADD2, MUL2) bündeln kann, was der R520 nicht beherrscht.

SM3 verlangt FP32-Präzision im Pixelshader. Der NV40 und G70 gewinnt durch Nutzung von FP16-Präzision Geschwindigkeit, überwiegend aus zwei Gründen: Erstens wird die interne Bandbreite nicht so stark beansprucht und zweitens werden die Registerspeicher nicht so stark belastet. Ob ATI die interne Bandbreite von vornherein für durchgehenden FP32-Einsatz ausgelegt hat, wissen wir noch nicht, aber man kann es zumindest vermuten.

Nun spricht ATI von 4 arithmetischen Operationen pro Takt. Zwei davon haben wir schon genannt: MAD3 und MAD1/SFU. Zusätzlich gibt es eine "Mini-ALU", die bietet ein ADD3 und ADD1, sowie bestimmte Skalierungsoperationen um Zweierpotenzen – die Mini-Alu kann also im Prinzip das gleiche wie beim R300, nur eben in FP32-Genauigkeit.

Auf den ersten Blick erinnert die ALU-Struktur des R300/R420/R520 an den NV40, nur dass Nvidia eben MUL statt ADD in einer kleineren Shader-Unit bietet. Aber der NV40 hat natürlich auch Pipeline-Stages für Zweierpotenzen-Skalierungsoperationen, diese Stages werden von Nvidia nur nicht extra genannt. Außerdem gibt es seit NV40 die Einheit für NRM_PP, welche in Partial Precision (FP16) pro Takt eine Normalisierungs-Operation ausführen kann. Das ist insbesondere beim Bumpmapping hilfreich, um die "normalen" ALUs zu entlasten und die Berechnung zu beschleunigen.

Lange Rede, kurzer Sinn: Der G70, mit der gegenüber der NV40 erweiterten Pipeline, bietet bekanntlich sogar zwei volle MAD4-Operationen pro Takt und könnte damit in erster Näherung pro Takt und Pipeline als deutlich stärker im Vergleich zum R520 eingeschätzt werden. Der NV40 hat übertriebene MUL-Kraft (und kann schon pro Takt und Pipe mehr berechnen als der R420), der R520 hat übertriebene ADD-Kraft, den G70 halten wir für sehr ausgewogen. Doch ganz so einfach ist es nicht.

Ein Pixelshader-Programm darf nach der Optimierung durch den Treiber nicht mehr als bis zu vier Temp-Register gleichzeitig nutzen, um auf dem G70 noch in voller Geschwindigkeit zu laufen. Solche Probleme kennen R300 und R420 nicht: Die können nach unseren Informationen bis zu 12 Temps gleichzeitig belegen, ohne dass es deswegen einen Slowdown gibt. Dies erleichtert die Optimierung des Shaders erheblich. Wie viele Temps der R520 physikalisch zur Verfügung stellt wissen wir nicht, jedoch ist mit Problemen à la G70 nicht zu rechnen. Die Anzahl der physikalisch zur Verfügung stehenden Temp-Register ist außerdem abhängig von der Zahl der Threads – zu den Threads später mehr.

Praktisch kein Problem mit der limitierten Zahl temporärer Register zu haben heißt: Bestimmter "blöder" Shadercode ist recht einfach optimierbar. Doch es kommt noch besser: Aufgrund des Phasenkonzepts (Aufteilung in reine Sampling- und reine Rechenphasen, eine Phase besteht aus dem Sampling und anschließender Verrechnung) kann die Radeon den Pixelshader-Code grundsätzlich so optimieren, dass mögliche Texelfüllratenlimitierung die Shader-Berechnung nur so weit ausbremst, wie es dem Verhältnis von Sampling-Takten zu Rechen-Takten entspricht (das gilt jedenfalls auf eine einzelne Phase bezogen). Bei CineFX hingegen kann es zu zusätzlichen Wartetakten kommen, weil Sampling und arithmetische Rechnungen ineinander verzahnt sind.

ATI hat es dabei aber nicht belassen, sondern stattete den R520 mit einem Threading-Algorithmus aus. Das heißt, neue Quads, die berechnet werden müssen, kommen in die am wenigsten belastete Pipeline. Das bietet Nvidia im Prinzip auch, jedoch ist das Optimierungspotenzial im R520 größer: Sobald eine Quadpipe freie Kapazität hat, bekommt sie einen neuen Thread. Wenn also nicht gerechnet werden kann, weil das Textursampling noch nicht abgeschlossen ist, wird der Thread "schlafen gelegt", und die Pipeline rechnet dann erst einmal an an einem anderen Thread. Ist das Textursample endlich fertig, wird der Thread wieder "aufgeweckt" und rechnet weiter. Damit lassen sich Textursampling-Latenzen hervorragend verstecken – jedenfalls bis zu einer bestimmten Grenze.

Der R520 zerteilt nach unseren Informationen die Quads in sehr kleinen Batches von lediglich 2x2 Quads ein, und unterstützt bis zu 512 Threads, kleinere Modelle bieten bis zu 128 Threads. Threading macht eine Art Hardware-Sheduler notwendig, ist jedoch mit Thread-Programmierung auf der CPU keineswegs vergleichbar. Wir haben bezüglich Threading noch keine genauen Informationen – und bitten deshalb, unsere Äußerungen dazu cum grano salis zu nehmen. Die TMUs sind bei der R5xx-Architektur entkoppelt, das ist wichtiger Schritt zur Auflösung der traditionellen Pipeline-Architektur.

Der R520 bietet eine Branch-Unit – ATI tut so, als hätte die Konkurrenz das nicht. Natürlich benötigen auch NV40 und G70 entsprechende Hardware, um dynamische Verzweigungen zu erlauben, allerdings führt dort jeder Befehl einer solchen dynamischen Verzweigungsstruktur zu mindestens zwei Takten, in denen nicht gerechnet werden kann. Das scheint ATI besser gelöst zu haben. Allerdings kommt es auf diese zwei Takte so sehr nicht an, entscheidend ist beim R520 die sehr kleine Batch-Größe von gerade mal vier Quads – beim G70 schätzen wir die Granularität auf etwa 256 Quads.

Das heißt im Klartext: Die Wahrscheinlichkeit, durch Branching tatsächlich Rechenzeit zu sparen, ist beim R520 deutlich größer. Denn bei 256 gleichzeitig in Bearbeitung befindlichen Quads im NV40/G70 ist die Wahrscheinlichkeit, dass beide Verzweigungen durchlaufen werden müssen, und man letztlich nichts spart, viel größer als bei nur vier Quads in der Pipe.

   Die Vertexpipeline

Zur Vertexshader-Pipeline haben wir noch keine genauen Informationen. Wir vermuten stark, dass ATI endlich unabhängige Vertexshader entwickelt hat. R420 zum Beispiel hat nur einen Vertexshader, der aber sechs Vertices pro Takt berechnen kann, für die alle das gleiche Vertexshader-Programm gilt. NV40 hat ebenfalls sechs Vertexshader, für die gilt ebenfalls immer dasselbe Vertexshader-Programm – jedoch dürfen sich die Programme während der Abarbeitung im gleichen Takt an unterschiedlicher Stelle befinden. Im NV40 und G70 lassen sich jedoch auch einzelne Vertexshader abschalten. Das ist beim R420 noch anders – ein Ableger mit 8 oder gar nur 4 Pixelpipes hat trotzdem seinen sechsfachen Vertexshader.

Der Vertexshader im R520 wurde in jedem Fall SM3-tauglich gemacht, wir wissen jedoch nicht, wie zum Beispiel das Vertex-Texturing gelöst wurde. Da bleibt uns nur das Warten auf entsprechende Informationen. Traditionell bieten Vertexshader einen Vektor4-Kanal und einen skalaren Kanal für Rechnungen. Radeon-Karten können auch im skalaren Kanal MAD-Operationen ausführen, bisherige Nvidia-Karten bieten das nicht – pro Takt und Vertexpipe ist der Vertexshader im Radeon also rechenkräftiger.

Die nun 8 Vertexshader bei einem Takt um die 600 MHz herum bieten im Vergleich zum G70 (ebenfalls 8 Vertexpipes, jedoch bei nur 470 MHz) also ein erhebliches Leistungsplus in der Geometrie-Verarbeitung – wovon insbesondere der 3DMark profitiert. Spiele können mit der extremen Leistung weniger anfangen. Allerdings ist es immer besser, Vertexleistung verpuffen zu lassen als im Gegenteil Gefahr zu laufen, dass der im Aufbau vergleichsweise einfache Vertexshader die teuren Pixelshader-Einheiten limitieren könnte.