ATI Radeon HD 2900 XT Review

14. Mai 2007 / von robbitop (Text, Benchmarks) & BlackBirdSR (Bildqualitäts-Betrachtungen) / Seite 2 von 19

   Der R600-Grafikchip

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.

	ATI Radeon HD 2900 XT	nVidia GeForce 8800 GTX
MAD Leistung	473 GFlops/sec	345 GFlops/sec

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.

	ATI Radeon HD 2900 XT	nVidia GeForce 8800 GTX
FX8 bilinear	11840 Mtex/s	18400 Mtex/s
FX8 trilinear	5920 Mtex/s	18400 Mtex/s
FP16 bilinear	11840 Mtex/s	18400 Mtex/s
FP16 trilinear	5920 Mtex/s	9200 Mtex/s

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.

 

   Das neue Anti-Aliasing

Jahre nach der Vorstellung des R300-Chips (Radeon 9500/9700) bohrt ATI beim R600-Chip das Raster des Trisetup von einer 12x12 Maske auf eine 16x16 Maske auf. Damit ist nun ein achtfaches Sparsed Grid Multisampling Anti-Aliasing, kurz SG-MSAA, möglich. Dank dem 512 Bit breiten Speicherinterface kann dieses auch mit akzeptabler Leistung umgesetzt werden.

Völlig neu hingegen ist das "Custom Filter Anti-Aliasing" (CFAA). Das Funktionsprinzip ist hierbei simpel: Mittels eines Shaders werden einfach bis zu 12 Subsamples von Nachbarpixeln "geborgt", das kostet schließlich kaum extra Rechenleistung und Bandbreite. Doch kennen wir das nicht irgendwoher? Klar, der "Weichzeichner" Quincunx seitens nVidia wird dem Leser jetzt durch den Kopf schiessen. Doch das ist so nicht ganz korrekt: Das Einbeziehen von Informationen von Nachbarpixeln durch CFAA führt zu einem gewissen Blurfilter, welcher aber in der Praxis deutlich geringer ist als beim Quincunx-Verfahren.

Der Filterkernel nutzt nämlich nur Randsubpixel der Nachbarsamples, der Blureffekt ist also deutlich kleiner. Man hat zusätzlich zur Anti-Aliasing Stufe die Wahl zwischen drei Filterarten: Narrow Tent, Wide Tent und Edge Detection. Der Wide Tent Filter bezieht mehr Subpixel von Nachbarpixeln ein als der Narrow Tentfilter, dies bedeutet allerdings auch einen stärkeren Blureffekt. Wir halten den Nutzen dieser beiden Filter für fragwürdig, da man somit zwar einen stärkeren Kantenglättungseffekt hat, jedoch die hart erarbeiteten Texturen-Bildinformationen wieder ruiniert werden. Dafür kosten diese Modi aber auch nur sehr wenig Performance.

Edge Detection hingegen wendet das Blur-Verfahren gezielt da an, wo es sinnvoll ist. Dazu wird das Bild nachträglich nach Polygonkanten abgesucht. Das geschieht, indem man sich die Eigenheit des Multisampling-Verfahrens zunutze macht: Pixel für Pixel werden über die ROPs in die Shader eingelesen. Diese vergleichen dann die Farbinformation der Subpixel: Ist die Subpixelfarbe der Samples pro Pixel gleich, so handelt es sich nicht um eine Polygonkante und CFAA wird nicht angewendet. Unterscheiden sich die Farbwerte hingegen, so wird CFAA angewandt.

Diese Resolvefunktionen im Shader sind natürlich nicht kostenlos. Es kostet Rechenleistung, ein wenig Bandbreite und ROP-Leistung. Da wir dieses "Edge Detection" Verfahren als sinnvoll erkannten und wie bereits erwähnt von der resultierenden Bildqualität positiv überrascht sind, verwendeten wir dieses Verfahren in unseren Benchmarks gegen das Coverage Sample Verfahren von nVidia. Das CFAA ist allerdings auf den Radeon-Karten der Vorgängergeneration nicht nutzbar, da dessen ROPs nicht die Fähigkeit besitzen, Samples an die Shader zu übergeben.

Da der Edge Detection Modus erst seit dem 8.3742er Treiber, welcher erst seit letztem Freitag verfügbar ist, über ein separates Tool aktivierbar ist, gehört 3DCenter vermutlich zu den wenigen Redaktionen, die diesen Modus überhaupt testen können. Das Fazit im Bildqualitäts- und im Benchmarkteil ist somit natürlich ein völlig anderes.

Ein weiterer Treiber-Fauxpas scheint andere Testredaktionen ebenfalls zu treffen: Im früheren 8.3740er Treiber war das Adaptive Anti-Aliasing laut ATI von einem Bug betroffen, welcher den R600-Chip enorm an Performance kostete. Laut unseren Beobachtungen und Messungen wurde erst in dem von uns verwendeten Treiber AAA durch ein Multisampling-Verfahren (genannt EATM) ersetzt. Dabei ist die Bildqualität für einen solchen Multisampling-Modus sehr gut, jedoch läßt derzeit die Kompatibilität noch zu wünschen übrig. Aus diesen Gründen hielten wir Leistungsmessungen mit Transparenz Anti-Aliasing zu diesem Zeitpunkt nicht für sinnvoll und haben dieses Feature nachfolgend auch nicht bei unseren Benchmarks eingesetzt.