Vorstellung des GeForce4: nVidia schlägt zurück

Light-Speed Memory Architecture II

Das Problem vieler heutiger Grafikkarten, bzw. der auf ihnen verbauten Chips, ist die deutlich schnellere Entwicklung bei den Grafikchips im Gegensatz zum Grafikspeicher. Die Schere zwischen beiden Geschwindigkeiten klafft immer weiter auseinander. So hat man seit nunmehr zwei Jahren Grafikchips, die eine Füllrate in der GigaTexel-Region (1 Milliarde texturierte Pixel) zu bieten haben, allerdings werden diese zunehmend durch die nur begrenzt wachsende Speicherbandbreite ausgebremst. Problematisch an dieser Sache ist, dass die zunehmende Tiefenkomplexität aktueller Spiele immer mehr Pixel dazu verdammt, gar nicht auf dem Bildschirm zu sehen zu sein, da sie, wenn die Szene fertig berechnet worden ist, von anderen Objekten verdeckt werden. Dieses Phänomen nennt man auf Neudeutsch Overdraw.

Seit geraumer Zeit gibt es nun schon Techniken, um die vom Overdraw geradezu verschwendete Bandbreite effektiver zu nutzen. Einsamer Primus in diesem Bereich ist eindeutig die Kyro-Reihe von ImgTech/PowerVR. Diese nutzen das sogenannte Tile-Based Rendering, bei dem nur die am Ende wirklich auf dem Bildschirm sichtbaren Pixel auch komplett berechnet werden. Ati nutzt seit der Einführung des originalen Radeon-Chips eine Kombination aus Techniken unter dem Marketingbegriff "HyperZ". Seit Erscheinen des GeForce3 vor knapp einem Jahr ist sich auch nVidia nicht mehr zu schade, ihre Chips mit bandbreitenschonenden Features auszustatten und verpasste diesen den Sammelbegriff "Light Speed Memory Architecture".

Die LMA-II besteht aus mittlerweile sechs einzelnen Komponenten, von denen jede für sich dazu beitragen kann, exzessive Bandbreitennutzung durch Texturoperationen zu minimieren. Zu Zeiten des GeForce3 waren es demgegenüber nur vier Elemente, die sich in „verbesserter“ Form auch in der LMA-II wiederfinden. Im Einzelnen wären dies der Cross-Bar Memory Controller, Z-Occlusion Culling und Lossless Z-Compression. Neu hinzugekommen sind eine QuadCache genannte Cache-Ansammlung, ein Auto PreCharge für das lokale GrafikRAM sowie ein Fast Z-Clear nach dem Vorbild von ATIs HyperZ. Nachfolgend ein paar Worte zu jeder Komponente.

Cross-Bar Memory Controller (CBCM):
Bei nahezu jeder herkömmlichen Grafikkarte (sogar inklusive der Radeon8500) arbeitet ein Memory-Controller, der die diversen notwendigen Speicherzugriffe, üblicherweise mit 128Bit (DDR), durchführt. An und für sich ist das eine gute Sache aber es gibt hier einen Haken. Jedesmal, wenn ein Zugriff durchgeführt wird, beim dem weniger als 128Bit (DDR) übertragen werden müssen, wird die überschüssige Kapazität des Controllers einfach verschenkt.

