Inside ATIs R420

4. Mai 2004 / von aths / Seite 1 von 4

   Prinzipielles

Um schnell auf den Punkt zu kommen: R420 (Radeon X800) ist ein Speed-Upgrade des R360 (Radeon 9800), wobei der R360 wiederum ein Speed-Upgrade vom R300 (der originalen Radeon 9700) ist. Für den R360 hat ATI die Taktfrequenz gesteigert (und eine Overdrive-Option eingebaut), aber R420 bietet bis zu 50% mehr Vertex- und 100% mehr Pixelshader-Power pro Takt, und wird zudem höher getaktet als ihre Vorgänger. Zudem kommt R420 mit einigen netten technischen Neuerungen. In einem Moment werden wir sie alle vorstellen.

Um den R420 zu verstehen müssen wir uns zunächst dem R300 zuwenden. Dieser Chip war ATIs dritter Versuch, an die Spitze zu komme. R100 – ATIs originale Radeon, war verglichen mit jedem anderen Produkt dieser Zeit featuremäßig sehr fortschrittlich. Während beispielsweise Nvidias NSR (Shading Rasterizer) im Jahre 2000 noch State of the Art war, bot ATIs "Pixel Tapestry"-Engine deutlich mehr Flexibilität und Rechenkraft. R100 bot auch schon Dependent Reads und damit sehr nützliche Bumpmapping-Techniken wie EMBM, während GeForce2 nur Dot3-BM hatte (was R100 natürlich ebenfalls berechnen kann.)

Der zweite Versuch war R200 (Radeon 8500). Diese Karte schlug mit Leichtigkeit sogar die mächtige GeForce3 – wenn wir wieder einmal die Feature-Seite betrachten. Die Radeon 8500 hat bessere Präzision, die Combiner sind weitaus flexibler, und sie bietet zudem eindrucksvolle Leistung. Die einzigen Nachteile sind beim Antialiasing zu finden (welches wegen dem Supersampling-Verfahren langsam ist und zudem aufgrund eines Bugs in der Smoothvision-Hardware nur ineffiziente Abtastmasken bietet) sowie bei der anisotropen Filterung (die weiterhin auf bilinear begrenzt ist, und nur Winkel im Umfeld von 90° verbessert, und noch immer Probleme bei der LOD-Berechnung hat was unter bestimmten Umständen zu Textur-Schimmern führt.)

Praktisch alle Nachteile waren mit dem R300 weg: Dieser Chip bietet 24 Bit Gleitkomma-Berechnungen in der Pixelpipe, während zu jener Zeit der Wettbewerber mit 9 Bit Festkomma rechnet. (Sowohl GeForce3 / 4 Ti als auch Radeon 9700 führen bestimmte Pixel-Berechnungen mit FP32-Genauigkeit aus.) Zudem war die Radeon 9700 die erste Karte mit einem 256 Bit breiten DDR-Speicherinterface und effizientem Crossbar-Controller. Neben solcher Rohleistung bot die Radeon 9700 als erstes Karte DirecxtX9-Beschleunigung, und gegenüber Radeon 8500 verbesserte anisotrope Filterung (verringerte Winkelabhängigkeit, trilineares AF), und spitzenmäßiges Antialiasing welches bis heute ohne Beispiel ist. Mit diesem Chip und ATIs Produkt-Refreshes basierend auf R300/RV360 wurden die Kanadier weltweit Nummer 1 bei 3D-Enthusiasten die überwiegend spielen.

Bisher lieferte ATI nicht nur die jeweils besten Features, sondern auch die Leistung um sie tatsächlich nutzen zu können. Ein anderer großer GPU-Entwickler tendiert dazu, erst mal die Features zu offerieren und später dann auch die Leistung dafür. Während dies bis heute so blieb, sind die Zielsetzungen bei ATI nun andere. Die Wirkung des R300 war nur teilweise ATI zuzuschreiben, denn sie profitierten auch von Nvidias Schwäche jener Zeit. Ohne Zweifel ist der R300 ein exzellenter Chip, aber seine Entwicklung war nur möglich, in dem Kompromisse eingegangen wurden. Kein IHV kann eine Wunder-GPU herbeizaubern, der Ingenieur muss entscheiden was geopfert wird, damit andere Features ausgebaut werden können.

