Der R600-Chip verfügt über vier SIMD Quad-Pipelines, welche jeweils mit 16 ALUs bestückt sind, jede ALU verfügt dabei über fünf Komponenten. Wie auch nVidia beim G80-Chip spricht ATI hierbei von einem skalaren Aufbau der Pipelines. Genau genommen entspricht das jedoch nicht der Wahrheit. Der SFU-Kanal arbeitet tatsächlich "vertikal" skalar. Der Vec4-Teil der ALU, hier als RGBA aufgeführt, ist eine "horizontale" SIMD-Einheit. Um zu verstehen, was daran besonders ist, werfen wir einen Blick auf eine ALU aus der letzten Generation (z.B. Xenos):

Als Input kommen hintereinander vier Pixel (in vier Takten) mit bis zu vier Komponenten und einer SFU (z.B. Sinus, Cosinus, Reziproke ect) in die ALU. Pro Takt berechnet die ALU also einen Pixel mit allen Komponenten. Der Nachteil dieser Methode ist offensichtlich: Nicht immer gibt es pro Takt und Pixel genügend Instruktionen, um alle Kanäle zu füllen. Die Einheiten werden also im Durchschnitt nicht optimal ausgelastet.

Die neuen R600-ALUs arbeiten hingegen anders. Als Input fallen pro Takt gleichzeitig vier Pixel an. Wie zuvor in der Abbildung dargestellt, braucht die Xenos-ALU jedoch bis zu vier Takte, um die Berechnungen für die vier Pixel durchzuführen – nacheinander werden alle Kanäle der vier Pixel berechnet. Die neue skalare SFU-ALU springt hingegen von Takt zu Takt zu den Registern der unterschiedlichen Kanäle hin und her. Am Ende sind auch die bis zu vier zugehörigen skalaren SFUs fertig.

Der Vorteil dieser Methode ist dann gegeben, wenn weniger unabhängige Instruktionen pro Takt und Pixel anfallen, als Kanäle verfügbar sind. In diesem Falle rechnet die ALU so lange, bis die Rechenoperation der vier Pixel benötigt wird. Es kann also Rechenzeit gespart werden, die Auslastung der ALUs ist somit besser.

Allerdings hat diese Methode den Nachteil, dass die Kontrolllogik deutlich mehr Transistoren kostet. Im Gegensatz zum G80-Chip hat man hier beim R600-Chip etwas gespart und gleich 16 dieser ALUs in einem SIMD verschaltet. Die Granularität und damit auch die Effizienz sinkt damit. Im Gegenzug konnte man jedoch eine höhere Anzahl an Rechenwerken verbauen. Der G80-Chip nutzt hier einen Trick aus der Fertigung, der bei CPUs gang und gebe ist: Durch "handoptimierte" Transistoren kann nVidia die ALUs deutlich höher takten.

Der R600-Chip scheint eine deutlich höhere MAD-Rohleistung zu haben. Zieht man allerdings die skalaren SFUs ab (welche beim G80-Chip durch die MUL-ALU erledigt werden), können diese kein MAD mehr zur Rechenleistung beisteuern. Dann ist die rechnerische Endleistung bei beiden Chips beinahe gleich. Wie die effektive Rechenleistung zustande kommt, ist eine reine Designentscheidung. Die Balance zwischen einer Vielzahl günstiger ALUs und einer geringeren Anzahl komplexer und effektiver ALUs entscheidet über die Endleistung.

Ein Beispiel: Der R580-Chip hat eine theoretische MAD-Rechenleistung von 306 GFlops/sec, die Vertexshader-Leistung wurde dabei miteinbezogen. Der G80-Chip hat hingegen eine theoretische MAD-Rechenleistung von 345 GFlops/sec. Letzterer verfügt jedoch dank seiner guten Auslastung in etwa über die doppelte effektive Rechenleistung.

Damit die teuer erkauften ALUs nicht auf profane Dinge wie die Texturfilterung warten müssen, muss genug Texturfüllrate vorhanden sein. Der R600-Chip bietet pro Takt 16 bilinear gefilterte Texel an. Das klingt zunächst nach keiner Steigerung gegenüber dem Vorgängermodel. Jedoch wurde der R600-Chip für HDR-Rendering entworfen. Die TMUs brechen im Gegensatz zu den G80-TMUs nicht durch die Filterung von Texturen ein, die im FP16-Format vorliegen. Auch das Speicherinterface bietet dank der 512-Bit-Anbindung genug Bandbreite für FP16-Texturen und den FP16-Framebuffer. Natürlich beherrschen die neuen TMUs auch das FP32-Texturformat. Dies ist dann allerdings mit einer Halbierung der Füllrate verbunden.

Wie man sieht, ist die Rohfüllrate des R600-Chips in allen Fällen geringer. Allerdings ist hier noch nicht mit einberechnet, dass der R600-Chip noch über 16 zusätzliche Pointsampling-TMUs verfügt. Diese werden für Pixel- und Vertexfetches genutzt. In zukünftigen Applikationen kommen noch Berechnungen von komplexeren Matrizen oder 2D-Kernel-Filter hinzu. All dies benötigt keine gefilterten Texturwerte und kann somit auf die Point-Sampling-TMUs ausgelagert werden. Das schmälert die effektive Füllrate des R600-Chips dann nicht – im Gegensatz zum G80-Chip.

Die Texturcaches des R600 belaufen sich auf 1x 256 kiB für den Level2-Cache sowie 4x 32 kiB für die Level1-Caches und sind damit ungewöhnlich groß bemessen. Inwiefern das die effektive Texturfüllrate verbessert, ist uns jedoch nicht bekannt. Am Ende des Tages ist die effektive Füllrate des R600-Chips auch unter HDR-R Bedingungen nicht von schlechten Eltern, jedoch ist sie der Füllrate eines G80-Chip im Vollausbau nicht gewachsen.

Um die berechneten Pixel auch auf die Straße bringen zu können, wurden die ROPs des R600-Chips deutlich aufgebohrt. Der R600 besitzt 64 Z/Stencil Units. Allerdings kann er maximal 32 Z/Stencil Werte pro Takt in den Framebuffer schreiben. Jedoch können die ROPs dennoch nebenbei für HSR und Farbe genutzt werden. Bei bis zu einem vierfachen Multisampling Anti-Aliasing bricht die ROP-Leistung also nicht unter die Pixelfüllrate von 16 Pixeln pro Takt ein. Damit ist der R600-Chip wie auch der G80-Chip für die Nutzung von vierfachem Anti-Aliasing optimiert.

Natürlich ist die ROP-Leistung des G80 mit 192 Z-Compare Units deutlich höher als die ROP-Leistung des R600. Dies dürfte in Spielen jedoch relativ selten zum Tragen kommen. Einerseits lastet der R600-Chip die ROPs wahrscheinlich weniger aus, da er über weniger Rohtexelfüllrate verfügt als der G80, und andererseits kostet ein ROP-Loop nur einen Takt. Verglichen mit dem dreistelligen Taktbereich zur Berechnung eines Pixels ist das verschwindend gering.