AMDs DirectX-10-Radeons der HD-2000-Reihe feiern Geburtstag (PCGH-Retro-Special)

Am 14. Mai 2007 fiel der Startschuss für AMDs Grafikkarten-Serie aus der Radeon-HD-2000-Familie, welche gleichzeitig auch die ersten DirectX-10-kompatiblen Grafikchips der von AMD gekauften Firma Ati darstellten. Die Familie, die gleichzeitig vorgestellt wurde, bestand aus der Radeon HD 2900, der HD 2600 und der HD 2400.

Anlässlich des Jahrestages frischt PC Games Hardware die Erinnerung an die DirectX 10 Done Right-Generation auf und bringt als Bonbon den Hintergrundartikel aus der PC Games Hardware Heftausgabe 08/2007 - diesen finden Sie auf der nächsten Seite dieser Meldung. Die Original-Autoren waren Ralf Kornmann und Carsten Spille.

Quelle: PC Games Hardware Der PC Games Hardware Artikel in Ausgabe 08/2007.
Radeon HD 2000 - ein Blick zurück
Als im Mai 2007 die HD 2900 XT zusammen mit den kleineren Vertretern der Modellreihe, der HD 2600 und der HD 2400, vorgestellt wurde, war die Gerüchteküche bereits seit Monaten am brodeln. Bilder hatten im Internet die Runde gemacht, welche eine HD 2900 zeigten, die über eine riesige Kühlkonstruktion verfügte. Gerüchte machten die Runde, nach denen der R600-Chip der bereits im November 2006 eingeführten Geforce 8800 bei DirectX-10-Aufgaben um das Zigfache überlegen sein würde. GDDR4-Unterstützung und ein 512-Bit-Speicherinterface sollten weitaus mehr Daten liefern können, als alle Konstruktionen zuvor. Aber der R600 kam und kam nicht. Aus Ende 2006 wurde Januar 2007, dann ganz sicher die Cebit jenes Jahres und schließlich einigte man sich auf den Mai - dort passierte es dann auch: AMD stellt die komplette Chipfamilie von R600 über RV630 bis zum Einsteigermodell RV610 vor.

Die nächste Überraschung: Das hochgehandelte Topmodell, die Radeon HD 2900 XT, sollte für damals enorm günstige 399 Euro in den Handel kommen und preislich mit der Geforce 8800 GTS konkurrieren. Tatsächlich lag der Verkaufspreis dann noch einmal 50 Euro niedriger - AMDs R600-Chip war aufgrund der 80-Nanometer-Fertigung gegenüber dem G80 + NVIO-Chip höher integriert, verfügte jedoch über mehr Datenleitungen zum Speicher, welcher zum Launch jedoch "nur" aus GDDR3-Modulen bestand, die GDDR4-Modelle mit 1 GIByte VRAM kamen einige Monate später.

Quelle: PC Games Hardware Die zweite Doppelseite des PC Games Hardware Artikels in der Ausgabe 08/2007. Im Spiele-Test stellte sich allerdings schnell heraus, warum AMD so einen Kampfpreis angesagt hatte: Selbst mit der drittschnellsten Geforce, der 8800 GTS, hatte die HD 2900 XT so ihre Probleme. Die Aktivierung von Anti-Aliasing sorgte trotz der großen Bandbreite von über 100 GByte pro Sekunde für teils heftige Fps-Einbrüche. Auch der anisotrope Filter mutete den nur 16 Textureinheiten viel Arbeit zu, sodass in Kombination mit den frühen Launch-Treibern manches Mal selbst der eigene Vorgänger, die Radeon X1950 XTX, nur äußerst knapp geschlagen werden konnte.

