nVidia NV20: HSR & Occlusion Detection

15. Dezember 2000 / von Leonidas ... Update vom 19. Dezember

Bekanntermaßen will nVidia baldmöglichst den Detonator 7.27 vorstellen, dieser soll auch der erste offizielle Detonator der 7er Serie werden. Die 7er Serie unterstützt erstmalig nVidia´s kommenden Grafikchip NV20 (bisher bekannte Spezifikationen). Einige Quellen sprechen von nächster Woche, andere vom 4.1.2000 - möglicherweise stimmt beides: Nächste Woche ist der Treiber inoffiziell zu haben und im neuen Jahr dann offiziell auf nVidia´s Seiten.

Genau diese 7.27er Detonatoren sind das Thema einer geleakten Informationen, welche uns "zugeflogen" ist: Danach wird aus Entwickler-nahen Kreise vermeldet, der 7.27er Detonator würde - wie die aktuellen 3dfx-Treiber - ein HSR-Feature mitbringen. Im Gegensatz zu 3dfx´ experimenteller Software-Lösung soll nach diesen Informationen das HSR bei nVidia in Hardware realisiert werden. Die 3dfx´schen Bildfehler sollen damit nicht auftreten und ein Performanceschub in Q3A 1024*768 @ 32 Bit von 25 Prozent erreicht werden. Zumindestens beim 7.27er wäre das HSR aber nur über einen Registry-Hack aktivierbar - notfalls auch für alle anderen bisherigen nVidia-Karten. So zumindestens die geleakten Informationen.

Mein persönlicher Reim darauf lautet folgendermaßen: Das Hidden Surface Removal (HSR) bei einer T&L-Architektur nur etwas in Hardware bringt (d.h. die Grafikkarte führt es aus), sollte klar sein. Wobei die Unterscheidung zwischen "Software" und "Hardware" so aussieht, daß bei Software die CPU das HSR durchführt (wie wohl bei den HSR-Hacks zu 3dfx´ aktuellem Voodoo5-Treiber), und bei Hardware die Grafikkarte - und in beiden Fällen immer nach der Transformationsberechnung (daß "T" aus T&L).

Software würde ungünstigerweise bei einer T&L-Karte bedeuten, daß die Grafikkarte die ganzen Geometriedaten, welche sie errechnet hat, noch einmal über den AGP-Bus zur CPU schickt, damit diese das HSR errechnen kann und die übrig bleibenden Daten wieder über den AGP-Bus zurückschickt - höchst uneffizient, auch aus Latenz-Erwägungen heraus. Hardware würde bedeuten, daß dies der Grafikchip selbst löst - bei einem T&L-Beschleuniger sicher weitaus sinnvoller. Da jedoch GeForce 1/2 wohl keine verborgenen :-) Hardware-HSR-Einheiten besitzen und der 7er Treiber ja eigentlich schon auf nVidia´s NV20 ausgelegt ist, bedeutet dies wohl ziemlich eindeutig, daß HSR auf den momentanen nVidia-Karten eher zweifelhaft wäre.

Mich würde dabei stark interessieren, wie genau nVidia das HSR in Hardware implementiert - auch bei 3dfx´ Software-Hack steht diese Frage noch offen. Dato ist von einem vorgezogenen Z-Buffer-Vortest nach der Geometrieberechnung auszugehen, immerhin stehen dann schon alle Dreiecks-Koordinaten und Z-Buffer-Daten - perspektivisch korrekt - zur Verfügung. Richtigerweise sollte man dies dann Occlusion Detection nennen - so steht es auch auf der Featureliste der X-Box (mit dem NV20-Abkömmling NV2A). Konventionelle Renderer führen den Z-Buffer-Test (d.h. die Überprüfung, ob ein gerenderter Pixel sichtbar ist oder von einem anderem überdeckt wird) auf Pixel-Ebene an mehr oder weniger letzter Stelle der Rendering-Pipeline aus. Die Lösung auf Pixel-Ebene verbraucht natürlich ziemlich viel Speicher, für 1024*768 und einer Z-Buffer-Tiefe von 32 Bit (im gewöhnlichen gleich der Rendering-Tiefe) sind das immerhin exakt drei MB Grafikkarten-Speicher.

