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

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

Was bei der GeForce4 verbessert wurde

LMA2

Verbessertes Z-Occlusion Culling

Der Hauptschwachpunkt der GeForce3-Implementierung, nämlich dass bei Anti-Aliasing kein Early Z Culling mehr möglich ist, wurde mit GeForce4 beseitigt. Das trug unter anderem mit dazu bei, dass das Einschalten von 2x Anti-Aliasing jetzt spürbar weniger Leistung zieht als noch auf der GeForce3. Eine weitere Ursache hierfür wird noch zu besprechen sein.

Die Early Z Logik musste für ein Funktionieren im Zusammenspiel mit Anti-Aliasing erweitert werden. Offenbar gab es da einige Probleme, denn erst in Detonator-Treibern ab 42.01 lässt sich Early Z in allen Anwendungen nachweisen und es muss in einigen Fällen zunächst explizit ab- und wieder angeschaltet werden, aTuner bietet hierfür im Direct3D-Panel eine entsprechende Funktion.

Mit den meisten früheren Treibern funktionierte es immerhin partiell, die Gründe für dieses seltsame Treiber-Verhalten sind jedoch unklar. Early Z sortiert etwa ein Viertel aller ankommenden Pixel gleich aus, doch leider ist es nicht möglich, diesen Vorteil komplett in Framerate umzusetzen, da die Pipelines bei zu vielen unsichtbaren Pixeln in Folge leer laufen und Leertakte einlegen müssen, ohne dass am Ende Pixel herauspurzeln. Aktives Early Z bringt immerhin ungefähr 10% mehr Geschwindigkeit.

Vereinfachter Crossbar Memory Controller für GeForce4 MX

Da jede MX-Version einer GeForce nur 2 Pipelines hat, ist der CBMC der GeForce4 MX in nur zwei Segmente unterteilt. Damit die Effizienz bei diesen Karten gegenüber dem "vollwertigen" CBMC geringer, mit der Ausnahme der GeForce4 MX420 mit nur SDR SDRAM, da deren effektives Speicherinterface von vornherein nur halb so breit ist.

Doch besser ein vereinfachter CBMC als kein CBMC: Eine auf GeForce2 MX Niveau herunter getaktete GeForce4 MX420 kann ihren Vorgänger sehr deutlich schlagen, auch wenn die Render-Architektur zunächst vergleichbar scheint (2 Pipelines á 2 bilinearen TMUs und ein 128 logische Bit breites Speicherinterface). Die GeForce4 MX Karten ab MX440 mit einem Speicherinterface von 256 Bit logischer Breite sind natürlich trotz der durch den erhöhten Verschnitt geringeren Effizienz deutlich schneller, da hier weitaus mehr "Roh-Bandbreite" zur Verfügung steht. Doch nun wieder zum allgemeinen LMA2.

Verbesserte Lossless Z Compression

Am Grundprinzip der GeForce3 wurde hier nichts geändert: Durch eine optimierte Umkodierung der Bitfolgen-Abschnitte, um die langen Null-Folgen zu verkürzen, konnte jedoch die Wahrscheinlichkeit gesteigert werden, dass die 4:1-Komprimerung tatsächlich klappt. Offensichtlich wurde der Aufbau der Z-Werte noch mal sorgfältig untersucht und mit den neuen Erkenntnissen die Komprimierungswahrscheinlichkeit gesteigert. Es muss nun weniger oft eine unkomprimierte Kachel übertragen werden, was logischerweise Bandbreite einspart.

Fast Z-Clear

Schon in Hyper-Z vorhanden, nun auch Teil von LMA2: Ein schnelles Löschen des Z-Buffers. Wenn ein Bild fertig gerendert wurde, wird die Speicher-Adressierung dahingehend modifiziert, dass jetzt der fertige Framebuffer vom RAMDAC ausgelesen und somit auf dem Monitor dargestellt wird (was den Framebuffer zum Frontbuffer macht), während der ehemalige Framebuffer jetzt den neuen Backbuffer stellt. Bevor neue Polygone verarbeitet werden können, muss dieser Speicher erst einmal gelöscht werden, das gilt auch für den Z-Buffer (der allerdings nicht "geswappt" wird). Herkömmliche Renderer überschreiben nun für jedes Pixel den zugehörigen Z-Wert mit einem vom Programmierer vorgegebenen Defaultwert.

Fast Z-Clear geht geschickter vor: Hierfür muss der (für Z Compression ohnehin schon gekachelter) Z-Buffer durch einen weiteren Buffer ergänzt werden, welcher für jede Z-Kachel bestimmte Statusinformationen aufnehmen kann. Dieser übergeordnete Puffer liegt sinnvollerweise direkt im Chip. Fast Z-Clear fasst zunächst nur diesen Verwaltungs-Buffer an und setzt kachelweise den Status auf "gelöscht".

Wird die Z-Kachel nun bearbeitet, bekommt der Z-Cache eine "leere" Z-Kachel vorgesetzt. Am Ende wird dann wie üblich die gesamte Kachel in den Z-Buffer geschrieben. Es ist natürlich unwahrscheinlich, dass wirklich alle Z-Werte der Kachel bearbeitet wurden, was zu neuem Verschnitt führt, doch die Vorteile sind insgesamt so immens (hinzu kommt ja noch Z-Compression), dass es sich lohnt, mit diesem Verschnitt zu leben.