Quelle: PC Games Hardware Die dritte Doppelseite des PC Games Hardware Artikels in der Ausgabe 08/2007. Im Mainstream- und Einsteiger-Bereich sah es für AMD dagegen besser aus. Zwar teilten auch Radeon HD 2600 und HD 2400 die prinzipbedingten Schwächen der großen Schwester, jedoch waren die entsprechenden Geforce-Karten ebenfalls nicht besonders leistungsfähig ausgefallen. Hier konnte AMD zudem mit den umfangreichen Multimedia-Features, wie dem HD-Videobeschleuniger UVD und dem integrierten Audio-Stream über DVI/HDMI punkten. Letzteres beherrschte auch die HD 2900 XT. Auch in den unteren Klassen setzte AMD auf modernere Fertigungstechnik und brachte die HD 2600 und 2400 direkt in der 65nm-Fertigung auf den Markt, während Nvidia noch mit 80nm breiten Strukturen arbeiten ließ.

Zumindest der zu der Zeit enorme Stromhunger der HD 2900 XT wurde recht bald mit der Einführung der HD-3800-Reihe im November 2007 bereinigt, wirklich konkurrenzfähig wurde AMD allerdings erst wieder mit der HD-4000-Generation im Juni 2008.

Der folgende Abschnitt erschien im Original in der PC Games Hardware, Ausgabe 08/2007 und wurde lediglich hinsichtlich der Formatierung an den Webauftritt angepasst.

Quelle: PC Games Hardware Details zur "superskalaren Shaderarchitektur" der HD-2000-Reihe Die R6x-Architektur
Mit der HD 2900 XT hat AMD ein nominelles Rechenmonster vorgestellt,welches aber im Test noch nicht überzeugen konnte. Mit einem Blick auf die Architektur klärt PCGH mögliche Ursachen.

AMDs neue HD-2000-Reihe sorgte in Form der HD 2900 XT in der letzten Ausgabe für Furore. Stark schwankende Leistungswerte aufgrund von - so hoffen wir - Treiberproblemen erschweren eine Einschätzung, wie gut und zukunftsorientiert das Design wirklich ist. In dieser Ausgabe bestätigen HD 2600 und HD 2400 diesen Trend.

Höchste Zeit also, einen Blick auf die Innereien der Chips zu werfen und aufzuzeigen, wo potenzielle Stärken und Schwächen von AMDs neuer Architektur liegen.

Rückblick
Setzte man bei AMD für die GPUs der Generation DirectX 9 noch auf eine weitgehend ähnliche Basisarchitektur, deren Grundlagen 2002 bereits mit der Radeon 9700 im R300-Chip das Licht der Welt erblickten, bringt der Wechsel auf Direct 3D 10 eine neue Richtung mit sich. Bisher übernahmen spezialisierte Shader-Einheiten die unterschiedlichen Aufgaben: Geometrie wurde von den Vertex-Shadern verarbeitet und Pixel von den Pixel-Shadern. Mit DirectX 10 hat AMD, ebenso wie Nvidia, die Chance genutzt, nicht nur bei der Ansteuerung, sondern auch in der Hardware auf einen "Unified Shader Core" zu setzen. Ein einzelner ALU-Typ muss oder vielmehr kann nun sämtliche anfallenden Berechnungen übernehmen. Ein Konzept, das bereits beim Grafikchip der Xbox 360 Verwendung fand. Trotz der gemeinsamen Grundidee gibt es erhebliche Unterschiede bei der Umsetzung.

