Ein erster Blick auf die R520-Architektur

5. Oktober 2005 / von aths / Seite 2 von 3

   Effizienz

Auf den ersten Blick ist der R520 enttäuschend: Nur 16 Pipelines, mühselig durch den Takt kompensiert, und die MAD-Rechenkraft der einzelnen Pipelines wurde nicht verbessert (wenn man davon absieht, dass die FP24-Rechenwerke auf FP32 aufgebohrt wurden). Die besprochenen Maßnahmen wie das Threading (das ist neu) und die robuste Leistung, auch wenn viele temporäre Register benötigt werden (das war bei ATIs DirectX9-Karten schon immer so), tragen aber dazu bei, dass die R520-Rechenwerke schon fast bestmöglich ausgenutzt werden können. Der G70 bietet zwar mehr Power pro Takt, diese kann aber nicht im gleichen Grad genutzt werden.

Nun ist das Threading nicht überzubewerten. Denn das Phasenkonzept, eingeführt mit dem R200 (Radeon 8500) sorgt schon für eine ganz gute Auslastung. Das Threading kann die Effizienz zwar steigern, aber nur von einem hohen Niveau aus – entsprechend gering ist der Zusatzgewinn. Doch ATI hat auch andere Komponenten verbessert.

Da ist der achtfach unterteilte Speichercontroller zu nennen. Das 256-Bit-Interface besteht beim R520 aus acht 32-Bit-Schnittstellen (und nicht aus vier 64-Bit-Controllern wie im R420 oder G70), das entlastet die Caches. Die Burstzeiten steigen mit neueren Speichertechnologien an, und dann pro Controller die Breite zu senken (und entsprechend mehr Controller zu haben), kompensiert dies. Die Caches und FIFOs scheinen zudem gründlich überarbeitet worden zu sein und können jetzt flexibler untereinander kommunizieren, ohne dass Daten im Grafikkarten-Speicher zwischengelagert werden müssen. All das kann nicht für Wunder sorgen, aber so fügt sich ein Baustein zum anderen, um Leertakte, in denen nicht gerechnet und nicht gesampelt wird, weitgehend zu vermeiden.

Doch auch die SM3-Implementierung kann für effizienteres Rendering sorgen. Bislang war es anbetrachts der begrenzten Möglichkeiten der weit verbreiteten SM2-Hardware üblich, Shader zu "permutieren". Das heißt vereinfacht gesagt, dass für alle möglichen Effekte in allen möglichen Kombinationen entsprechende Shader erstellt werden. Die Grafikkarte muss dann öfters das Shaderprogramm wechseln, was neben der GPU auch die CPU belastet.

SM3 ermöglicht Shader, die lang genug sind, um alle Effekte in einen einzigen Shader zu packen. Was davon tatsächlich berechnet wird, kann man über Konstanten konfigurieren. Dank bestimmter Befehle wie DDX und DDY, die seit SM3 Pflicht sind (jedoch schon der NV30 beherrscht), ist es sogar möglich, innerhalb des Shaders zu berechnen, ob bestimmte Effekte überhaupt noch sichtbar sind. Wenn nicht, kann man sich die entsprechenden Rechnungen sparen.

Der frühzeitige Abbruch der Berechnung heißt auch "Early Out". Eine Anweisung namens texkill gibts schon seit DirectX8, doch dort wird in jedem Fall zu Ende gerechnet, wobei die Rechenergebnisse dann verworfen werden. Dank der kleinen Threads im R520 ist anzunehmen, dass der R520 aus dem Early Out großen Nutzen ziehen kann.

   Bildqualität

Weiterhin bleibt 6x sparse die höchste Multisampling-Einstellung. Dieser Modus ist mit dem R300 (Radeon 9700) seit 2002 verfügbar – die fehlende Weiterentwicklung in diesem Punkt lässt sich insofern verschmerzen, als dass mit 6x sparse bereits sehr hochwertige Kantenglättung geboten wird. Sparse grid Supersampling für Polygone, bei deren Texturen Alphatesting genutzt wird, ist per Treiber nachgerüstet worden, und läuft prinzipiell auch auf anderen Radeon-Karten, die Multisampling beherrschen.

Beim G70 wurde diesbezüglich auch höchstens minimal zusätzliche Hardware eingebaut. Wir fragen uns, warum ATI erst jetzt auf die Idee kam. Jahrelang ärgerten sich Radeon-User über das Geflimmer bei Alphatest-Artefakten. Die GeForce-Karten vor dem G70 bieten wenigstens generell Supersampling, wenn auch nur mit der ineffizienten Ordered-Grid-Methode.

Bei dem von ATI "adaptiv" genannten Antialiasing ist generelles Supersampling natürlich nicht mehr notwendig. Bezüglich Antialiasing sehen wir ATI mit dem R520 vorne, dabei ist es unerheblich, welche der gebotenen Features eine reine Treiberfrage sind. Wie sieht es nun mit der aniostropen Filterung (dem AF) aus?

