ATi Radeon HD 2900 XT im Test: Platzhirsch oder kleiner Bruder der GeForce 8800?

Technik im Detail Part 2

Raster Operation Processor (ROP):
Die Raster Operation Processors hat ATi mit dem R600 gegenüber den Derivaten auf dem R580 verbessert. Abgesehen von dem neuen 8xMulti-Sampling-Anti-Aliasing können die ROPs auf dem R600 nun mehr Tiefen/Z-Tests (Sichtbarkeitsprüfung, Tiefentests) durchführen. Auf dem R600 setzt ATi insgesamt 16 ROPs ein, die Z-Tests für 32 Pixel pro Takt ausführen können. Da sowohl auf dem RV630 als auch auf dem RV610 vier ROPs vorhanden sind, ist die Anzahl der Z-Tests logischerweise auf acht Pixel pro Takt geviertelt. Im Vergleich dazu konnten die 16 ROPs im R580 nur für 16 Pixel einen Tiefentest durchführen. Ebenso wurde in gewissen Teilbereichen die Effizienz der ROPs stark verbessert. Das Render-to-Texture-Verfahren soll nun um ein vielfaches schneller als auf einem R5x0 funktionieren, zudem können mit acht Multiple Render Targets (MRT) doppelt so viele MRTs inklusive 4xMSAA ausgeführt werden. Neben dem für Direct3D 10 vorgeschriebenen FP32-Blending können die ROPs auf dem R600 ein weiteres Floating-Point-Format (11:11:10) darstellen.

HierarchicalZ:
Wie bereits weiter oben erwähnt, kann der R600 nun effektivere Sichtbarkeitsprüfungen und Tiefentests durchführen, um nicht sichtbare Pixel zu verwerfen und somit Rechenzeit einzusparen. So wurde die Z- und Stencil-Kompression vom Verhältnis 8:1 auf 16:1 verdoppelt (128:1 bei 8xMSAA, da die ROPs mehr „Zeit“ haben, entsprechende Tests zu vollziehen) und die Z- und Stencil-Kompression wird nun separat ausgeführt. Somit soll die Effizienz verbessert werden. Durch die erweiterte Kompression sind Z-Tests nun ebenfalls in höheren Auflösungen als bei der „alten“ Chipgeneration (bis zu 2560x1600) möglich. Außerdem wird auf dem R600 ein Feature namens „Re-Z“ eingeführt, was es der GPU ermöglicht, den Z-Buffer zwei Mal zu kontrollieren; zuerst vor dem Pixelshader und das zweite Mal nach den Shader-Berechnungen. Darüber hinaus wurde unter anderem der HierarchialZ-Buffer verbessert, um die Stencil-Schatten-Geschwindigkeit zu erhöhen.

Speicherinterface:
Dass man mit einem 256 Bit breiten Speicherinterface bei einem modernen High-End-Beschleuniger nicht mehr weit kommen würde, war spätestens nach der Einführung der GeForce 8800 GTX mit ihrem 384 Bit Speicherinterface klar. ATi setzt mit dem R600 noch einen drauf und implementiert dem Chip ein 512 Bit breites Speicherinterface. Ermöglicht wird dies durch gleich acht 64 Bit breite Speicherkanäle und somit einer (aber nur leicht) schlechteren Effizienz gegenüber dem R580. Dieser hatte acht 32 Bit Kanäle implementiert. Laut ATi wäre das Chipdesign bei 16 32 Bit breiten Kanälen aber zu komplex geworden bei zu geringem Nutzen. Von den 16 Speicherbausteinen auf der Radeon HD 2900 XT (16 multipliziert mit 32 MB entspricht 512 MB – man kann durch die Nutzung von 64-MB-Speicherchips also ohne einen allzu großen Aufwand auf demselben PCB 1024 MB unterbringen) sind also immer zwei an einen Speicherkanal angeschlossen und kommunizieren durch diesen.