Quelle: PC Games Hardware Vergleich der Shader-Anzahl Quelle: PC Games Hardware Shaderarchitektur - herkömmlich vs. skalar vs. superskalar. Quelle: PC Games Hardware Vergleich des Arithmetik-/ Texturverhältnisses. R600: Das Arithmetik-Monster
Der R600 setzt auf vier als "SIMD Arrays" bezeichnete Shader-Kerne, die zusammen über annähernd ein halbes Tera-FLOP Rechenleistung verfügen. Diese wird aus 320 ALUs - in Gruppen zu je fünf Einheiten zusammengefasst - gewonnen. Jeweils 16 dieser Quintetts bilden einen Shader-Kern. Dadurch wird pro Takt für 16 Pixel oder Vertices die gleiche Operation wie zum Beispiel eine Multiplikation oder Addition ausgeführt. Damit erklärt sich auch die gewählte Bezeichnung "SIMD". Neben der größeren Breite - fünf statt nur vier Slots, vorher nur bei Vertex-Shadern üblich - einer einzelnen Shader-Einheit wurde auch das Rechenwerk überarbeitet. Im Gegensatz zum Vorgänger unterliegt der Verbund aus fünf ALUs nun nicht mehr einer festen Unterteilung in einen Vektor- und einen Skalar-Teil. Jede ALU kann unabhängig von den anderen einen eigenen skalaren Befehl ausführen. Diese Technik bezeichnet man allgemein als "superskalar" und sie soll dabei helfen, die Auslastung der einzelnen ALUs zu verbessern (siehe auch Extrakasten "Superskalar"). Diese erhöhte Flexibilität hat aber ihren Preis. Die Ansteuerung eines solchen Rechenwerks erfordert ein wesentlich größeres "Steuerwort" (VLIW). Für die Umsetzung des von der Anwendung gelieferten Shader-Codes in eine Reihe dieser Steuerwörter ist der Treiber verantwortlich. Dabei ist die Zerlegung der Vektoranweisungen des Shaders in einzelne Skalare der einfachste Teil. Anschließend müssen diese jedoch auf die fünf ALUs verteilt werden. Dabei gilt es besonders zwei Regeln zu berücksichtigen:

• Nur eine der fünf ALUs verfügt über die Möglichkeit, spezielle Operationen wie Sinus, Logarithmus, Exponentenrechnung oder das Ziehen der Quadratwurzel auszuführen. Solche Anweisungen dürfen daher vom Treiber auch nur ihr zugeordnet werden.
• Da alle fünf ALUs parallel arbeiten, dürfen im selben Takt nur Operationen ausgeführt werden, die nicht auf Ergebnisse der anderen angewiesen sind (siehe auch Extrakasten "Parallel vs. sequenziell").

Quelle: PC Games Hardware Detailaufbau der Shader-Einheiten. So kann es trotz der superskalaren Architektur der R600-Rechenwerke immer noch dazu kommen, dass einzelne ALUs leerlaufen.

Dispatch-Prozessor
Um die einzelnen Ausführungseinheiten mit Aufgaben zu versorgen, ist ein den vier einzelnen Shader-Blöcken vorgeschalteter Steuerblock verantwortlich. Dieser kennt alle momentan anstehenden Arbeiten und unterteilt sie in kleinere Blöcke zu jeweils 64 Elementen. Diese sogenannten "Threads" (auch Quad-Batches genannt) werden dann den Shader-Einheiten zur Bearbeitung übergeben. Entsprechend ihrer Größe benötigen diese vier Takte, um eine Operation für alle enthaltenen Elemente auszuführen. Neben den Shader-Einheiten muss der Steuerblock auch die vier Textureinheiten mit Arbeit versorgen.

Quelle: PC Games Hardware Details zu den Textureinheiten. Textureinheiten
Auch wenn die Anzahl es vermuten lässt, sind die Textureinheiten keineswegs fest einer Shader-Einheit zugeordnet. Sie operieren vielmehr unabhängig an den zugewiesenen Threads; im Gegensatz zu den Shader-ALUs jedoch nur an vier statt an 16 Elementen pro Takt. Beim Texturfilter setzt der R600 auf die klassische Lösung mit einem bilinearen Basisfilter, der durch mehrfache Nutzung ("Loop") bessere Qualitäten vom trilinearen bis hin zu 16-fach anisotropen Filter erlaubt. Im Gegensatz zu seinem Vorgänger stellen nun auch Gleitkommaformate kein Hindernis mehr dar. Selbst 32 Bit pro Kanal sind möglich, wenn auch nur mit halbierter Geschwindigkeit. Neben der für die Filter zuständigen Einheit enthält die TMU noch einen zweiten Funktionsblock mit vier Elementen. Dieser kann vier weitere ungefilterte Werte aus dem Speicher auslesen. Sowohl zur Beschleunigung entsprechender Shader-Befehle in Direct 3D 10 als auch zum Auslesen der Vertexdaten können die Adressierer genutzt werden. Zu diesem Zweck besitzt jede Textureinheit neben dem normalen L1-Cache einen weiteren dedizierten Vertex-Cache (außer RV610/HD 2400). Beide werden durch einen von allen vier Quad-TMUs gemeinsam genutzten L2-Cache unterstützt.

