3dfx Voodoo5 6000 Review

21. Januar 2007 / von Raff, Mr. Lolman & robbitop / Seite 4 von 26

   Der 22-Bit-Postfilter

Um heute noch den Sinn des Postfilterns nachvollziehen zu können, muss man wissen, dass selbst im Jahr 2000 32-Bit-Rendering alles andere als selbstverständlich war. Zwar konnten die damals aktuellen Grafikkarten alle schon 32-Bit-Rendering, jedoch meist nur mit einem deutlichen Leistungsverlust, welcher in der Regel in keinem vernünftigen Verhältnis zur optischen Verbesserung stand. Natürlich wurde 32-Bit-Rendering nicht nur von diversen Herstellern gepusht und von wohl allen Entwicklern gewünscht, sondern es war auch klar, dass die steigenden Grafikanforderungen das alteingesessene 16-Bit-Rendering über kurz oder lang an seine Grenzen bringen würden.

John Carmack propagierte dies bei der Entwicklung von Quake III Arena schon anno 1998. Und tatsächlich: Q3A war eines der ersten Spiele, welches unter 32 Bit nennenswert besser aussah als unter 16 Bit. Umso schlimmer war es, dass sich 3dfx Mitte 1999 noch erlaubte, mit der Voodoo3 eine Grafikkarte auf den Markt zu bringen, welche auf 16-Bit-Rendering limitiert war. Nun hatten die Voodoo-Chips aber schon seit jeher einen Postfiltermechanismus, welcher die bei 16 Bit auftretenden Dithering-Artefakte ziemlich effektiv eliminieren konnte.

Bis inklusive der Voodoo2 war dies ein 4x1 linearer Filter, welcher bis zu bestimmten Grenzwerten einfach pro Pixel einen Mittelwert aus vier nebeneinander liegenden Pixeln bildete. Damit hatte man die lästigen Dithering-Artefakte zwar beseitigt, dafür kam es aber in gewissen Situationen zu einer deutlich sichtbaren Linienbildung, die jedoch die Bildqualität nicht ganz so irritierte wie das bei 16 Bit durch Rundungsfehler verursachte Dithering. Mit der Banshee hatte 3dfx den Cache im RAMDAC vergrößert und konnte so eine zweite Bildzeile auch in den Filter miteinbeziehen.

Das Ergebnis ist der 2x2-Box-Filter, der üblicherweise auch gemeint ist, wenn man von 3dfx' "22-Bit"-Bildqualität spricht. 3dfx selbst sprach damals von ca. 4 Millionen Farben, die so ein postgefiltertes Bild maximal haben kann, was eben einer Genauigkeit von ~22 Bit entspricht. Natürlich war der 3dfx-Postfilter keine eierlegende Wollmilchsau, sondern konnte im Rahmen einer Interpolation von vier Pixeln nur schon bestehende Artefakte wegglätten, sie jedoch nicht in der Entstehung verhindern, was sich spätestens bei massivem Alphablending und den dadurch entstehenden hohen Rundungsfehlern in sichtbarem Dithering äußert. In so einem Fall wurde nämlich der Grenzwert, bis zu dem der Postfilter arbeitet, überschritten, weswegen die Dithering-Artefakte unbehandelt blieben.

Ein anderer Schönheitsfehler ist, dass der Filter prinzipbedingt natürlich nicht unterscheiden konnte, ob das zu glättende Dithermuster durch 16-Bit-Rendering verursacht wurde oder es eine gewünschte Struktur einer Textur war. Dementsprechend gibt es auch Fälle, wo der Texturinhalt auch vom Boxfilter negativ beeinflusst werden kann. Beim Mipmap-Dithering ist dieser Effekt zwar recht praktisch, jedoch war das Dithermuster oft so stark, dass der Grenzwert für das Postfiltering überschritten und deswegen auch nicht geglättet wurde. In der Praxis verrichtete der Postfilter seine Arbeit jedoch so gut, dass 3dfx-User lange Zeit die propagierten Probleme mit 16-Bit-Rendering nicht nachvollziehen konnten, während andere Karten schon recht deutlich "bröselige" Bilder produzierten.