Bei dem R5x0 führte ATi einen Ringbus ein und stellte diesen als eine große Innovation vor. Ohne Zweifel, der Ringbus hat seine Vorteile (zum Beispiel ist dieser weniger Komplex als eine Crossbar und man kann einen Ringbus recht simpel erweitern), allerdings ist die schnellst mögliche Verbindung immer noch die altbekannte Crossbar, sprich die Punkt-zu-Punkt-Verbindung von Speicher- zu Speicherkanal. ATi hat mit der R600-Genration den Ringbus nun aber verbessert, auch wenn dieser logischerweise immer noch nicht an die Performance einer Crossbar heranreichen kann. So gibt es nun anstatt zwei vier Datenleitungen, die die Bits für den Speicher transportieren können. Um die Erweiterungsmöglichkeiten zu verbessern hat ATi die noch vorhandene Crossbarswitch entfernt.

Dynamic Branching:
Dynamic Branching wurde mit der Spezifikation des Shader-Models 3.0 (beziehungsweise dem Shader-Model 2.A) eingeführt und gewinnt bei neuen Grafikkarten immer mehr an Bedeutung, da Spieleprogrammierer gerne auf dieses Feature zurückgreifen. Dynamic Branching, oder auch Flow Control genannt, ist eine Sprunganweisung innerhalb eines Shadercodes. So kann man unter anderem mit einem if- oder when-Befehl eine gewisse Bedingung festlegen, wann welcher Shadercode ausgeführt, wann ein Shader abgebrochen oder wann ein gewisser Teil übersprungen werden soll. Wichtig ist es dabei immer eine feine Granularität zu haben, da ansonsten längst nicht für alle Pixel Dynamic Branching angewendet werden kann.

Bei einem R580 teilt der Dispatch Processor den Shadercode in einen 4x12 Pixel großen Block auf, was insgesamt 48 Pixel entspricht. Auf einem R600 ist die Granularität etwas geringer geworden, sprich die Effizienz ist nicht mehr ganz so gut. Diese liegt nun bei 64 Pixeln. Der G80 ist in der Lage, den Shader in einen 4x4 großen Pixelblock einzuteilen.

Tessellation-Einheit
Wohl mit das interessanteste, weil außergewöhnlichstes Detail in der R600-GPU ist die Tessellation-Einheit, die die Direct3D-10-Spezifikation eigentlich gar nicht vorsieht. Erst in Direct3D 11 wird eine Tessellation-Unit vorausgesetzt. In einer klassischen Architektur wäre der Tessellator noch vor dem Vertexshader implementiert. Nichtsdestotrotz soll es für Programmierer ohne größere Schwierigkeiten und ohne neue Anweisungen in der Shader-API möglich sein, den Tessellator anzusprechen. Wie genau das funktionieren soll, wollte uns ATi leider nicht mitteilen. Doch was macht eine Tessellation-Unit überhaupt? Einfach ausgedrückt, ein Tessellator kann ein Polygon (sei es nun ein Dreieck, Viereck oder eine andere Form) in mehrerer kleinere Polygone mit derselben Form ohne einen allzu großen Rechen- und Programmieraufwand aufteilen. Dies ist auf dem R600 bis zu 15 Mal mit einem Polygon möglich, wobei pro Tessellations-Stufe ein Drawcall, also ein Zeichenaufruf für die API, nötig ist.

Somit kann man ein schnell zu berechnendes Low-Polygon-Modell mit der Tessellations-Einheit bearbeiten, anschließend eine Displacement-Map auflegen und schon hat man ein detailliertes High-Polygon-Modell ohne die GPU großartig zu belasten bei nur marginal gestiegenem Speicherverbauch. Darüber hinaus kann man mit dem Tessellator ein interessantes LOD-System erstellen. Bei weit entfernten Figuren nimmt man nur wenige Tessellations-Stufen, während man bei einer nahen Betrachtung das Polygonmodell mehrmals mit dem Tessellator bearbeitet und somit ein detaillierteres Modell erhält. Dies ist natürlich auch mit dem Geometryshader möglich, dieser wäre dann aber nur noch begrenzt für andere anstehende Arbeiten zu gebrauchen. Laut ATi soll es vor allem bei den Xbox-360-Portierungen nicht kompliziert sein, den Tessellator auf einem R600 zu nutzen, da der Xenos über dieselbe Tessellations-Einheit verfügt. Der Tessellator auf der Radeon-HD-2000-Serie beherrscht mehrere so genannte „Subdivision Surface“-Typen, weswegen die Recheneinheit flexibel vom Programmierer benutzt werden können soll.

Die Tessellations-Einheit kann adaptiv verwendet werden, sprich nicht direkt das ganze Objekt muss vom Tessellator bearbeitet werden. So kann sich der Programmierer einzelne Objektstellen aussuchen und nur diese modifizieren.