Raster-Operatoren
Das Übertragen der von den Shader-Einheiten berechneten Pixel in den Speicher übernehmen beim R600 auch weiterhin entsprechende Einheiten - Raster-Operatoren oder auch Render-Backends genannt. Bei diesen kam es vor allem zu Verbesserungen im Detail, da sich die Aufgabe dieser Einheiten schon seit Längerem nicht mehr geändert hat. Die offensichtlichste Veränderung ist die Erweiterung von sechs auf acht Anti-Aliasing-Samples pro Pixel. Konnten die alten ROPs nur jeweils zwei MSAA-Samples pro Takt ausgeben und mussten entsprechend für 4x MSAA zweimal und für 6x MSAA dreimal durchlaufen werden, sind die neuen Einheiten zu Single-Cycle 4x MSAA, also vier Samples pro Takt fähig. Für 8x MSAA werden die ROPs zweimal durchlaufen. Warum AMD auf 12x MSAA und damit drei Durchläufe wie bisher verzichtet, ist leider nicht bekannt. Auch sind die Raster-Operatoren nun in der Lage, pro Takt anstelle eines Z- und eines Farbwertes zwei Z-Werte durchzuschleusen. Das ist besonders zur schnellen Schattendarstellung oder für einen sogenannten Z-First-Pass nützlich. Frühere Chips konnten das nur, wenn MSAA aktiviert war. Ansonsten versuchten AMDs Ingenieure unter der Leitung von Eric Demers vor allem, die Effizienz durch bessere Kompressionstechniken zu erhöhen. So soll jetzt die Z-/Stencil-Kompression auch ohne MSAA funktionieren und für eine bessere Ausnutzung der Bandbreite und der ROP-Ressourcen sorgen.

Ring-Bus
Bereits bei den direkten Vorgängern des R600 führte man einen Ring-Bus als Neuerung an. Während dieser jedoch nur für den Datentransport vom Speicher zu den einzelnen Einheiten des Chips genutzt wurde - für Leseoperationen also -, benötigten diese Chips auch weiterhin eine Crossbar. Diese wurde jetzt endgültig entfernt, um Platz für die zweite Generation des Ring-Busses zu machen. Nutzte man beim R5x0 den Ringbus nur für Leseoperationen, ist er beim R600 nun auch für sämtliche Schreiboperationen zuständig. Wie schon beim Vorgänger besteht der Ring aus vier sogenannten Stops, also kleinen Controller-Knoten, die jeweils vier Speicherchips mit 32 Datenleitungen anbinden. Dadurch ist der R600 die erste Einzelchip­lösung mit einem 512-Bit-Speicher-Interface. Der Verdopplung der externen Anbindung folgten auch die Verbindungen der Busstops untereinander. Dies schließt auch den fünften Stop mit ein, welcher die GPU über das PCI-Express-Interface mit der CPU verbindet. So ein Transfer blockiert dank der integrierten DMA-Engine nun nicht mehr die gesamte Pipeline während der Datenübertragung. Wie schon beim R5x0 besitzen die Busstops die Möglichkeit, Anfragen der einzelnen Chipsegmente zu gewichten. Dies ist vor allem dann wichtig, wenn kurzfristig zu einem Speicherchip mehr Bandbreite benötigt wird, als vorhanden ist. Durch die richtige Gewichtung können dann die Leerlaufzeiten des Chips verringert werden. Eine falsche kann die Situation aber auch verschlechtern. Problematisch dabei ist jedoch, dass der Chip diese Gewichtung nicht selbstständig anpassen kann, sondern auf den Treiber angewiesen ist. Damit kann AMD zwar die optimale Einstellung für bestimmte Einstellungen oder gar Benchmarks hinterlegen, aber davon abweichende Anforderungsprofile profitieren von solchen Treibern nicht und können im schlimmsten Fall sogar langsamer laufen.

