Ein erster Blick auf die R520-Architektur
5. Oktober 2005 / von aths / Seite 1 von 3
16 Pipelines, Shader Model 3: Das sind seit längerem bekannte Eckdaten des R520. Wir versuchen heute, etwas tiefer zu blicken, im Wissen dass sich einige interessante Details erst durch spätere Tests ermitteln lassen.
Auf den ersten Blick müsste der R520 etwa gleich stark wie der G70 sein: Was der G70 mehr an Pipelines hat, gleicht der R520 durch den Mehrtakt wieder aus. Allerdings kommt es natürlich nicht nur auf die Zahl der Pipes an, sondern darauf, was der Chip ingesamt berechnen kann. Zunächst soll die Pixelpipeline im R520 besprochen werden, danach betrachten wir die Effizienz um uns anschließend dem wichtigsten zuzuwenden, der Bildqualität.
Die Pixelpipeline
Zur Begriffsklärung: Ein Quad besteht aus 2x2 Pixeln. Seit Jahren berechnen 3D-Karten keine einzelnen Pixel mehr, sondern immer Quads, also vier Pixel gleichzeitig. Das gilt auch für Karten, die nur zwei Pixelpipes haben: Dort dauert eine Operation auf das Quad eben zwei Takte.
"R520" die Ähnlichkeit im Namen zum R420 ist nicht ohne Grund: Der R520 lässt deutlich seine R420-Verwandschaft erkennen. Dies betrifft nicht nur die Anzahl der Pixel-Pipes (weiterhin vier Quadpipes, die einzeln abschaltbar sind) sondern auch den Aufbau der ALU. Die ALU übernimmt die arithmetischen Rechnungen im Pixelshader, verrechnet also Farben und andere Daten.
Über die Performance entscheidet insbesondere die MAD-Leistung (Multiply-Add). Eine Pipeline im R520 kann nach wie vor nur ein MAD4 (also MAD mit jeweils 4 Kanälen Input und Output) pro Takt berechnen. Falls eine Vektor-Operation mit bis zu drei Komponenten und eine skalare MAD-Operation (mit nur einem Kanal) auftreten, können diese beiden im gleichen Takt ausgeführt werden der berühmte Color:Alpha-Split im Combiner. Nach wie vor gibt es also den Vektor-Combiner (vor allem für Farb-Rechnungen) und den getrennten skalaren Combiner (für andere Rechnungen), welcher übrigens auch die SFUs übernimmt.
SFUs sind "Special Functions" wie zum Beispiel Sinus. Im Gegensatz zum R420 sind zumindest einige SFUs, wie zum Beispiel der Sinus, beschleunigt worden, so dass sie keine acht Takte mehr benötigen sollten. Details hierzu werden in der Zukunft sicherlich noch herauskommen. Die CineFX-Architektur der GeForce-Karten bietet von vornherein einen Sinus für 2-3 Takten. Denkbar ist im R520 eine Beschleunigung auf einen Takt, doch hier müssen wir erst unabhängige Benchmarks abwarten.
Die Combiner im NV40 und G70 sind nicht wie in der Radeon vertikal getrennt, können aber im gleichen Takt trotzdem bis zu zwei Befehle abarbeiten, solange die Anzahl der Kanäle der gebündelten Befehle höchstens vier beträgt. Das heißt, dass der NV40 und G70 auch ein 2:2-Paar (z. B. DP2, DP2 oder ADD2, MUL2) bündeln kann, was der R520 nicht beherrscht.
SM3 verlangt FP32-Präzision im Pixelshader. Der NV40 und G70 gewinnt durch Nutzung von FP16-Präzision Geschwindigkeit, überwiegend aus zwei Gründen: Erstens wird die interne Bandbreite nicht so stark beansprucht und zweitens werden die Registerspeicher nicht so stark belastet. Ob ATI die interne Bandbreite von vornherein für durchgehenden FP32-Einsatz ausgelegt hat, wissen wir noch nicht, aber man kann es zumindest vermuten.
Nun spricht ATI von 4 arithmetischen Operationen pro Takt. Zwei davon haben wir schon genannt: MAD3 und MAD1/SFU. Zusätzlich gibt es eine "Mini-ALU", die bietet ein ADD3 und ADD1, sowie bestimmte Skalierungsoperationen um Zweierpotenzen die Mini-Alu kann also im Prinzip das gleiche wie beim R300, nur eben in FP32-Genauigkeit.
Auf den ersten Blick erinnert die ALU-Struktur des R300/R420/R520 an den NV40, nur dass Nvidia eben MUL statt ADD in einer kleineren Shader-Unit bietet. Aber der NV40 hat natürlich auch Pipeline-Stages für Zweierpotenzen-Skalierungsoperationen, diese Stages werden von Nvidia nur nicht extra genannt. Außerdem gibt es seit NV40 die Einheit für NRM_PP, welche in Partial Precision (FP16) pro Takt eine Normalisierungs-Operation ausführen kann. Das ist insbesondere beim Bumpmapping hilfreich, um die "normalen" ALUs zu entlasten und die Berechnung zu beschleunigen.
Lange Rede, kurzer Sinn: Der G70, mit der gegenüber der NV40 erweiterten Pipeline, bietet bekanntlich sogar zwei volle MAD4-Operationen pro Takt und könnte damit in erster Näherung pro Takt und Pipeline als deutlich stärker im Vergleich zum R520 eingeschätzt werden. Der NV40 hat übertriebene MUL-Kraft (und kann schon pro Takt und Pipe mehr berechnen als der R420), der R520 hat übertriebene ADD-Kraft, den G70 halten wir für sehr ausgewogen. Doch ganz so einfach ist es nicht.
Ein Pixelshader-Programm darf nach der Optimierung durch den Treiber nicht mehr als bis zu vier Temp-Register gleichzeitig nutzen, um auf dem G70 noch in voller Geschwindigkeit zu laufen. Solche Probleme kennen R300 und R420 nicht: Die können nach unseren Informationen bis zu 12 Temps gleichzeitig belegen, ohne dass es deswegen einen Slowdown gibt. Dies erleichtert die Optimierung des Shaders erheblich. Wie viele Temps der R520 physikalisch zur Verfügung stellt wissen wir nicht, jedoch ist mit Problemen à la G70 nicht zu rechnen. Die Anzahl der physikalisch zur Verfügung stehenden Temp-Register ist außerdem abhängig von der Zahl der Threads zu den Threads später mehr.
Praktisch kein Problem mit der limitierten Zahl temporärer Register zu haben heißt: Bestimmter "blöder" Shadercode ist recht einfach optimierbar. Doch es kommt noch besser: Aufgrund des Phasenkonzepts (Aufteilung in reine Sampling- und reine Rechenphasen, eine Phase besteht aus dem Sampling und anschließender Verrechnung) kann die Radeon den Pixelshader-Code grundsätzlich so optimieren, dass mögliche Texelfüllratenlimitierung die Shader-Berechnung nur so weit ausbremst, wie es dem Verhältnis von Sampling-Takten zu Rechen-Takten entspricht (das gilt jedenfalls auf eine einzelne Phase bezogen). Bei CineFX hingegen kann es zu zusätzlichen Wartetakten kommen, weil Sampling und arithmetische Rechnungen ineinander verzahnt sind.
ATI hat es dabei aber nicht belassen, sondern stattete den R520 mit einem Threading-Algorithmus aus. Das heißt, neue Quads, die berechnet werden müssen, kommen in die am wenigsten belastete Pipeline. Das bietet Nvidia im Prinzip auch, jedoch ist das Optimierungspotenzial im R520 größer: Sobald eine Quadpipe freie Kapazität hat, bekommt sie einen neuen Thread. Wenn also nicht gerechnet werden kann, weil das Textursampling noch nicht abgeschlossen ist, wird der Thread "schlafen gelegt", und die Pipeline rechnet dann erst einmal an an einem anderen Thread. Ist das Textursample endlich fertig, wird der Thread wieder "aufgeweckt" und rechnet weiter. Damit lassen sich Textursampling-Latenzen hervorragend verstecken jedenfalls bis zu einer bestimmten Grenze.
Der R520 zerteilt nach unseren Informationen die Quads in sehr kleinen Batches von lediglich 2x2 Quads ein, und unterstützt bis zu 512 Threads, kleinere Modelle bieten bis zu 128 Threads. Threading macht eine Art Hardware-Sheduler notwendig, ist jedoch mit Thread-Programmierung auf der CPU keineswegs vergleichbar. Wir haben bezüglich Threading noch keine genauen Informationen und bitten deshalb, unsere Äußerungen dazu cum grano salis zu nehmen. Die TMUs sind bei der R5xx-Architektur entkoppelt, das ist wichtiger Schritt zur Auflösung der traditionellen Pipeline-Architektur.
Der R520 bietet eine Branch-Unit ATI tut so, als hätte die Konkurrenz das nicht. Natürlich benötigen auch NV40 und G70 entsprechende Hardware, um dynamische Verzweigungen zu erlauben, allerdings führt dort jeder Befehl einer solchen dynamischen Verzweigungsstruktur zu mindestens zwei Takten, in denen nicht gerechnet werden kann. Das scheint ATI besser gelöst zu haben. Allerdings kommt es auf diese zwei Takte so sehr nicht an, entscheidend ist beim R520 die sehr kleine Batch-Größe von gerade mal vier Quads beim G70 schätzen wir die Granularität auf etwa 256 Quads.
Das heißt im Klartext: Die Wahrscheinlichkeit, durch Branching tatsächlich Rechenzeit zu sparen, ist beim R520 deutlich größer. Denn bei 256 gleichzeitig in Bearbeitung befindlichen Quads im NV40/G70 ist die Wahrscheinlichkeit, dass beide Verzweigungen durchlaufen werden müssen, und man letztlich nichts spart, viel größer als bei nur vier Quads in der Pipe.
Die Vertexpipeline
Zur Vertexshader-Pipeline haben wir noch keine genauen Informationen. Wir vermuten stark, dass ATI endlich unabhängige Vertexshader entwickelt hat. R420 zum Beispiel hat nur einen Vertexshader, der aber sechs Vertices pro Takt berechnen kann, für die alle das gleiche Vertexshader-Programm gilt. NV40 hat ebenfalls sechs Vertexshader, für die gilt ebenfalls immer dasselbe Vertexshader-Programm jedoch dürfen sich die Programme während der Abarbeitung im gleichen Takt an unterschiedlicher Stelle befinden. Im NV40 und G70 lassen sich jedoch auch einzelne Vertexshader abschalten. Das ist beim R420 noch anders ein Ableger mit 8 oder gar nur 4 Pixelpipes hat trotzdem seinen sechsfachen Vertexshader.
Der Vertexshader im R520 wurde in jedem Fall SM3-tauglich gemacht, wir wissen jedoch nicht, wie zum Beispiel das Vertex-Texturing gelöst wurde. Da bleibt uns nur das Warten auf entsprechende Informationen. Traditionell bieten Vertexshader einen Vektor4-Kanal und einen skalaren Kanal für Rechnungen. Radeon-Karten können auch im skalaren Kanal MAD-Operationen ausführen, bisherige Nvidia-Karten bieten das nicht pro Takt und Vertexpipe ist der Vertexshader im Radeon also rechenkräftiger.
Die nun 8 Vertexshader bei einem Takt um die 600 MHz herum bieten im Vergleich zum G70 (ebenfalls 8 Vertexpipes, jedoch bei nur 470 MHz) also ein erhebliches Leistungsplus in der Geometrie-Verarbeitung wovon insbesondere der 3DMark profitiert. Spiele können mit der extremen Leistung weniger anfangen. Allerdings ist es immer besser, Vertexleistung verpuffen zu lassen als im Gegenteil Gefahr zu laufen, dass der im Aufbau vergleichsweise einfache Vertexshader die teuren Pixelshader-Einheiten limitieren könnte.
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.
Vergleich mit dem G70 und Ausblick
Wir sehen es schon vor uns, wie diverse Websites einen "Battle of the Titans" herbeischreiben wollen. Die endgültige Grafikkarte ist auch der R520 nicht. Bezüglich der Architektur gibt es zum G70 massive Unterschiede. Interessant ist, wie die beiden IHVs unterschiedliche Prioritäten setzen: Nvidia bietet mit dem G70 die überlegene arithmetische Leistung sofern man sie entfalten kann, hat der R520 keine Chance.
Während Nvidia bereits über die breite Architektur mit 6 Quadpipes verfügt, und jetzt erst einmal nur an der Taktschraube drehen muss, hat ATI eine mögliche Architekturverbreiterung noch vor sich. Denkbar wäre auch, dass ATI zum Refresh lediglich die ALUs überarbeitet. Im Takt sind für jedoch keine Wunder mehr möglich, und je breiter die Architektur, desto mehr hat man pro einzelnem Zusatz-MHz. Das spricht für Nvidia.
ATI hat seinen Schwerpunkt bei der Effizienz gesetzt, um mit der schlankeren, dafür hochgetakteten Architektur zu punkten. Dabei beantspruchen beide Designs etwa 300 M Transistoren. Effizienz-Features kosten eben auch. Der R520 hat sogar mehr Transistoren als der G70, und ebenso wie beim G70 besteht bei Chipfehlern eine gewisse Chance, dass der Chip nicht weggeworfen werden muss, da bestimmte Dinge redundant (also mit Reserven) ausgelegt wurden.
Doch zurück zur Shader-Architektur: Wenn der G70 aufgrund seiner Limitierungen hin und wieder zu einigen Leertakten gezwungen wird, ist das nicht so schlimm, denn die arithmetische Rohleistung ist höher. Hat das Pixelshader-Programm eine Zusammensetzung, die dem G70 schmeckt, hängt der den R520 ab und umgekehrt. Es sind problemlos SM3-Shader denkbar, in denen der R520 dem G70 davonzieht.
Als der NV40 vorgestellt wurde, und ATI nur den R420 aufzubieten hatte, weil das geplante R400-Design in der Entwicklung abgebrochen wurde (die erwartete Performance war ungenügend), rückte Nvidia in der öffentlichen Wahrnehmung dank der fortschrittlichen Architektur nach der GeForceFX-Schlappe wieder nach vorne. ATIs Beteuerungen, das Mehr der Features im NV40 seien noch nicht notwendig, klangen genauso hilflos wie Nvidias Statements zum 256-Bit-Interface im R300 (der NV30 hatte nur ein 128-Bit-Interface, mit dem NV35 wurde das 256-Bit-Interface dann als tolle Sache vermarktet). Während ATI auf dem R420 basierend ein Modell nach dem anderen launchte, und die Modellpalette langsam unübersichtlich wurde, legte Nvidia mit dem G70 nach: Gegenüber dem NV40 etwa bis zu 70% mehr Leistung.
Doch ATI legte jetzt einen Chip vor, der es auch mit dem G70 aufnehmen kann. Die Multisampling-Antialiasing-Qualität ist nach wie vor Spitze, obwohl es seit dem R300 hier keine Entwicklungen mehr gab doch die gesteigerte Leistung erlaubt es jetzt endlich, 6x AA generell zu nutzen. Reine Supersampling-Modi sind nicht notwendig, da ATI einen sparse Supersampling-Modus per Treiber nachgerüstet hat, der wie beim G70 nur dann zum Einsatz kommt, wenn es wegen aktiven Alphatests notwendig ist. Mit 6x sparse Multi- und Supersampling hat ATI mit Nvidia nicht nur gleichgezogen, sondern den G70 überboten (der G70 bietet zwar weiterhin höhere und bessere Modi als 4x, jedoch nur im Zusammenhang mit ineffizientem ordered grid Supersampling, hier bezahlt man für das Mehr an Qualität mit massiven fps-Einbrüchen).
Was den anisotropen Filter angeht, hat ATI Nvidia schlicht blamiert trotz der Probleme in der LOD-Bestimmung bietet der R520 ein AF mit vernünftig reduzierter Winkelabhängigkeit. Dieser drückt die fps-Rate um einige Prozent, doch der Qualitätsgewinn ist in jedem Fall höher als der fps-Verlust (den Zusammenhang findet man hier erläutert). Aus unserer Sicht sollte es nicht darum gehen, mit einem neuen Chip die Konkurrenz in Dingen fps um Längen zu schlagen. Seit einiger Zeit muss man mindestens in 1600x1200 benchmarken, damit sich aktuelle Highend-Modelle überhaupt noch absetzen können.
Lediglich in einer handvoll besonders anspruchsvoller Titel macht sich die zusätzliche Leistung auch in gängigen Auflösungen bemerkbar. Diese wenigen Titel dürfen aber nicht einziger Maßstab sein, um Hardware zu bewerten. Top-Hardware muss nicht nur bei den allerneusten Edelshootern brillieren, sondern auch breite Kompatibilität mit älteren Titeln bieten, und Optionen auf Bildqualität-Features offerieren, um die Spiele nicht nur so schnell wie nie, sondern auch so schön wie nie zu rendern.
Angesichts der trotzdem vorhandenen Bemühung beider IHVs, den Kunden immer wieder mal mit einigen Prozenten angeblichem Leistungsgewinn zu beglücken, wobei tatsächlich nur die Texturqualität weiter verschlechtert wurde: ATI hat endlich zur Kenntnis genommen, dass anisotrope Filterung nur dann bestmöglichen Qualitätsgewinn bringen kann, wenn es so wenig winkelabhängige AF-Reduzierung gibt wie möglich. Die Probleme in der LOD-Bestimmung und die damit verbundene seltsame MIP-Map-Wahl harrt noch einer genauen Analyse, doch der von ATI eingeschlagene Weg ist richtig. Nvidias aktuelle Entscheidungen betreffs der anisotropen Filterungen sind falsch.
Dem Threading gehört die Zukunft, auch Nvidia wird dereinst auf eine vergleichbare Technologie setzen. Damit geht die Auflösung der Pipelines einher: Man hat Threads und Units. Das quadbasierte Rendering könnte uns hingegen noch länger erhalten bleiben (weil man damit massiv Texturkoordinaten-Logik sparen kann). ATI bietet jetzt endlich Skalierbarkeit in Dingen ALUs und TMUs: Die Radeon X1600 (RV530) hat 12 ALUs, aber nur 4 TMUs (eine solche Entkopplung ist bei einem Phasen- oder Threading-Konzept viel einfacher vorzunehmen, als bei der CineFX-Architektur). Wir erwarten für die Zukunft Chips, wo nicht nur die Pixelpipeline mehr oder weniger aufgelöst ist, sondern es hardwareseitig einfach Units gibt, die sowohl für Pixel- als auch Vertexshading genutzt werden können.
Viele Leser werden sich fragen, wie es beim R520 mit der Fähigkeit zum HDR-Rendering aussieht. Zum Thema HDR-Rendering planen wir allerdings einen eigenen Artikel. Bis dahin sein so viel gesagt: Der R520 beherrscht zwar FP16-Alphablending, jedoch nicht die Filterung von FP16-Texturen. Dies sehen wir als Nachteil, da HDR-Lightmaps für vernünftige Qualität gefiltert werden sollten. Auf der anderen Seite bieten die R520-ROPs Multisampling-Antialiasing auch in Verbindung mit HDR-Rendering, was beim NV40 und G70 nicht vorgesehen ist.
Unser erster Blick auf den R520 musste sich angesichts unserer Quellenlage auf wenige Punkte beschränken. Obwohl nach bestem Wissen zusammengestellt, möchten wir was den Inhalt dieses Artikels angeht zur besonderen Vorsicht raten. Wer Fehler melden oder Bemerkungen anbringen möchte, kann unseren Thread im Forum nutzen. User Dank gilt allen, die zum Artikel direkt oder indirekt beigetragen haben.
Eine Anmerkung in eigener Sache
Am Freitag und Sonnabend letzter Woche richtete ATI auf Ibiza eine Presseveranstaltung aus, in der die einen Redakteure ausspannen konnten, und die anderen mit richtigen Technikern reden durften. 3DCenter war nicht eingeladen. Seitens Nvidia war der Autor dieses Artikels einmal zu einer ähnlichen Veranstaltung eingeladen (zum Editor's Day 2004, dieses Jahr jedoch nicht mehr, dennoch wir haben weiterhin Kontakt zu Nvidia). Während diese Zeilen geschrieben werden, nimmt der Autor einen Schluck aus seiner ATI-Tasse ein Giveaway von einer kleinen Zusammenkunft in München aus der R420-Zeit, bei der ATI die Reisekosten übernahm.
Jetzt zum Launch des großen neuen Chips von ATI bekamen wir nicht mal ein NDA. Das sorgte bei uns für Irritationen. Vor jedem großen Chip-Launch wissen wir rechtzeitig die interessanten Eckdaten. Sofern wir Fakten kennen, ist es eigentlich unsere Aufgabe, den Leser zu informieren. Ein NDA verzögert dies, da wir so lange schweigen müssen, wie es dem IHV genehm ist. Der Deal ist folgender: Wir spielen bezüglich des Release-Termines mit und erhalten dafür Hardware für eigene Tests und Zugang zu Technikern. Dies erlaubt es uns, Fragen zu stellen und Informationen zu erhalten, die nicht im Pressematerial stehen, also den Artikel einzigartig zu machen. Aus unserer Sicht nützt das unseren Lesern.
Hinter uns steht kein Verlag mit einer Publikation, an der wegen ihrer schieren Größe der IHV nicht vorbeikommt. Dennoch erwarten wir als Deutschlands größte 3D-Hardwaretechnik-Site, dass der IHV auf uns zukommt und uns ein NDA anbietet. Bisher haben wir jedes angenommen. Hat uns ATI nur versehentlich übersehen? Nein, uns wurde im Zuge der Anfrage auf Hardware abschlägig beschieden.
Zum R420, einer Verlegenheitslösung, bekamen wir das Pressematerial und sogar eine Telefonkonferenz, wenn auch nicht mit einem Techniker. Beim R520, der neuen Generation nach dem R300/R420, jetzt wo ATI nach Jahren endlich wichtige Feautures realisiert und Nvidias Grenzen aufgezeigt hat, bekamen wir, eine bekanntermaßen technisch interessierte Website, nichts.
Lange Zeit kamen wir gänzlich ohne Beachtung irgendeines GPU-Entwicklers aus. Journalismus basiert auf Recherche und heißt nicht, Marketingmaterial wiederzukäuen. Das ist ein Lernprozess, durch den auch wir gegangen sind: Unsere Artikel zu Matrox' Parhelia und ATIs R300 enthalten etliche Irrtümer, weil wir nicht in der Lage waren, die Aussagen der Hersteller kompetent genug zu hinterfragen. Das Pressematerial formuliert oft bewusst so, dass man den Hintergrund nur dann versteht, wenn man ihn bereits kennt.
Wir sehen unsere Aufgabe jedoch nicht darin, ein Feature so zu beschreiben, wie es dem Hersteller gefällt, sondern es zunächst zu verstehen und es dann selbst zu beurteilen. Entsprechend änderte sich unser Herangehen an einen Technik-Artikel: Statt so genannte White Papers durchzusehen, die größtenteils Werbespam sind, wird Grundlagenforschung betrieben. Dabei unterschlagen unsere Artikel wahrscheinlich einige Details, die im Pressematerial stehen; doch kommt es darauf an?
Wir sagen: Es kommt darauf an, dass der Leser versteht, was er erfährt doch wie kann das gewährleistet sein, wenn der Redakteur nicht die Dinge versteht, über die er schreibt? Das Marketing-Material und etwas Halbwissen vom Hörensagen alleine reicht nicht aus, um ein Verständnis zu erlangen. Ohne Techniker, die vergleichsweise ehrlich sind und nicht nur mit "ja" oder "nein", sondern auch mal ausführlicher antworten, können wir die Funktionsweise neuer Features oft nicht erkennen, denn solche Vollprofis, das wir gleich alles wissen, sind wir nicht. Dieser Artikel hier ist entsprechend oberflächlich und sollte dem Leser so eigentlich nicht vorgesetzt werden. Zudem ist er eine reine Textwüste ohne Karte können wir nunmal keine Bilder erstellen.
Wir hoffen, in absehbarer Zeit dennoch eigene Benchmarks sowie neue Technik-Details anbieten zu können.
Quelle
www.3dcenter.org
und wenn nicht ists mir auch egal 
[/u]