Percentage Closer Filtering (PCF):
Die Direct3D-10-Spezifikation schreibt es vor und dementsprechend ist der R600 in der Lage Percentage Closer Filtering, kurz PCF, auszuführen. PCF ist eine schnelle Möglichkeit, mehrere Samples aus einer Shadowmap mit einem TEX-Befehl aufzurufen und diese in der Textureinheit bilinear zu filtern. Somit verhindert man verfranst aussehende Schattenkanten bei der Verwendung von Shadowmaps, wie sie auf einem R5x0 üblich waren. Dies fiel vor allem in Spielen wie Battlefield 2 und Company of Heroes negativ auf. Der R5x0 beherrschte lediglich Fetch 4. Mit Fetch 4 kann man zwar mehrere Samples mit einem TEX-Befehl aufrufen, filtern konnte man die Samples in den TMUs aber nicht. Dies musste im Pixelshader erledigt werden, was nicht nur zusätzliche Arbeitszeit in Anspruch nimmt, sondern zusätzlich in vielen Spielen (oder sogar allen) nicht implementiert worden ist.

Wir haben einen kurzen Screenshotvergleich angefertigt, der Überraschendes zeigt. Trotz PCF werden die Shadowmaps auf dem R600 in Battlefield 2 offensichtlich nicht gefiltert – warum ist uns unbekannt. Wir versuchen dies so schnell wie möglich zu klären.

Unified Video Decoder (UVD):
Dass der R600 sowie dessen Ableger RV630 und RV610 über zwei Dual-Link-DVI-Anschlüsse inklusive eines integrierten HDCP-Key-ROM in der GPU (was auch bei einer Dual-Link-Auflösung genutzt werden kann) verfügt, ist quasi schon eine Selbstverständlichkeit für eine neue GPU. Interessanter sind dagegen die Avivo-Verbesserungen, die aber nur die Radeon HD 2600 sowie Radeon HD 2400 betreffen. So wurde ein spezieller Unified Video Decoder (UVD) im RV630 und RV615 integriert, der nun alle vier Stufen des Decodierens eines HD-Videos (Entropy Decode, Frequency Transform, Pixel Prediction und Inloop Deblocking) sowohl für den H.264- als auch für den VC-1-Decoder übernehmen und beschleunigen kann. Der R600 besitzt dagegen keinen UVD, sondern erledigt alle anfallenden Arbeiten über die ALUs, weil diese laut ATi rechenstark genug für diese Aufgabe sind. Die G84- und G86-GPUs von nVidia sind dazu ebenso in der Lage, allerdings nur für den H.264-Codec. Bei VC-1 fehlt die erste Entropy-Decode-Stufe, die weiterhin die CPU übernehmen muss.

Jeder Käufer einer Radeon-HD-2000-Grafikkarte erhält einen speziellen DVI-zu-HDMI-Adapter, mit dem man zum Beispiel einen Fernseher mit HDMI-Schnittstelle an die Grafikkarte anschließen kann. Dieser ist sogar in der Lage, den Ton mit zu übertragen, obwohl dies die DVI-Spezifikationen gar nicht vorsehen. ATi macht sich hier die ungenutzte Bandbreite des DVI-Ports zu Nutze. Mitspielen muss natürlich zudem die Grafikkarte, wobei das bei jedem R600, RV630 sowie RV610 der Fall ist. So kann eine Radeon HD 2000 den Ton von der Soundkarte beziehungsweise dem Onboard-Sound über den PCIe-Bus empfangen, und leitet diesen über die R600-GPU (dort wird dann auch für den Ton die HDCP-Verschlüsselung vorgenommen) an den DVI-/HDMI-Port. So kann man ohne ein zusätzliches Kabel Bild und Ton über die Grafikkarte übertragen. Entgegen mancher Gerüchte ersetzt eine ATi Radeon HD 2000 aber keine Soundkarte. Auf die neuen HD-Tonformate (Dolby TrueHD, DTS-HD, aber ebenso Dolby Digital Plus) und auf 7.1-Sound muss man jedoch verzichten. Der Audio-Controller unterstützt nur bis zu 5.1-Sound, bietet dann aber immerhin Dolby-Digital- und DTS-Ton.