GeForce4 Ti: Pro und Kontra

11. Februar 2002 / von aths / Seite 1 von 3

Eine gute Hardware-Firma hat heutzutage nicht Kunden, sondern Fans. Und das Marketing von Hardware-Firmen tut einiges, um ihren Fans zu gefallen. Beim Start der GeForce4 Ti hat die nVidia Marketing-Abteilung ganze Arbeit geleistet - wieder einmal. Wir vom 3DCenter stehen nun zwischen den Fronten: Für die einen ist eine Karte grundsätzlich gut, weil sie von XYZ kommt, für die anderen grundsätzlich schlecht - aus dem gleichem Grunde.

Aber wenn wir es schon nicht allen recht machen können, so wollen wir es uns nun wenigstens mit allen verscherzen :-) ... indem wir zunächst Pro und dann Kontra dem neuen nVidia-Chip argumentieren. Denn die GeForce4 Ti ist nicht nur eine GeForce3 mit zwei VertexShader-Pipelines, so viel vorneweg!

   Pro

Bevor der NV25 entwickelt wurde, haben sich die nVidia-Ingenieure den NV20 und NV2A (X-Box Chip) genau angesehen, und viele Schwachstellen ausgemerzt. Die Änderungen sind dabei klein, aber zahlreich. Die meisten laufen darauf hinaus, das Problem der Latenzzeiten zu minimieren. Denn ehe auf den RAM zugegriffen werden kann, müssen Pausen eingelegt werden, wodurch die Gesamtleistung erheblich gedrückt werden kann.

Die Speichercontroller wurden im Hinblick auf dieses Problem verbessert. Da man an den RAM-Refreshzeiten an sich nichts ändern kann, wurden Techniken wie vorausschauendes Laden oder Sammeln von Daten, um sie in einem einzigen Rutsch ("Burst Write") zu schreiben, optimiert. Im gleichen Zuge bekamen vier wichtige Caches auf ihre jeweiligen Bedürfnisse besonders angepasste Logik. Das erhöht die Effizienz ebenfalls, denn kann aus dem Cache gelesen werden, tritt das Problem mit den RAM-Latenzzeiten gar nicht erst auf.

Auch die VertexShader-Pipeline wurde sanft verbessert. Das Problem stellt sich hier folgendermaßen: Fast alle Operationen nehmen für sich genommen mehr als einen Takt in Anspruch. Jede Operation durchläuft aber die Pipeline. Während gerade das Ergebnis einer Operation in den Speicher geschrieben wird, kann ein anderer Teil der Pipeline z.B. für den nächsten Befehl schon eine Rechenoperation ausführen. Auch wenn nun ein Befehl beispielsweise vier Takte Durchlaufzeit benötigt, so kann doch pro Takt ein Ergebnis ausgegeben werden! So weit der Idealfall.

Weil die Art und Reihenfolge der Programm-Befehle jedoch nicht vorhersehbar ist, kann eine 100%ige Auslastung aller Pipeline-Bestandteile nicht gewährleistet werden. Das äußert sich so, dass doch nicht pro Takt ein Befehl fertig abgearbeitet ist. Nun enthalten X-Box Chip und NV25 gleich zwei Pipelines, die parallel arbeiten können. Die eingehenden Vertices bedingen sich aus Hardware-Sicht gegenseitig nicht, so dass eine Verteilung auf zwei Einheiten kein Problem ist. Um eine optimale Auslastung beider Shader zu erreichen, ist einiger Aufwand nötig. Der NV25 wurde hier optimiert - und dies soll so weit gehen, dass bestimmte Logik-Bausteine gemeinsam verwendet werden können.

Auch das normale Rendering wurde beschleunigt. Dafür sind in erster Linie zwei Gründe verantwortlich: Einerseits kann der Z-Buffer viel schneller gelöscht werden als im NV20, andererseits wurde die Z-Buffer-Komprimierung verbessert.

Nach jedem gerendertem Frame muss der Z-Buffer zurückgesetzt werden - und zwar normalerweise Pixel für Pixel! Das wird nun im NV25 umgangen. Dazu muss man wissen, das schon seit einiger Zeit eigentlich alle Grafikchips das Bild in Kacheln aufteilen. Es reicht nun beim NV25, pro Kachel einen globalen Z-Wert zu schreiben, um so die gesamte Kachel zu löschen.

Komprimierung ist ein schwieriges Problem: Gerade beim Z-Wert, welcher die "Tiefe" des Pixels im Raum angibt, sollten keine Ungenauigkeiten auftreten. Die Kompression muss also verlustfrei erfolgen. Nun lässt sich aber nicht jede beliebige Bitfolge verlustfrei komprimieren. Der NV25 geht hier im Prinzip genauso vor wie der NV20: Es wird versucht, den Z-Wert zu komprimieren.

Stellt sich heraus, dass das mit Datenverlust verbunden wäre, wird eben der unkomprimierte Wert gesendet. Weil das Verfahren zur Kompression im NV25 verbessert wurde, können nun mehr Z-Werte als früher geschrumpft werden, was Bandbreite spart. Gleiches gilt für den vorgezogenen Z-Test, für welchen nun ein Cache verwendet wird - so lassen sich einige Zugriffe auf den RAM gleich ganz einsparen.

Der vorgezogene Z-Test sorgt übrigens für eine HSR-Technik namens "Z-Culling" (HSR = verdeckte Flächen aus dem Bild entfernen). Falls strenges Front-to-Back-Rendering eingehalten wird, werden damit nur noch sichtbare Bereiche gerendert. Die Dreiecke entsprechend zu sortieren, ist allerdings CPU-Arbeit und daher nur begrenzt machbar. Letztlich wird hier HSR noch auf herkömmlichen Wege mittels Z-Buffer gemacht. Durch den Cache kann das Z-Culling ein wenig beschleunigt werden.

Bandbreite sparen war auch das Ziel, als das Anti-Aliasing verbessert wurde. Das Downsampling für Quincunx wird mittels einem verbesserten Line-Cache deutlich effizienter als früher verwirklicht. Desweiteren wird beim Downsampling generell ein Schreibzyklus pro Pixel gespart. Eine Eigenschaft beim Multisampling ist, dass nur pro Pixel (und nicht pro Subpixel) ein Farbwert berechnet wird. Dafür wird an einer bestimmten Stelle aus der passenden Textur gelesen. Diese Stelle wird nun mit einem geringerem Fehleranteil pro Subpixel berechnet, was sich positiv auf die Bildqualität auswirkt.

An Speicherplatz mangelt es bei der GeForce4 Ti wahrlich nicht: Satte 128 MB sind verbaut. Heutzutage noch weitestgehen ohne Nutzen, wird sich die großzügige Dimensionierung in Zukunft als Vorteil erweisen. Das alles macht die GeForce4 Ti nur schneller als eine gleich getaktete GeForce3. Doch auch featureseitig gibt es eine Reihe Neuigkeiten:

Die Dualmonitor-Technik ist relativ flexibel und bringt im Treiber zusätzliche nette Features mit. Mit diesen Features verhält es sich wie mit Anti-Aliasing: Vorher denkt man, man braucht es eigentlich nicht. Hat man es erst einmal, möchte man sich davor nicht wieder lösen. Wer einen großen Schreibtisch und zwei Monitore hat, kommt in Genuss einiger Goodies.