Mit der Voodoo5 bekam der Postfilter, trotz der Einführung von nativem 32-Bit-Rendering, nochmal einen besonderen Stellenwert. Denn meistens war man als Voodoo5-Nutzer darauf bedacht, eine Einstellung zu verwenden, unter welcher man die konkurrenzlosen AA-Modi auskosten konnte. So kam es, dass man für eine hohe Performance in möglichst hohen Auflösungen auch auf 32 Bit verzichtete, was in fast allen damaligen Spielen nur mit eher minimalen optischen Einbußen verbunden war.

Der Leistungsverlust bei Aktivierung des Postfilters bewegt sich nämlich lediglich im messbaren Bereich, ist in der Praxis in der Regel aber nicht festzustellen. Nun hat ja 3dfx-Supersampling bekanntermaßen den Effekt einer Überabtastung der Bildschirmpixel, was das 16-Bit-Dithering schon einmal deutlich reduziert, bevor der Postfilter im RAMDAC appliziert wird. Dies war sogar so effektiv, dass 3dfx beim 4xAA den Postfilter komplett deaktivierte und dennoch ein völlig artefaktfreies 22-Bit-Bild auf den Bildschirm zaubern konnte.

   Z-Buffer-Genauigkeit

Einen Nachteil des 16-Bit-Renderings konnte man allerdings weder mit dem Postfilter noch mit Supersampling ausgleichen: Präzisionsprobleme beim Z-Buffer. Mit immer höheren Sichtweiten und dem wachsenden Detailreichtum wurden auch die Anforderungen an die Genauigkeit des Z-Buffers höher. Während Glide aufgrund von einer dem W-Buffer ähnlichen, nichtlinearen Quantisierung von Tiefeninformationen von Präzisionsproblemen größtenteils verschont blieb, hatte man bei neueren Spielen mit einer Z-Buffer-Genauigkeit von 16 Bit mit dem "Z-Fighting" getauften Polygonflackern zu kämpfen. Aber auch dafür gibt es eine Lösung: So bietet beispielsweise das Spiel Mafia W-Buffering an, welches aufgrund einer veränderten Interpolation eine gleichmäßigere Genauigkeit erlaubt, die das Z-Fighting je nach Anwendung vollkommen eliminierte.

An dieser Stelle muss man auch den von Metabyte entwickelten OpenGL-Glide-Wrapper "WickedGL" erwähnen, der auch bei unseren Benchmarks zum Einsatz kam. Da Glide ja im Normalfall ausreichende 16-Bit-Präzision erlaubte, bot dieser neben dem großen Vorteil einer forcierbaren Texturkompression und einer schlanken schnellen API (der Wrapper ist 340 kiB und der letzte offizielle Glide3x-Treiber nur ~320 kiB groß) somit auch für OpenGL-Spiele völlig ausreichende 16-Bit-Präzision, womit häufig auch der letzte Vorteil für 32 Bit fiel.

   Bildqualität: Die Folgen

Insgesamt kann man festhalten, dass es 3dfx sich selbst nicht allzu einfach gemacht hat. Lange Zeit musste man einfach blind 3dfx' viel zu brav gestreuten Marketingaussagen trauen oder sich selbst ein Bild von der Bildqualität machen, weil es einfach keine Möglichkeit gab, das Postfiltering auf Screenshots zu bannen. So war es leider erst nach einer sehr späten Anpassung der Software HyperSnapDX ambitionierten Hardware-Seiten wie 3DConcept vorbehalten, etwas Klarheit in das Thema zu bringen. Dies konnte jedoch auch nicht mehr die ganzen falschen Screenshots rückgängig machen, welche seinerzeit mit allen Voodookarten bis inklusive der Voodoo3 schon erschienen waren. Außerdem wurde die Software nie an die Voodoo5 angepasst, weswegen mit aktiviertem 2x Anti-Aliasing Screenshots produziert werden, die sichtbares Colorbanding aufweisen, das tatsächlich so nicht am Bildschirm zu sehen ist.