Übrigens lässt sich das Verfahren noch zu einem "Hierarchical Z-Buffer" verfeinern, wo mehrere Z-Buffer in unterschiedlichen Auflösungen verwaltet werden. Die GeForce4 Ti verfügt lediglich über einen Status-Buffer, um pro Z-Kachel 1 oder 2 Bit zu speichern. Es ist allerdings davon auszugehen, dass der neue Status-Buffer für den Z-Buffer bei hohen Auflösungen (unter Umständen auch mit Anti-Aliasing) nicht mehr komplett in den Chip passt. Dann muss der Rest in den lokalen RAM und der Status-Buffer wird quasi zum Cache.

Quad Cache

nVidia vermarktet bei der GeForce4 auch das bislang namenlose Cache-System. Gepuffert wird praktisch alles, sogar Puffer werden gepuffert. So hat der Vertex Cache, der im Zusammenhang mit der T&L-Funktionalität im lokalen Grafikkarten-RAM einige Megabyte an Geometriedaten aufnehmen kann, seinen eigenen Cache. nVidia hat das Cache-System offenbar einer Revision unterzogen und optimiert. Was im einzelnen geändert wurde, scheint jedoch Betriebsgeheimnis zu sein.

Auto Pre-Charge

Bei modernen CPUs gibt es ausgetüftelte "Branch Prediction" Logiken. Diese versuchen, den Zielort von Programm-Verzweigungen vorherzusagen. Vom als wahrscheinlich angenommen Ziel werden dann schon einmal die ersten Speicher-Inhalte im voraus in den Cache geladen. Hat die Vorhersage funktioniert, liegen die benötigten Daten schon vor, wenn sie gebraucht werden, und die Pipeline gerät nicht ins Stocken. Schlägt die Vorhersage fehl, muss die Pipeline auf Kosten einiger dann nutzloser Takte komplett geleert werden, was allerdings bei Programm-Verzweigungen ansonsten ohnehin angesagt wäre.

Ein nicht exakt gleiches, aber ähnliches Problem gibt es auch bei Grafikkarten: Wenn der Cache neue Daten braucht, muss der Speichercontroller nach der Berechnung der Zieladresse den entsprechenden Zielort erst einmal vorbereiten. Es vergehen einige Takte, ehe die Daten dann auch tatsächlich ausgelesen werden können, um dann über den Controller in den Cache zu wandern. Die Auto Pre-Charge Technik versucht eine Vorhersage von Speicherzellen, die in Kürze "angefasst" werden, und bereitet sie schon mal seelisch und moralisch darauf vor: Die im groben zweidimensional segmentierten DRAM-Gatter werden für einen Datentransfer initialisiert. Trifft die Vorhersage tatsächlich zu, können eine Handvoll Takte gespart werden.

Das erscheint zunächst sehr wenig, doch angesichts des vielen Verkehrs über den Bus bringt das Kürzen von Latenzzeiten insgesamt eine durchaus spürbare Beschleunigung. Da z.B. Framebuffer, Z-Buffer und Textur-Speicher über den gesamten RAM verteilt sind, muss der Speichercontroller ständig zu neuen Zielorten hin- und herspringen. Auto Pre-Charge sorgt dafür, dass die Pipelines weniger oft ins Stocken kommt und wertlose Warte-Zyklen einlegen müssen.

Fazit

So wie keine der originalen LMA-Maßnahmen für sich alleine für die große Effizienz-Steigerung verantwortlich ist, so ist auch keine einzelne Verbesserung oder Neuerung bei LMA2 der Bringer - das Zusammenspiel macht´s. Auch das Anti-Aliasing wurde dahingehend verbessert: Im 2x-Modus findet, sofern es sich um eine Vollbild-Anwendung handelt, der Scanout direkt aus den beiden Multisample-Buffern statt. Auf ein Downfilter-Buffer wird verzichtet, was zwar etwas mehr RAM kostet, da man beim Pageflip beide Frontbuffer (statt einem Downfilter-Buffer) im Speicher halten muss. Durch diese Methode wird aber immerhin ein Schreibzyklus pro Pixel gespart.

An dieser Stelle sei noch erwähnt, dass hohe Bildwiederholfrequenzen generell die Bandbreite ebenfalls belasten, da der RAMDAC für jedes Bild die Daten neu aus dem Speicher auslesen muss. Allerdings ist der Effekt in der Praxis sehr gering. Mit Benchmarks lässt sich die Performance von 60 Hz vs. augenfreundlichen 100 Hz kaum nachweisen. Das liegt allerdings auch daran, dass schwachbrüstigere Karten der Performance wegen ohnehin in geringeren Auflösungen betrieben werden, wodurch der Bandbreiten-Verbrauch durch den RAMDAC-Scanout wieder sinkt.

Falls in diesem Artikel unrichtige Darstellungen bemerkt werden, bitten wir um eine Notiz im Forum oder einen Hinweis per Mail.

Folgende Quellen wurden verwendet:

Insbesondere danken möchte ich: Demirug, zeckensack und nggalai für ihre Unterstützung.