Beim nV25 (und auch beim nV20) kommt dagegen ein vierfacher Speichercontroller zum Einsatz, der jeweils unabhängig mit 32Bit (DDR) arbeitet. Diese, bei Bedarf auch zusammenschaltbaren Einheiten mit dann ebenfalls 128Bit (DDR), ermöglichen eine wesentlich effizientere Nutzung der zur Verfügung stehenden Speicherbandbreite, da oftmals nicht die vollen 128Bit (DDR) während eines Zugriffes benötigt werden. Im Idealfall (Zugriffe mit weniger als 33Bit (DDR) können so bis zu 75% Bandbreite eingespart werden, die dann für andere Aufgaben zu Verfügung stehen. Der nV17 enthält ebenfalls diese Technik, jedoch nur in zweifacher Ausführung (2x64Bit (DDR)), d.h. der maximale Nutzen durch den CBMC liegt bei 50% gesparter Bandbreite.

QuadCache:
Für Primitive (grundlegende geometrische Elemente), Vertex-Daten, Texturen und bereits in Bearbeitung befindliche Pixel kommt jeweils ein eigener in Größe und Aufbau optimierter Cache zum Einsatz. Dieser hält häufig benötigte Daten vor, die ansonsten umständlich aus dem Grafikspeicher geladen werden müssten. Der Effekt ist vergleichbar den First- und Second-Level Caches, ohne die sich selbst ein moderner Prozessor jenseits der 1,5GHz auf das Leistungsniveau eines Pentium133 ausbremsen ließe.

Laut nVidia sind diese Caches optimal an das jeweilige Anforderungsprofil angepasst, was auch nötig ist, da sie ja im Chip integriert sind und dort jeder unnötige Transistor bares Geld wert ist. Näheres hierzu ist bis dato nicht zu erfahren gewesen, beim GeForce3 jedoch umfasste z.B. der Vertex-Cache 24 Einträge, während die anderen Caches in der Form noch nicht vorhanden waren (oder zumindest nicht beworben wurden).

Z-Occlusion Culling:

Wie oben schon angesprochen, ist eine Überlagerung mehrerer Objekte in aktuellen 3D-Spielen kaum zu vermeiden. Je komplexer die Grafik des Spiels ist, desto höher wird auch dieser Overdraw und kostet damit im Verhältnis mehr und mehr Leistung.

Sehr schön zu sehen ist der Effekt beim Villagemark, bei welchem eine von den Rohdaten her fast schon lächerlich wirkende KyroII-Karte sowohl die aktuellen High-End Chips von Ati als auch nVidia weit hinter sich lässt und der einen absichtlich herbeigeführten, besonders hohen Overdraw-Faktor von bis zu 10 aufweist. Das bedeutet, das bis zum zehnfachen der sichtbaren Bildpunkte berechnet werden müssen, obwohl sie hinterher nicht zu sehen sind. Genau diesem Problem wird versucht, mittels Z-Occlusion Culling (dem Entfernen verdeckter Objekte) beizukommen.

Wie kann man im Vorfeld erkennen, dass bestimmte Bildpunkte, oder idealerweise ganze Bereiche, später nicht zu sehen sind? Die Lösung hierfür ist eigentlich recht naheliegend. Da man auf dem Bildschirm kein heilloses Durcheinander von sich gegenseitig überlagernden Objekten zu sehen bekommt, muss es ja schon irgendeinen Wert geben, der bestimmt, wie weit ein bestimmtes Objekt im Sichtfeld vom Betrachter entfernt ist. Diesen Wert, die Tiefeninformation, nennt man Z-Wert und er wird, naheliegenderweise, im Z-Buffer aufbewahrt. Wenn man nun vor dem Rendering prüft, ob ein bestimmtes Pixel evtl. schon von einem anderen verdeckt wird, kann man sich natürlich die weitere Berechnung sparen, was wiederum der verfügbaren Bandbreite stark zugute kommt.

Ein Unterpunkt ist die Anwendung dieses Verfahrens auf eine komplette Region des Bildschirminhaltes, die sogenannnte Occlusion Query. Dies muss aber zur Zeit noch per Software-Anforderung erfolgen, d.h. Das jeweilige Programm muss den Grafikchip dazu auffordern, eine Region zu prüfen. Prinzipiell ist diese Methode natürlich noch deutlich effizienter, erfordert jedoch den Einsatz hierfür ausgelegter Software.

Lossless Z-Compression:
Hierunter versteht nVidia eine Komprimierung für die zu schreibenden Tiefeninformationen (Z-Buffer), wobei die Kompressionsrate bei 4:1 liegen soll, wie schon beim GeForce3. Nähere Informationen zu diesem Feature liegen uns leider noch nicht vor, so dass man erst einmal kritisch nVidias Behauptung, der Datenverkehr vom und zum Z-Buffer könne hierdurch um den Faktor 4 reduziert werden, im Hinterkopf behalten sollte.

Auto PreCharge:
Dieses Feature dient dazu, das RAM nach einem Zugriff auf einen Bereich des RAM und vor den Zugriff auf einen anderen Bereich möglichst schnell wieder bereit zum Aufnehmen neuer Daten zu machen. Auch der im PC verbaute Hauptspeicher muss z.B. eine gewisse Zahl an Taktzyklen warten, bis neue Daten gesendet werden können. Je höher die Taktfrequenz des RAM, desto höher fällt im Allgemeinen auch die Anzahl dieser Zyklen aus. nVidia spricht hier von bis zu 10 Taktzyklen, die nötig sein können, bis ein Speicherbereich geschlossen und der nächste geöffnet und bereit zur Datenübertragung ist. Auto PreCharge soll nun per im Chip berechneter Vorhersage Bereiche aktivieren, die in nächster Zeit (im Microsekundenbereich) möglicherweise zum Ziel eines Datentransfers werden. Diese werden dann auf Verdacht "pre charged" und so kann die Wartezeit auf die "normale" Latenz von 2-3 Zyklen reduziert werden.

Fast Z-Clear:
Den Z-Buffer haben wir ja vorhin bereits angesprochen. Damit kein Chaos auf dem Bildschirm entsteht, müssen die Werte darin natürlich exakt sein. Restbestände von einem Pixel aus dem letzten fertig gerenderten Frame können das Ergebnis verfälschen und Pixelfehler wären die Folge. Deswegen muss vor jedem neuen zu berechnenden Bild jeder wert im Z-Buffer auf Null gesetzt werden. Das kostet im Prinzip genausoviel Bandbreite, wie jeder andere Zugriff. Für ein einziges Bild in 1024x768 in 32Bit würden alleine für diesen Z-Buffer Reset 3,1MB an Bandbreite verloren gehen (multipliziert mit der Anzahl der Bildrate, bei angenommenen 30 Bildern/s also schon 95MB/s) , die man genausogut sinnvoll verwenden könnte.

Ganz wie beim Vorbild HyperZ in ATIs Radeon-Serie, die selbiges schon seit Mitte des Jahres 2000 durchführt, werden hier die Z-Buffer nicht einzeln mit Null überschrieben, sondern in einem Rutsch auf den Ursprungswert gesetzt, prinzipiell einem Druck auf den Reset-Knopf nicht unähnlich, nur das ausschließlich der Bereich des Grafikspeichers gelöscht wird, in dem sich der Z-Buffer befindet.

Interessant ist in diesem Zusammenhang noch die Tatsache, dass es bei der GeForce3 noch ein weiteres Features gegeben hat, welches ebenfalls zur Reduzierung der Bandbreite diente, allerdings in diesem Falle zur Reduzierung der Geometriedaten.

Die Rede ist von den sogenannten Higher Order Surfaces. Vielen mögen sie schon einmal in Form von ATIs TruForm über den Weg gelaufen sein. Im wesentlichen ging es bei nVidias Weg der HOS darum, komplexe gewölbte Flächen nicht mehr mittels einer Unmenge von Dreiecken über den AGP-Bus zu jagen, sondern nur noch durch eine komplizierte mathematische Formel zu beschreiben. Nötige Veränderungen wurden dann per Variablenänderung an der Formel durchgeführt. Diese Feature ist leider zeitlebens ein Phantom geblieben. In der offiziellen Produktbeschreibung zur GeForce3 taucht es zwar auf, aber seit den Detonator-Treiber in Version 20.80 ist es nicht mehr verfügbar und nun scheint nVidia dies ganz aus der Feature Liste gestrichen zu haben. Wer weis, vielleicht um es beim nV30 wieder als neues Feature zu vermarkten?