ATi Radeon HD 3870 im Test: Ein neuer Name alleine reicht nicht

 3/34
Wolfgang Andermahr
527 Kommentare

Technik im Detail Part 1

Auch wenn man anhand der Kartenbezeichnung (ATi Radeon HD 3800) vermuten könnte, dass es sich bei dem verbauten Chip um eine völlige (oder eher gesagt größtenteils) neu entwickelte GPU handelt, so ist dies bei der RV670-GPU nicht der Fall. Denn der Codename verdeutlicht bereits, dass der RV670 eng verwandt mit dem R600, der auf der Radeon HD 2900 XT verwendet wird, ist. Und dies ist beim RV670 und somit der Radeon HD 3850 oder der Radeon HD 3870 der Fall. ATi hat allerdings die Zeit genutzt um einige Veränderungen vorzunehmen.

Der RV670 wird wie beinahe sämtliche Grafikchips in der Chipschmiede von TSMC gefertigt. ATi hat seit längerer Zeit die Tradition, dass man immer den neuesten zur Verfügung stehenden Fertigungsprozess nutzt, von der man beim RV670 nicht abgewichen ist. So wird die GPU im modernen 55-nm-Prozess gefertigt und beherbergt mit 666 Millionen Transistoren einige Schaltungen weniger als der R600. Kurz zusammengefasst besteht der RV670 aus denselben technischen Einheiten wie der R600: 320 Stream-Processing-Units (64 5D-Vektorprozessoren), 16 Textureinheiten sowie 16 Raster Operation Units (ROPs), die ATi gerne als „Raster Back-Ends“ bezeichnet. Doch nicht alles ist so geblieben wie man es vom R600 kennt. So unterstützt der RV670 die Direct3D-10.1-API, den Unified Video Decoder (UVD), eine intelligente Stromsparfunktion und den PCIe-Standard der zweiten Generation – doch dazu später mehr.

RV670-GPU
RV670-GPU

Die 64 5D-Shadereinheiten sind auf dem RV670 unverändert geblieben. Im optimalen Fall steht der Grafikkarte also eine sehr hohe Shaderleistung zur Verfügung, allerdings tritt dies voraussichtlich eher selten ein. Zwar können sich die 5D-Einheiten im Verhältnis 1:1:1:1:1 aufsplitten, wobei diese sich dann wie Skalarshader verhalten würden, jedoch müssen die Operationen völlig unabhängig voneinander sein. Falls diese doch voneinander abhängig sind, warten einige ALUs auf deren Ergebnisse und stehen still. Der Thread-Scheduler versucht dies zu verhindern und die ALUs mit anderweitigen Aufgaben zu belegen, doch ist dazu eine Menge Treiberoptimierung von Nöten. Jede ALU kann auf dem RV670 eine MADD-Operation (Multiply-ADD) pro Takt durchführen. Von einer dynamischen Sprunganweisung (Dynamic Branching, eingeleitet durch if-/when-Befehle) wird keine der ALUs blockiert, da es für diesen Zweck eine eigene Einheit im RV670 gibt. Dafür werden die „Special-Function“-Operationen, unter anderem eine Kosinus-Berechnung, aber von einer der fünf ALUs pro Shaderblock ausgeführt, die in diesem Takt (und in den folgenden, falls nötig) nicht für anderweitige Operationen genutzt werden kann.

Beim RV670 hat es ATi bei 16 Textureinheiten belassen, obwohl dies zweifellos eine große Schwachstelle im R600-Design ist. Die Texturfüllrate ist einfach viel zu gering, was vor allem beim Einsatz vom anisotropen Filter des Öfteren in einem großen Performanceverlust resultiert. Weiterhin kann der RV670 16 Texturen pro Takt filtern und 32 Texturen adressieren. FP16-Texturen werden in einem Takt gefiltert, weswegen der Chip keine Füllrate verliert. Der G8x sowie der G92 benötigen dazu zwei Takte. Auch die ROPs sind von den Fähigkeiten identisch geblieben. Das „Sample Resolve“ für Multi-Sampling-Anti-Aliasing wird immer noch von den Shadereinheiten berechnet und pro Takt können 32 Z-Operationen (Tiefentests) durchgeführt werden. Die (bis jetzt nicht wirklich benutzbare) Tessellation-Unit schlummert erneut im RV670-Design, obwohl diese erst mit Direct3D 11 Einzug halten wird. Der RV670 beherrscht das so genannte „Double Precision“, kann also alle Daten mit einer Genauigkeit von 64 Bit anstatt 32 Bit (Single Precision) berechnen. Dies ist aber nur bei manchen GPGPU-Programmen von Wichtigkeit und wird (zumindest vorerst) nicht in den Spielealltag einfließen.

Radeon HD 3800 Series Spezifikationen
Radeon HD 3800 Series Spezifikationen

Verkleinert hat ATi auf dem RV670 und den dazugehörigen Grafikkarten das Speicherinterface. Während dieses bei der Radeon HD 2900 XT noch über einen 512 Bit breiten Bus angeschlossen ist, ist das Speicherinterface auf einem RV670 nur noch 256 Bit breit. Damit spart man zwar einige Transistoren, allerdings halbiert sich bei gleichem Speichertakt die Speicherbandbreite. Dabei muss man erwähnen, dass die sehr hohe Speicherbandbreite auf der Radeon HD 2900 XT in vielen Fällen wohl ins Nichts verpufft ist. Denn selbst bei einem 200 MHz niedrigerem Speichertakt gibt es nur in wenigen Situationen einen spürbaren Performanceverlust.

Doch was hat sich denn nun überhaupt auf einem RV670 geändert? Die Feinheiten liegen – abgesehen von den oben erwähnten offensichtlichen Modifizierungen – im Detail. Ein Gespräch mit David Nalasco von AMD brachte ans Tageslicht, dass AMD primär die Zugriffszeiten und somit die Effektivität des Speichercontrollers verbessert hat, um so die geringere Speicherbandbreite kompensieren zu können. Die „Arbitter-Logik“ im Speichercontroller wurde verbessert, zudem kann man nun auftretende Latenzen besser in den ROPs verstecken. Somit soll die RV670-GPU mehr mit der vorhandenen Speicherbandbreite anfangen können als der R600. In Fällen, in denen beim R600 ein Latenzproblem aufgetreten ist, soll der RV670 deutlich schneller seinen Dienst verrichten, trotz der niedrigeren Bandbreite.

UVD
UVD

Darüber hinaus hat man sich dem „MSAA-Shader-Resolve-Problem“ (das Shader-Resolve wird normalerweise von den ROPs durchgeführt. Beim R600 übernehmen dies die ALUs; ob dies Absicht oder ein Defekt an den ROPs ist, ist weiterhin unbekannt) angenommen und dessen Effizienz erhöht. Erreicht wird dies laut David Nalasco durch eine höhere Taktrate des „Shader-Cores“. Genauere Details konnten wir bis jetzt leider noch nicht in Erfahrung bringen. Ob die Shadereinheiten tatsächlich mit einer höheren Frequenz als die restlichen GPU-Komponenten arbeiten, können wir derzeit nur vermuten. Darüber hinaus hat ATi auf dem RV670 nach eigenen Angaben die Performance bei Geometry-Shader-Berechnungen steigern können, was in Direct3D-10-Anwendungen (falls diese Gebrauch vom Geometry-Shader machen) einen Geschwindigkeitsschub bringen soll.