ATIs Kompromiss war die Genauigkeit. Nun ist dies in praktisch allen heutigen Spielen und Anwendungen nicht zu sehen, weshalb wir es für ein "theoretisches Problem" halten können. R300+ ist und bleibt in Spielen vollkommen brauchbar. Diese Thematik diskutieren wir aber später, und wenden uns nun gleich den neuen Features zu. Danach nehmen wir die Pipeline unter die Lupe.

   3Dc

Aus selbsterklärenden Gründen mögen wir nicht nur den Namen, sondern auch das Feature ansich :) Hierbei handelt es sich um eine Technik, Normal Maps zu komprimieren. Normal Maps beinhalten Informationen für Bumpmapping und werden gewöhnlich in Texturen gespeichert. Weil Normal Maps ziemlich groß werden können, ist es eine gute Idee sie zu komprimieren. Bisher genutzte Texturkomprimierungs-Algorithmen arbeiten mit zwei Referenz-Farben und interpolieren diese. Auf Normalen-Vektoren angewendet, ergibt das leider blockige Artefakte, weil die interpolierten Vektoren im Vergleich zu unkomprimierten kürzer sind.

3Dc arbeitet in gewissem Sinne wie S3TC. Die Textur wird in Kacheln von je 4x4 Texeln zerlegt. Für jede diese Kachel werden zwei Referenz-Farben (in diesem Falle Normalen) gespeichert. Andere Farben (oder, im Kontext, Normalen) werden interpoliert. Einige Komprimierungsformate nutzen insgesamt 4 Werte (2 als Referenz, zwei interpolierte), andere 8 Werte (2 Referenz, 6 interpolierte.) Letztere Methode braucht mehr Speicher, da 3 statt 2 Bits notwending sind, bringt aber auch bessere Qualität. 3Dc nutzt 3 Bit für jedes gespeicherte Texel (oder eben Normale. Für den Komprimierungs-Algorithmen handelt es sich einfach um "Daten".)

Normal Maps müssen nicht unbedingt alle 3 Komponenten des Normalen-Vektors (X, Y, und Z-Achse) speichern. Gewöhnlicherweise hat jede Normale eine normalisierte Länge von 1,0. Wenn man das voraussetzt, kann man eine der Achse bei der Speicherung weglassen (weil weiterhin drei Informationen zum Normalen-Vektor bekannt sind.) Sowohl die Wiederherstellung des Z-Wertes (welches in 3Dc nicht mitgespeichert wird) als auch die Renormalisierung kann dann im Pixelshader gemacht werden. Natürlich geht das zu Lasten der Performance.

3Dc muss vom Entwickler direkt unterstützt werden. Der Chip kann solche Texturen nur dekomprimieren, sie müssen also vorkomprimiert vorliegen. ATI bietet dafür kostenlose Tools an. Damit ist es kein großer Aufwand, das sogar in bereits existierende Spiele zu integrieren: Die Anwendung / Engine muss nachsehen, ob Hardware-Unterstützung für 3Dc besteht und dann ein spezielles FourCC-Texturformat nutzen. Jemand muss zuvor natürlich noch die ganzen vorhandenen Normal Maps komprimieren. Wegen dem geringerem Speicherverbrauch ist das für Karten mit "nur" 128 MB sehr nützlich. Da weniger Speicherplatzverbrauch hier auch weniger die Bandbreite beansprucht, könnte es außerdem einen schönen Performance-Boost geben.

Wir versuchen noch herauszufinden, welche Vorteile man, außer etwas gespartem Speicherplatz, von 3Dc nun genau hat, verglichen mit DXT5 und Renormalisierung im Pixelshader. Etwas seltsam mutet uns an, wie ATI auf die Komprimierungsrate von 4:1 kommt. Eine Kachel von 4 x 4 = 16 Werten wird mit 3Dc auf 16 Byte komprimiert. Eine Normal Map muss nicht zwingend Alpha speichernn, und kostet pro 16 Werten dann 48 Byte. Das tatsächliche Ratio wäre demnach 3:1. Da man den Trick mit der Rekonstruierung von Z auch unabhängig von 3Dc nutzen kann, reduziert sich die effektive Komprimierung auf 2:1. DirectX definiert jedenfalls Zwei-Kanal-Texturformate, die für Normalen genutzt werden können.

   "Temporales" Antialiasing

