Ein Blick auf die Effizienz-Features bei GeForce 3/4

20. März 2003 / von aths / Seite 2 von 5

Wie die GeForce3 Bandbreite spart, Teil 1

Methode 1) - Vermeidung von überflüssiger Arbeit

Z-Occlusion Culling (Early Z)

Wie bereits besprochen, wird das Problem des Grafik-Renderings in viele kleine Teilprobleme zerlegt. Wenn die Grafikkarte die Polygon-Daten bekommt, muss sie zunächst feststellen, welche Bildschirmzeilen es bedeckt, das wird im Triangle Setup erledigt. Für jede Zeile wird außerdem berechnet, bei welcher Position das Dreieck anfängt und wo es aufhört. Dann wird das Dreieck Zeile für Zeile gerendert, (zumindest die GeForceFX rendert schon blockweise mit je 2x2 Pixeln, was den "Dreieckskanten-Verschnitt" senkt).

Ob die vom Triangle Setup erzeugten Pixel wirklich sichtbar sind, stellt sich allerdings erst am Ende der Pipeline heraus, wenn nämlich der Z-Test gemacht wird. Dabei prüft die Grafikkarte, ob sich nicht schon ein Pixel an dieser Position befindet, der durch seine Lage in der Tiefe des zu erstellenden 3D-Raumes den eben fertiggerechneten Pixel überdeckt. Das Triangle Setup der GeForce3 ist nun so modifiziert, dass dieser Z-Test vorgenommen wird, bevor das Pixel überhaupt erst in die Pipeline kommt. Somit kann gegebenfalls der Texturiervorgang und damit wertvolle Bandbreite gespart werden. Wegen dem frühen Z-Test nennt man diese Methode auch "Early Z", wobei es komplett eigentlich "Early Z Culling" heißen müsste.

Damit das Sinn macht, muss der Chip einen Pixel schneller verwerfen können, als die Berechnung dieses Pixels dauern würde. Zum Glück stehen pro Pipeline ohnehin schon 4 Z-Test-Units zur Verfügung. Dies gehört zu den Teilen einer Pipeline, die mehrfach ausgelegt werden müssen, wenn man quasi füllratenfreies Multisampling-Anti-Aliasing ermöglichen möchte. Dank 4 Pipelines stehen insgesamt 16 Z-Units bereit, so dass pro Takt bis zu 16 Pixel verworfen werden können.

Die ganze Sache klingt etwas einfacher, als sie ist. Damit dieses Feature funktioniert, muss das Triangle Setup von den Pipelines durch einen Cache entkoppelt werden. Eine weitere Schwachstelle ist, dass bei der GeForce3 das Early Z nicht im Zusammenspiel mit Multisampling Anti-Aliasing funktioniert, da die Z-Einheiten, die ansonsten vom Early Z belegt sind, dann fürs Multisampling gebraucht werden. Ungeklärt ist bislang, ob in diesem Fall nicht noch wenigstens die Bandbreite fürs Texturieren gespart wird.

Problematisch ist ebenfalls, dass unsichtbare Pixel gehäuft auftreten. Dann wird der Triangle Setup Cache schneller geleert als gefüllt und letztlich laufen die Pipelines leer. Bei komplexen Pixel Shadern ist es zwar noch immer besser, Leerlauf zu haben, als etliche Takte für das Rendern eines unsichtbaren Pixels zu vergeuden, aber der Vorteil von Early Z hat eben auch seine Grenzen. Erstmalig kam ein Early-Z-Verfahren übrigens im originalen Radeon-Chip zum Einsatz.

Methode 2) - Redundanz-Vermeidung

Daten nennt man redundant, wenn sie die gleiche Information mehrfach enthalten. Redundante Daten erlauben somit Kompression. Bei unserem Speicherbandbreiten-Problem treten zwei Arten von Redundanzen auf:

"Verschnitt"
Übertragung sehr ähnlicher Daten

Betrachten wir zunächst den Verschnitt: Dieser kommt zustande, weil pro Takt immer die komplette Busbreite in Anspruch genommen wird. Angenommen, es liegt eine Anforderung für das Laden eines Z-Wertes vor. Das sind 32 Bit, die über den Bus müssen. Bei einem Interface von 128 Bits und DDR-Technologie werden daraus 256 Bit. Somit gibt es 256 - 32 = 224 "Füllbits", die ohne Nutzen sind, aber zwangsweise anfallen. Um den Verschnitt gering zu halten, gibt es schon längst Techniken wie Burst Write. Dafür werden mehrere Daten gesammelt, die dann mit einem Schlag übertragen werden. Das funktioniert allerdings nur dann, wenn diese Daten im Grafik-Speicher auch nebeneinander stehen. Ansonsten muss der eine große Schreibzyklus in mehrere kleine unterteilt werden, und dann fallen wieder Füllbits an.

Der Verschnitt lässt sich in Effizienz umrechnen. Angenommen, im Durchschnitt gibt es 1/4 Verschnitt. Dann beträgt die Effizienz 75%, was nichts anderes bedeutet, als dass für die praktisch vorhandene Bandbreite mit einem entsprechend schmaleren Interface gerechnet werden müsste. Die Informationen auf der Verpackung einer Grafikkarte werden natürlich nicht "effiziente" Bandbreiten, sondern nur theoretische Maximalwerte angeben. Der Trend ging vor einiger Zeit dazu, die "effektive Bandbreite" sogar hochzurechnen, weil z.B. der Verschnitt minimiert wurde (beispielsweise GeForceFX mit angeblich 48 GB/Sekunde). Das ist aber auf gut Deutsch alles Quark mit Sauce. Mehr Bandbreite als den theoretischen Spitzenwert liefert keine Karte, auch nicht "effektiv".

Ein Speicherinterface mit 128 Bit und 200 MHz DDR-RAM ist in jedem Fall weniger effizient als ein Interface mit gleicher Breite, aber 400 MHz SDR-RAM. Denn DDR-RAM macht das Interface doppelt so breit, wodurch der Verschnitt erheblich steigt. Die Voodoo5 umging das Problem elegant durch den Einsatz von gleich 2 bzw. 4 Chips, so dass es dementsprechend gleich 2 oder 4 unabhängige Speicher-Interfaces gibt. Allerdings verbraucht ein Mehrchipsystem auch mehr Bandbreite, was diesen Vorteil zum Teil wieder relativiert. Die GeForce3 bot hier eine deutlich intelligentere Lösung:

Crossbar Memory Controller (CBMC)

Das Speicherinterface der GeForce3 besteht aus vier einzelnen Interfaces. Dazu wird der Speicher in vier Teile segmentiert und jedes Interface kann auf jedes Segment zugreifen. Dazu wird der Speicherzugriff der Pipeline auf den RAM mit einem Cache entkoppelt und der CBMC verteilt die Last so gleichmäßig wie möglich. Effektiv stehen 4 Controller á 32 Leitungen zur Verfügung (mit DDR pro Takt = 64 Bit). Der Verschnitt wird drastisch reduziert und dieser angenehme Effekt ist dann auch für den Löwenteil der Effizienzsteigerung verantwortlich. Der ab GeForce3 vorhandene Crossbar Memory Controller mit dieser Effizienz ist unseres Wissens einzigartig bei Grafikkarten in dieser Klasse.

Die Stärke des Speicher-Controllers besteht aber auch darin, dass er gleich den Z-Buffer mit löschen kann. Andernfalls müssten das die Pipelines übernehmen (welche dann natürlich auch den Speicher-Controller verwenden), doch ein Controller mit eingebauter "Z Clear"-Logik ist natürlich schneller.