AMD / ATI Radeon HD2000-Serie Preview

Technische Daten (Fortsetzung)

I. Architektur

Werfen wir zunächst zur Veranschaulichung der Architektur einen Blick auf ein vereinfachtes Blockschaltbild des R600, das AMD zur Verfügung stellt.

Die Setup-Engine am oberen Bildrand hat die Aufgabe die Unified-Shader mit Arbeit zu versorgen. Dort werden die Ausführungssttränge (Threads) zur Abarbeitung erstellt und an die Shader-Einheiten weitergegeben. Die Weiterleitung der Threads erfolgt nicht direkt sondern über den (Ultra Threaded) Dispatch Prozessor. Dieser soll für eine möglichst gute Auslastung der Shader-Einheiten sorgen - muss beispielsweise ein Shader-Einheit bei der Abarbeitung auf Daten warten, so wird der Thread "schlafen gelegt". In der Zwischenzeit wird ein anderer Thread ausgeführt, bis die angeforderten Daten des schlafenden Threads verfügbar sind.

Am Ende der Pipeline liegen die ROPs (Render Back-Ends), welche die fertigen Pixel in den Speicher schreiben, aber auch einige finale Berechnungen wie Sichtbarkeitstests und Blending durchführen. Der Speicher ist beim R600 über ein 512 bit breites Speicherinterface angebunden (zum Vergleich GeForce 8800 GTX: 384 bit). Die Speicherschnittstelle wird hierbei allerdings nicht wie bei NVIDIA über eine Crossbar sondern über einen Ringbus realisiert.

II. Shader-Einheiten

AMD spricht beim R600 von insgesamt 320 Rechenwerken (ALUs) die als "Unified Shader" agieren, also sowohl Pixel-, Vertex-, als auch Geometry-Shader-Berechnungen (Neu in DirectX 10) durchführen können. Allerdings ist die Organisation der Recheneinheiten anders als man es von AMDs Marketing-Titulierung "Superscalar" unter Umständen erwartet. Der grobe Aufbau gliedert sich hierbei in 4 SIMD-Arrarys (Single Instruction Multiple Data). Jedes SIMD-Array besteht wiederum aus 16 Vektorprozessorern mit 5 Komponenten (Vec5).

Diese Vec5-Rechenwerke sind in der Lage einen Vektor mit 5 Komponenten in einem Takt zu verarbeiten. Allerdings verfügt der R600 laut AMD über deutlich verbesserte Co-Issue-Fähigkeiten als seine Vorgänger. Der R580 konnte beispielsweise dank Co-Issuing in seinen Pixel-Shader Vec4-Recheneinheiten entweder einen einzelnen 4D-Vektor (4 Komponenten), oder einen 3D-Vektor und zusätzlich ein Skalar (1D-Vektor), in einem Takt berechnen. Der R600 kann seine Vec5-Recheneinheiten nun gänzlich frei aufteilen, kann also bis zu 5 Skalare (Vec1) in einem Takt berechnen.

Nachteile der R600-Architektur gegenüber einer Architektur mit Skalarprozessoren ergeben sich in erster Linie bei Berechnungen die Abhängigkeiten voneinander aufweisen. Zur Verdeutlichung das nachfolgende Beispiel.

In diesem Worst-Case-Szenario können zwar beide Architekturen die Berechnung innerhalb von 5 Takten fertigstellen, ein Großteil der Vec5-Recheneinheiten bleibt aber ungenützt, während die skalare Architektur voll ausgelastet ist. Bei Spielen sind allerdings Vec3+Skalar bzw. Vec4+Skalar die üblicherweise benötigten Berechnungen, von daher ist die Angelegenheit bei weitem nicht so gravierend wie in unserem Beispiel – es zeigt aber die grundsätzliche Problematik.

III. Texturierungs-Einheiten

Für die Texturierung – also dem Auslesen und Filtern von Texturdaten – stehen beim R600 vier Texturierungs-Blöcke bereit. Jeder dieser Funktionsblöcke verfügt hierbei über 8 Texture Adress Units zur Adressierung der Texel, 20 Texture Sampling Units zum Auslesen der Texel, und 4 Texture Filtering Units zur Filterung (bi-, trilinear, anisotrop). Insgesamt stehen somit also 16 vollwertige TMUs bereit, die bei FP16-Texturen (Gleitkomma, 16 bit) ein bilinear gefiltertes Sample pro Takt erzeugen kann. Bei FP32 (Gleitkomma, 32 bit) werden hierfür zwei Takte benötigt.