Der Begriff "temporal" mag vielleicht nicht ganz korrekt sein, ATI nutzt ihn aber um die R420-Technologie mit einer alternierenden Antialiasing-Maske zu vermarkten. Jedes ungerade Frame bekommt eine bestimmte Subpixel-Maske, während für jedes gerade Frame eine andere Maske verwendet wird. Durch die dem Monitor innewohnende Eigenschaft nachzuleuchten, werden beide Masken zu einer kombiniert, was in einer besseren "scheinbaren Subpixelmaske" resultiert. Dies führt dann zu höherer Kantenauflösung, auch "edge equivalent resolution" (EER) genannt.

Ehrlich gesagt bezweifeln wir, dass das eine gute Idee ist. Betrachten wir das "temporale" Antialiasing näher: Es mit 2x-AA zu nutzen ist nicht ratsam, weil die Unterschiede zwischen den Frames zu groß würden. Man müsste einen Monitor mit sehr hoher Bildwiederholrate einsetzen, und außerdem mit extremen Frameraten spielen damit es richtig funktioniert. Mit der Leistung, um Spiele dermaßen schnell laufen zu lassen, wäre es sinnvoller gleich 4x (oder 6x) AA zu aktiveren anstatt 2x "temporal" zu nutzen. 4x mit einer alternierenden Maske könnte theoretisch zwar die gleiche Qualität wie 8x "sparsed" liefern.

Soweit wir wissen, nutzt R420 aber weiterhin ein internes AA-Grid von 12x12, so dass die Effizienz eines "sparsed" Grids bei 8x nicht in Gänze ausgeschöpft werden kann. Mit Hilfe von 6x wäre es denkbar, einen virtuellen 12x-Modus zu ermöglichen, doch 6x frisst nach wie vor ein gutes Stück Leistung. Wenn die Framerate sinkt, muss der Treiber das temporale Feature deaktivieren, um wahrnehmbares "Kanten-Flimmern" zu vermeiden. Wenn schon mehr als genügend Performance für 6x vorhanden ist, warum sollte man nicht lieber die überschüssige Leistung in zusätzliche Effekte stecken, oder in höherer Auflösung spielen?

Kurz, diese Technologie basiert auf dem Nachleuchten, wobei dies eigentlich ein unerwünsches "Feature" ist und Display-Hersteller ständig daran arbeiten, es zu minimieren. Obwohl TFT-Bildschirme eine lange Nachleucht-Phase haben, ist T-AA keine gute Wahl für TFT-Schirme, weil ihr Nachleuchten nicht-linear ist. Unabhängig vom Monitor-Typ hat ein Polygon in Bewegung keine zusätzlichen Vorteile, denn durch die "temporale" Natur kann diese AA-Technoloige nur die Qualität von ruhig stehenden Kanten erhöhen. Und um sicherzustellen, dass jedes Pixel eine alternierende Maske bekommt, muss VSync aktiviert werden. Das heißt in der Regel, viel Leistungverlust, zumindest solange man nicht Triple Buffering aktvieren kann.

In diesem Kapitel behandeln wir aber nur die technische Seite. Vielleicht mögen einige Leute temporales AA, das steht ihnen ja frei. Wir denken aber dass dieses "verbesserte" AA ein Gimmick ist, und diese Technik keine Zukunft hat. Natürlich irren wir öfters – die Zeit wird es zeigen. Wir möchten noch erwähnen, dass "temporales" AA ein reiner Treiber-Trick ist, welcher auf den "programmierbaren" (veränderbaren) Multisampling-Subpixelpositionen basiert. Das sollte mit jeder R300-basierenden VGA-Karte funktionieren. (In der Tat kündigte ATI dann, dass zukünftige Treiber das Feature auch auf R300-basierenden Karten ermöglichen.)