Nvidia hielt sich beim NV40 wahrscheinlich für gewitzt, das winkelabhängige anisotrope Muster der Radeon-Karten nachzuahmen, um somit für einige zusätzliche Prozent bei der fps-Zahl erheblich Qualität zu opfern und sich der fragwürdigen R300/R420-Qualität anzunähern. Beim G70 wurde dem User zunächst sogar Flimmergrafik zugemutet, wenn AF zugeschaltet wird. Das heißt, standardmäßig ist das heute noch so, nur im HQ-Modus, den der User etwas versteckt im Control Panel findet, darf er sich entscheiden, bitte kein Flimmern zu haben – was allerdings auch spürbar auf die Framerate geht. Die in der Regel mit den Standard-Settings gebenchten Nvidia-Karten haben deshalb in der öffentlichen Wahrnehmung einen Vorteil in der "Leistung", welcher nicht gerechtfertigt ist.

Standardmäßig bietet der R520 kein besseres AF als seine Vorgänger R300/R420, lediglich die Auflösung des trilinearen Filters soll verbessert worden sein. Doch ATI bietet auch einen HQ-Modus mit besserem AF-Muster. Allerdings ist damit die traditionelle Qualität à la NV20 (GeForce 3) nicht erreicht. Zu diesem HQ-Modus im R520 haben wir noch keine genaue Informationen, außer dass die LOD-Berechnung nicht wie erwartet funktioniert. Das heißt nicht automatisch, dass damit kein gutes AF-Sample zustande kommt. Das seltsame LOD könnte dazu dienen, bestimmte Effekte, die bei anisotroper Filterung auftreten, zu kompensieren. Davon gehen wir derzeit jedoch nicht aus.

Doch der Weg ist klar: Vom fürchterlichen sogenannten AF im R100 (Radeon) zum verbesserten AF im R200 (verbessertes Winkelmuster, verbesserte Präzision) zum nochmals deutlich verbesserten AF im R300 (endlich trilineares AF, nochmals verbessertes Winkelmuster) gibt es nun den nächsten Schritt hin zu mehr Qualität. Nvidia bot im NV20 bishin zum NV38 ein AF, das ATI bis heute, auch mit dem R520, nicht erreicht hat. Dazu zählt auch die Tatsache, dass die GeForce auch bei sehr dünnen Polygonen noch ein korrektes LOD berechnen kann, während die Radeon hier bis heute Probleme hat.

Aber: Bei ATI geht es bezüglich Texturqualität aufwärts, bei Nvidia abwärts. Wir sehen ATIs aktuelles HQ-AF im R520 als besser im Vergleich zum aktuellen HQ-AF von Nvidia (im NV40 und G70).

   Oh Marketing, Oh Marketing, wie wirr sind deine Worte ...

Bald nun ist Weihnachtszeit – jedenfalls kann man das denken, wenn man im Supermarkt ist. Um ein Märchen zu hören, braucht man sich aber nur das zu Gemüte zu führen, was PR-Fachmänner verbreiten. ATI sagt nun endlich klar, dass die 3Dc-Texturkomprimierung Zweikanal-Texturen komprimiert, beharrt aber weiterhin auf einer Komprimierungsrate von bis zu 4:1. Wir haben in einem Artikel ausführlich vorgerechnet, dass man eben deshalb von einer 2:1-Komprimierung sprechen muss. Das besondere bei 3Dc ist, dass die beiden Kanäle unabhängig voneinander komprimiert werden.

Jetzt bietet ATI 3Dc auch für einzelne Kanäle, und nennt das Paket 3Dc+. Bei dieser Einkanal-Komprimierung spricht ATI korrekterweise von einem 2:1-Komprimierungsverhältnis. Das Verfahren ist genau dasselbe (also nicht neu, sondern entspricht der Alpha-Komprimierung von DXT5, 1999 entwickelt von S3) – ob man nun ein oder zwei Kanäle komprimiert, ändert nichts am Komprimierungsverhältnis. ATI widerspricht sich damit selbst und hofft, dass der Reviewer trotzdem weiterhin das Märchen von "4:1" glaubt.

Nvidia griff für die G70-Unterlagen ATIs verschwurbelte Argumentation dankbar auf, und spricht von 2:1-Komprimierung, ohne dass irgendwas komprimiert wird – man speichert einfach Normalmaps im Tangentspace mit nur zwei Kanälen (Details dazu ebenfalls im obigen Link).

ATI beharrt ebenfalls darauf, dass man 12x Antialiasing 14x nennen kann. Wenn man die Textursamples einfach zu den Geometriesamples addieren möchte (was man aus guten Gründe nicht tut), böte der R520 ohne CrossFire kein 1x, 2x, 4x und 6x, sondern 2x, 3x, 5x und 7x AA. Wir sind sprachlos, dass ATI diesen Quatsch von "14x" weiterhin verbreitet. Nvidias 8x-Modus müsste man dann 10x nennen, den 16x-Modus gar 20x. Beim Antialiasing zählt man die Geometriesamples, was ATI bei den Nicht-CrossFire-Modi ja auch (noch?) tut, und führt mögliche Supersampling-Anteile separat auf (Nvidias 16x-Modus ist 4x Multisampling mit 2x2 Supersampling, ATIs 12x-Modus ist 6x Supersampling mit 2x sparse grid Supersampling).

Wir bedauern es, wie mit eigentlich klaren Begriffen schlicht Schindluder getrieben wird. Der Pokal geht dabei nicht an einen einzelnen IHV, sondern an alle – leidtragenden sind die interessierten Leser des Marketing-Materials, denen es so erschwert wird, hinter die Funktionsweise der einzelnen Features zu steigen.