Feature-Set
Bei den Chips der DirectX-9-Generation verzichtete AMD meist auf die Rolle des Vorreiters, wenn es um den Einsatz neuer Technologie ging. Bei ihrer ersten DirectX-10-GPU erfüllen die Kanadier aber nicht nur die bereits umfangreichen Forderungen von Microsoft, sondern gehen sogar darüber hinaus. So unterstützt der gesamte Chip eine Gleitkommagenauigkeit von 32 Bit, während DirectX 10 nur 16 Bit in den Texturfiltern und den ROPs voraussetzt.

Tessellator
Zusätzlich haben AMDs Entwickler eine Funktionalität eingebaut, die von DirectX 10 noch nicht einmal optional unterstützt wird. Mit dem Tessellator unternimmt man nach dem R200 in der Radeon 8500 zum zweiten Mal den Versuch, "Higher Order Surfaces" (HOS, auch Freiformflächen genannt) im Bereich der PC-GPUs zu etablieren. Wie schon zuvor soll die GPU die angelieferte Geometrie durch die Anwendung einiger mathematischer Regeln dynamisch in kleinere Dreiecke unterteilen. Dabei ist die Einheit des R600 nun funktional identisch zum Gegenstück in der Xbox 360. Entsprechend setzt man auf die Portierung von Konsolen­titeln für den PC. Zugleich hofft man ebenso darauf, dass in der nächsten Direct-3D-Version ein Tessellator unterstützt wird. Inwieweit der R600 aber zu dieser nächsten Version überhaupt kompatibel sein wird, lässt sich noch nicht sagen.

Anti-Aliasing
Eine der Anforderungen für Kompatibilität zu DirectX 10 ist der Zugriff auf einzelne MSAA-Samples in den Shader-ALUs. Während dies für bestimmte Rendering-Verfahren der einzige Weg ist, Anti-Aliasing überhaupt zu ermöglichen, entschloss sich AMD dazu, davon auch für andere Applikationen Gebrauch zu machen. Anstelle des normalen Verrechnens der einzelnen Samples eines Pixels zu einem endgültigen Farbwert nutzt man nun mehr oder weniger aufwendige Shader-Programme für diese Aufgabe. Die Möglichkeiten damit sind sehr vielfältig und durch neue Treiber können leicht zusätzliche Varianten hinzugefügt werden. Allerdings hat diese Vorgehensweise auch ihren Preis. Denn wie bei anderen Shader-Programmen benötigen auch diese Filter Rechen- und Texturleistung, um ihre Aufgabe zu erfüllen. Als hilfreich könnten sich hierbei die zusätzlichen Textur-Sampler in den TMUs erweisen, die auch für Vertex-Daten genutzt werden. Werden diese auch für das Auslesen der MSAA-Samples verwendet, blockiert man nicht die Sampler, die auch die Filter füttern, und spart so die besonders beim R600 kostbare Texturleistung.

Flaschenhälse
In Verbindung mit dem Unified-Shading-Konzept wird immer wieder davon gesprochen, dass man damit auch Flaschenhälse beim Render-Prozess beseitigen würde. Dies trifft jedoch nur auf die Bremswirkung zu, welche entsteht, wenn sich getrennte Vertex- und Pixel-Shader gegenseitig aufhalten, weil einer der beiden zu langsam ist. Das passiert zum Beispiel, wenn am "Beginn" eines Bildes erst einmal die Vertex-Daten verarbeitet werden müssen, bevor die Pixel-Shader etwas zu tun bekommen. Daneben bleiben jedoch auch weiterhin eine ganze Reihe von Engstellen in einem Unified-Shader-Chip. Mit fünf Operationen für 64 Elemente sind die Shader-Einheiten des R600 die "breiteste" Stelle der gesamten GPU, sprich, hier weist der Chip den höchsten Grad an Parallelität auf. Es wird an bis zu 64 Pixeln gleichzeitig gearbeitet. Aber gerade das macht sie besonders anfällig für Leerlauf. In der gleichen Zeit, in der 320 skalare Berechnungen durchgeführt werden, können lediglich 16 Texturen gefiltert werden. Enthalten die laufenden Shader-Programme also weniger als durchschnittlich 20 Rechenoperationen pro Element (320:16=20), limitiert die Textureinheit. Da aktuell eingesetzte Vertex-Shader-Programme allerdings nur äußerst selten Texturen nutzen, entspannt sich die Situation dadurch etwas. Im Gegenzug gibt sich aber auch kaum jemand mit einem einfachen, bilinearen Texturfilter zufrieden. Beim Einsatz eines trilinearen Filters verdoppeln sich die nötigen Rechenoperationen bereits und erreichen ihr theoretisches Maximum bei 640 Rechenoperationen pro Texturzugriff bei 16-fach anisotroper Filterung.