Eine gute Möglichkeit bezüglich der technischen Umsetzung des HSR-Features wäre, daß man nach der Transformations-Berechnung einen dreiecksbasierte Z-Buffer-Vortest dazwischenschiebt. Man müsste alle fertigen Dreieckskoordinaten (3 Punkte im Raum) sowie den Z-Buffer-Wert des am weitesten vorne liegendsten Pixel dieses Dreiecks speichern. Das sind für die Koordinaten jeweils 16 Bit für X- und Y-Koordinate, davon drei Stück plus der einmalige 32 Bit Z-Buffer-Wert macht ideale 128 Bit = 16 kB Speicherbedarf pro Dreieck (ideal, weil dies bei einem 128bittigen Speicherinterface genau einen Zugriff darstellt). Bei 15.000 Dreiecken (Q3A) wären das im übrigen nur 240 kB - und dies ist mit Sicherheit einfacher zu handeln als die normalerweise benötigten drei MB für einen konventionellen Z-Buffer.

Der Punkt, solche Listen zu erzeugen, ist allerdings bei weitem der einfachste. Der Vergleich von 15.000 Dreiecken bezüglich der Frage, ob sie sich den nun überlappen und wenn ja, welche wirklich komplett überdeckt sind, ist eine ziemliche Rechen-Herausforderung. Der Grafikchip (oder die CPU, wenn sie diese Arbeit erledigen muß) weiss ja nun vorher nichts von der Anordnung der Dreiecke im entgültigen Bild und müsste theoretisch alle Dreiecke mit allen anderen vergleichen. Bei 15.000 Dreiecken sind das allein 112 Millionen Vergleiche - und dies geht extrem hoch bei Szenen mit größerer Komplexität (200.000 Dreiecke = 20 Milliarden Vergleiche).

So etwas ist nur mit entsprechend intelligenten Algorithmen zu lösen, welche diese Arbeit in vernünftiger Zeit bewältigen können - und möglicherweise entfällt ein großer Teil der im NV20 "freien" 10 bis 20 Mill. Transistoren auf eine diese Berechnungen ausführende Einheit. Wie ein im Grafikchip zusätzlich integrierter Pentium III - dieser hat ca. 9 Mill. Transistoren ohne L2-Cache :-)) Die Kunst ist also weniger, diesen Test überhaupt durchzuführen, sondern den nötigen Berechnungsaufwand so weit zu optimieren, daß der vorgezogenen Z-Buffer-Test weder zum Bremsklotz wird noch die Berechnungen so ungenau werden, daß die 3dfx´schen Bildfehler auftreten.

Natürlich ist ein dreiecksbasierender Z-Buffer-Vortest bei weitem ungenauer, denn für jedes Dreieck wird dann nur der Z-Buffer-Wert (Tiefenwert) des am weitesten vorn gelagersten Pixels benutzt. Im ungünstigsten Fall ist dieses Pixel das einzige des Dreiecks, welches überhaupt sichtbar ist - und die restlichen Pixel des Dreiecks werden dann umsonst mit weiter verarbeitet. Eine Effizenz wie die des KYRO ist über einen dreiecksbasierenden Z-Buffer-Vortest mit Sicherheit nicht zu erreichen, aber man kann sich - sagen wir einmal - die Hälfte der zuviel gerenderten, weil sowieso überdeckten Pixel (Overdraw) sparen.

Hilfe zu exakten Zahlen beim Thema "Overdraw in aktuellen Spielen" bietet diese News von 3D Concept: Demnach haben momentane Spiele einen Overdraw abzüglich des Transparenzeffekts-Overdraw (welcher ja auf jeden Fall mitgerendert werden muß) von zwischen 25 und 40 Prozent - dreiecksbasierend. Das passt ungefähr auf die genannten 25 Prozent HSR-Vorteil des NV20 in Q3A. Hier wäre auch die von nVidia gern angesprochene 7fache Leistungssteigerung des NV20 bei sehr komplexen Szenen zu finden (siehe dazu diese News des ZD Nets): In diesen sehr komplexen Szenen werden automatisch wesentlich mehr Dreieecke verdeckt sein als z.B. momentan in Q3A. Und damit kann die Hardware-HSR-Einheit des NV20 ihre Stärken voll ausspielen, in dem sie diese verdeckten Dreiecke erkennt und vom weiteren Rendering-Prozeß ausschließt. Womit der Chip wieder mehr Zeit hat, an den letztendlich wirklich sichtbaren Teilen des entstehenden Bildes zu arbeiten ...

Die Frage, die uns natürlich am meisten dabei beschäft, ist natürlich: Wie schaut es mit den aktuellen nVidia-Produkten und HSR aus? Eine scheinbar eindeutig Aussage kommt dazu von nVidia´s Presseabteilung, in Gestalt einer Mail von nVidia´s Diane Vanesse an den Planet GeForce:

Ziemlich klare Worte. Ein was finde ich dabei allerdings höchst irrtierend: Die Lady redet von "enabled" - "einschalten" kann man aber nur Features, welche vorhanden sind, ob nun im Treiber oder in der Hardware selber. Das würde doch noch die Möglichkeit offen halten, daß die bisherigen nVidia-Chips HSR durchaus könnten, wenn man dies wollte. Oder bezieht sich das nur auf eine Software-Lösung, welche auf einer T&L-Karte wie vorbeschrieben eine sehr ungünstige Lösung darstellen sollte? D.h. eine GeForce 1/2 würde nach der Geometrieberechnung im Grafikchip die CPU das Hidden Surface Removal / Occlusion Detection errechnen lassen.

Über die Registry ist HSR in den 7.27er Detonatoren wohl auch für die GeForce 1/2 erzwingbar, möglich, daß dies aber mangels echter Hardware-Unterstützung ähnlich desolate Ergebnisse hervorbringt wie 3dfx´ momentane Alpha-HSR-Lösung. Der Berechnungsaufwand bei einer Software-Lösung muß wahrscheinlich so weit nach unten gedrückt werden, um die Aufgabe überhaupt in annehmbarer Zeit zu lösen, daß diese Bildfehler wohl unumgänglich scheinen. Eine höhere Genauigkeit der Berechnung löst das Problem der Bildfehler, bürdet der CPU aber dann so viel Last auf, daß das Feature zum Bremsklotz würde - in einer Software-Lösung wohlgemerkt. Dies ist sehr wahrscheinlich unabhängig davon, ob es auf 3dfx´ Voodoo4/5 oder nVidia´s GeForce 1/2 angewandt würde.

Eine schwierige Thematik ist es allemal. Abschließend: Es ist davon auszugehen, daß der NV20 HSR (besser: Occlusion Detection) in Hardware unterstützt und das dies wirklich die 25 Prozent Vorteil bringt, wie angedeutet. Es ist ebenfalls davon auszugehen, daß nVidia eine Lösung ohne Bildfehler anbieten wird, etwas anderes könnte man sich sowieso nicht leisten. Der 7er Detonator wird eine Funktion haben, daß HSR generell einzuschalten - ob sich allerdings GeForce 1/2 davon wirklich ansprechen lassen, steht noch in den Sternen. Die Ausrichtung von nVidia auf eine Hardware-HSR-Einheit im NV20 sollte es eigentlich der GeForce 1/2 unmöglich machen, die entsprechenden Treiber-Funktionen fehlerfrei zu nutzen. Darüber hinaus wäre es auch Marketing-technisch für nVidia nicht besonders klug, mehr oder weniger kurz vor dem Start eines neuen Chips der "alten" Chip-Generation noch einmal einen treiber-seitigen Leistungsschub zu verpassen - selbst wenn dies technisch machbar wäre.

Thx @ Ulukay für die Informationen. Thx @ RAM für einige Tips, welche in die richtige Richtung geführt haben.

Update vom 19. Dezember

Noch neuere Informationen zu diesem Thema sind nun auf nV Italia zu lesen, welche den 7.27er schon in den Händen haben: Danach ist in den 7.27er Hardware-HSR enthalten! Es funktioniert zwar momentan nur unter OpenGL, soll in späteren Treiber-Versionen aber auch für Direct3D verfügbar sein. nV Italia konnte - mit vorhandener Hardware, d.h. einer GeForce2 - 30 Prozent Zugewinn in Q3A erreichen. Tja, wie zum Henker schafft nVidia der GeForce2 ein Hardware-HSR abzugewinnen? Die Aussagen dazu sind momentan noch etwas diffus: Es werden zum einen kombinierte Register benutzt, welche das HSR ausführen (was auch immer das genau bedeuten mag) und zum anderen ist HSR nur möglich, wenn gleichzeitig NSR aufgegeben würde, beides zusammen geht nicht. Letzeres ist noch merkwürdiger als ersteres, unter "NSR" versteht man im gewöhnlichen die komplette Renderingarchitektur des GeForce2. Augrund der Unterschiede GeForce1 (kein NSR) zu GeForce2 (NSR) könnte man darauf deuten, daß dann die zusätzlichen NSR-Effekte Per-Pixel Bump Mapping, Per-Pixel Diffuse Lighting und Per-Pixel Specular Lighting in einem Durchgang nicht mehr ausführbar sind. Dies würde für momentane Spiele noch keinen Beinbruch bedeuten, da einfach noch nicht genutzt - könnte sich aber zumindestens bei der GeForce2 als Bremsklotz bei zukünftigen Spielen entwickeln. Andererseits müsste dies auch definitiv bedeuten, daß HSR nicht auf der GeForce1 funktioniert, da diese kein NSR-Renderer lt. nVidischer Definition ist. Ok, wir lassen uns überraschen ... im Januar soll es dann ja nun endlich so weit sein mit den 7.27er Detonatoren.

Home               Artikel-Index