Überdies existiert ein weiteres Problem, welches allerdings exklusiv nur auf der Voodoo5 6000 existiert: Es ist fast unmöglich, auch nur irgendeinen Anti-Aliasing Modus unter Direct3D korrekt auf Screenshots abzubilden. Nur in Glide- und OpenGL-Spielen (egal ob nativ oder per WickedGL gewrappt) ist dies möglich. Leider hat dieser Modus auch noch das Problem der partiellen Custom-Mipmap-LOD Applizierung beim brilinearen Filtering mit Supersampling Anti-Aliasing, weswegen es schlicht und einfach unmöglich ist, die tatsächliche Darstellungsqualität einer Voodoo5 6000 mit 8x SGSSAA und LOD -2 auf Screenshots zu bannen.

Deswegen haben in dem Artikel einige 8x SGSSAA Screenshots ein LOD von -1, was ungefähr der Schärfe von 2xAF entspricht. Tatsächlich kann man bei diesem hohen Anti-Aliasing Modus zumindest in den getesteten Spielen das LOD bedenkenlos auf -2 stellen, was mit dem zuvor erwähnten simplen Trick der LOD-Verschiebung am zweiten Chip einer ungefähren Schärfe von ~5xAF entspricht. Damit bietet die Voodoo5 6000 selbst heutzutage eine Bildqualität, die das ein oder andere Auge noch verzücken kann - bei einem Rechenaufwand, der meist deutlich auf die Endperformance schlägt. Allerdings sollte nicht unerwähnt bleiben, dass selbst eine Radeon X1950 XTX mit 6x AAA + ASBT in Extremfällen (Alphatexturen en masse) auf ein Zehntel der Ursprungsleistung einbrechen kann. Solange die Performance allerdings im spielbaren Bereich bleibt, ist das verschmerzbar.

nVidia hingegen bietet mit dem G80-Chip keine dermaßen leistungsfressenden AA-Modi mehr an. Während der auf G70-Karten noch inoffiziell verfügbare 16x-OGSSAA-Modus für das eigentliche Rendering nur ein Sechzehntel der urspünglichen Füllrate übrig ließ und dementsprechend viel Leistung kostete, ist auf dem G80 momentan der 16xQAA-Multisamplingmodus mit TSSAA das höchste der AA-Gefühle. Dieser ist hinsichtlich der für die Bildverbesserung benötigten Leistung zwar wesentlich effizienter, lässt aber gewisse Bildhinhalte unbearbeitet.

So verbessern die AA-Samples neben Polygonkanten nur Alphatests, während Texturen und Pixel-Shader trotzdem fröhlich weiterflimmern können. Deswegen muss man momentan dem G70 eine insgesamt höhere maximal mögliche Bildqualität attestieren, die er jedoch nur bei mittlerweile oft praxisfernen Frameraten erreicht - oder in alten Spielen. Das Pferd von der anderen Seite aufgezäumt bedeutet das, dass eine Szene ohne Mipmapping (sei es ein Designfehler oder Absicht wie in so mancher Konsolenportierung) schon ausreichen würde, aktuelle Topgrafikkarten schlechter aussehen zu lassen als sechs Jahre alte 3dfx-Hardware ;).

Der T-Buffer war somit der Dreh- und Angelpunkt in der ganzen Diskussion um die Bildqualität. Leider erschöpfte sich dessen praktische Nutzung im Anti-Aliasing. Bei einer konsequenten Nutzung der Möglichkeiten des T-Buffers wäre der Preis für die gewonnene Bildqualität insgesamt wieder ziemlich gering geworden, da Softshadows, Softreflections, Motion Blur und Depth of Field bzw. Anti-Aliasing in einem Zyklus berechnet werden konnten (Anti-Aliasing und Depth of Field sind Fullscreen-Effekte und brauchen somit jeweils einen eigenen Framebuffer) und deswegen keine zusätzliche Rechenlast erzeugten (bis auf die komplexere Verschiebung der Vertexkoordinaten). Allerdings hatte man damals keine API-Extension zur Verfügung, welche es dem Entwickler ermöglicht hätte, auf diese Features direkt zurückzugreifen - die Transformationen mussten manuell erfolgen. Demnach hätte jemand eine modulare T-Buffer-Engine programmieren müssen, damit diese Features ihren Einsatz in kommerzielle Spiele gefunden hätten.