Eine zweite Limitierung ist bei den Raster-Operatoren zu finden. Diese verhindern, dass der Chip mehr als 16 Pixel pro Takt ausgeben kann. Da die Textureinheiten bereits bei 16 Elementen ein Limit haben, wirkt sich die geringe Anzahl der Raster­operatoren nur noch bei kurzen Shader-Programmen aus, die völlig auf Texturen verzichten und nahe am maximalen ALU-Durchsatz laufen.

Varianten
Neben dem schnellsten Modell, der HD 2900 XT, gibt es von AMDs DirectX-10-Architektur auch noch zwei kleinere Varianten. Skalierte man in der Vergangenheit vor allem über die Anzahl der Shader, sind die Eingriffe nun wesentlich umfangreicher. Beim HD2600 reduzierte AMD die Anzahl der Pixel pro Shader von 16 auf 8. Der HD 2400 muss sich gar nur mit 4 begnügen. Daneben wurde dann aber auch noch die Summe der Einheiten reduziert. Die HD 2600 muss mit drei Shaderblöcken (120 ALUs) und zwei Quad-Textureinheiten auskommen. Bei der HD 2400 sind es gar nur zwei Shader (40 ALUs) und eine Quad-Textureinheit. Auf der Ausgabeseite müssen beide mit einem Raster-Operator auskommen. Dieser ist bei der HD2600 an einen bis zu 128 Bit breiten und bei der HD 2400 an einen nur 64 Bit breiten Speicherbus angebunden. Durch diese Einsparungen kommt es natürlich zu Leistungseinbußen. Gleichzeitig ändert sich aber auch das Idealverhältnis von Rechen- zu Texturoperationen. Dies macht es, zusätzlich zur Treiberabhängigkeit, nochmals schwieriger, von der Leistung des Topmodells auf die seiner kleineren Brüder zu schließen und dürfte bei Spiele- und Treiberentwicklern für die eine oder andere Überstunde sorgen.

Technisches Fazit:R6xx-Architektur
Mit dem R600 hat AMD eine äußerst rechenstarke Direct3D-10-GPU geschaffen. Die im Verhältnis dazu relativ geringe Texturleistung lässt jedoch viel davon verpuffen. Inwieweit zukünftige Programme verstärkt auf Rechenleistung setzen, lässt sich nur schwer vorhersagen. Aber selbst dann wird AMDs Treiberteam beweisen müssen, wie gut es mithilfe des Catalysts die superskalaren Rechenwerke auszulasten versteht.

Interessante Links zum Thema:
• AMD/Ati: Techdemos von 2001 bis 2009
• Geschichte der Multi-GPU-Grafikkarte
• Geschichte der Grafikchips: Packaging und Chipshot-Galerie (Ati-Grafikkarten)

So interessant der Tesselator aus technischer Sicht auch sein mag, zeigen bisherige Ausflüge von Nvidia und AMD in diese Welt, dass es um die Akzeptanz solcher Dinge bei den Entwicklern eher schlecht bestellt ist. Ohne aktive API-Unterstützung muss sich AMD hier sogar durchaus den Vorwurf der Transistorverschwendung gefallen lassen. Man hofft jedoch auf eine direkte Übernahme der Tesselator-Nutzung bei Portierungen von der Xbox 360 und will den Zugriff darauf in einem der nächsten Treiber bereitstellen.

Artikel teilen

Heute im Jahre 2007 wurde AMDs DirectX-10-Grafikkarten der Radeon-HD-2000-Reihe offiziell vorgestellt. PC Games Hardware wirft einen Blick zurück auf das inzwischen historische Ereignis.

Per E-Mail versenden

98