Der VSA-100 Chip

Die letzte Generation aus dem Hause 3dfx basiert noch immer auf dem originalen Voodoo-Graphics-Design aus dem Jahre 1996. Dies ist der Tatsache geschuldet, dass der eigentliche Voodoo-Nachfolger namens "Rampage" es bis dahin trotz mehrerer Respins nicht auf den Markt schaffte. Kurz gesagt waren die ungenügenden Ressourcen im Bereich Research & Development – wie für so ziemlich alles Negative bei 3dfx – dafür verantwortlich.

Moderne Features wie Environment- und Dot3-Product Bumpmapping, sowie hardwarebeschleunigte Transformation fanden ihren Weg leider nicht in den VSA-100. Das war in der Praxis für diese Generation jedoch unerheblich, da es zu der Zeit so gut wie keine Spiele gab, welche diese Features umsetzten. 3dfx ging mit dem VSA-100 einen anderen Weg und implementierte einige Ideen aus dem Rampage, welche in jedem Spiel nutzbar waren und die Bildqualität deutlich steigerten. Die Rede ist vom berühmten "T-Buffer": Gary Tarolli, Mitbegründer und Chefentwickler bei 3dfx, spendierte diesem Feature das "T" aus seinem Nachnamen.

Dieser ermöglichte:
• skalierbares SG-FSAA (sparse grid Full Scene Supersampling Anti-Aliasing – dazu im BQ-Teil später mehr)
• Depth of Field (Tiefenunschärfe, um den Realismusgrad von Spielen zu erhöhen)
• Motion Blur (Ein temporales Anti-Aliasing, welches die eigentlich erzeugte Frameraten teilt und die Ergebnisse mehrerer Bilder in einem kombiniert. Die Bildinformation in der zeitlichen Dimension steigt also pro Bild. Nicht zu verwechseln mit Motion Trail, welches nur zwischen aufeinander folgenden Frames blurrt.)
• Soft Shadows (weiche Abstufungen bei Schatten)
• Soft Reflections (weiche Abstufungen bei Reflektionen)

Das Transistorbudget wurde statt für Checklistfeatures sichtbar in Geschwindigkeit und Skalierbarkeit des VSA-100 investiert. Die Abkürzung "VSA" steht übrigens für Voodoo Scalable Architecture und ist Programm: Über die Skalierung der Chip-Anzahl pro Grafikkarte können alle Segmente des Grafikkartenmarkts auf einmal abdeckt werden. Das spart enorm R&D-Ressourcen, da auch nur eine GPU entwickelt und gefertigt werden muss.

Möglich wurde dies durch das Scanline-Interleave-Verfahren (SLI, nicht zu verwechseln mit nVidias Kürzel). Bei diesem wird das zu rendernde Bild in Zeilen aufgeteilt und jeder GPU ihr Anteil zum Rendern übertragen. Je mehr GPUs im SLI-Verbund zusammengesetzt werden, desto weniger Arbeit entsteht für den einzelnen VSA-100 Chip. Am Ende setzt der RAMDAC die fertig gerenderten "Zeilenkämme" der GPUs zusammen. Der Vorteil gegenüber dem heute üblichen AFR/SFR-Verfahren ist, dass weder CPU-lastiges Loadbalancing noch Vorberechnung mehrerer Bilder notwendig ist, denn alle GPUs arbeiten am selben Bild.

Im Gegensatz zu AFR (Alternate Frame Rendering) skaliert sogar der Videospeicher partiell mit. Zwar müssen Texturen redundant gehalten werden, da die GPUs keinen Zugriff auf den Texturspeicher der jeweils anderen GPUs haben (dies wäre auch nur extrem schwierig zu realisieren), allerdings fällt der benötigte Framebuffer pro GPU natürlich geringer aus, da jede ein weniger großes Bild rendern muss.

Die Skalierung der Bandbreite fällt ebenfalls exzellent aus: Jeder VSA-100 verfügt über sein eigenes Speicherinterface. Bei der Voodoo5 5500 wären dies also zwei unabhängige 128 Bit SDR-SDRAM-Interfaces. Dies ist als deutlich effektiver anzusehen als ein einzelnes 128 Bit breites DDR-SDRAM-Interface, denn auf diese Art sinkt der Bandbreitenverschnitt und es ergeben sich weniger durch Speicherzugriffe bedingte Pipelinestalls. Genau aus diesem Grund unterteilten die Grafikchip-Entwickler ATI und nVidia später auch ihre Speicherinterfaces in mehrere kleinere.

All diese Vorteile machen SLI zu einem Verfahren, welches eine unerreichte Effizienz bei der Skalierung bietet. Es war möglich und sinnvoll, bis zu 32 dieser GPUs miteinander zu koppeln, dies blieb jedoch den professionellen Militärsimulatoren der 3dfx-Tochter Quantum3D vorbehalten. Im Consumer-Markt beschränkte man sich, die Voodoo5 6000 mitgerechnet, auf einen Ausbau von vier GPUs pro Grafikboard.

Der Grund für das Aussterben dieses Verfahrens nach dem Ableben von 3dfx ist sehr einfach: Ein großer Nachteil entsteht bei der hardwarebeschleunigten Transformation. Alle GPUs in einem SLI-Setup müssten dieselbe Geometrie berechnen. Somit würde eine Skalierung der Geometrieleistung ausbleiben. Dies störte den TnL-freien VSA-100 Chip nun allerdings wenig (und vermutlich deshalb sollte der Rampage eine externe Geometrieeinheit bekommen). Weiterhin skaliert die Texturbandbreite in einem SLI-Setup nicht linear mit, da nicht zwischen benötigten und nicht benötigten Texturteilen unterschieden werden kann, lediglich ob ganze Texturen vorrätig sein müssen oder nicht. Der VSA-100 hatte allerdings offenbar genug Bandbreite pro Texel, damit dieser Nachteil nicht weiter auffiel.

Um den VSA-100 auf die Standards aus dem Jahre 2000 zu hieven, spendierte man diesem einen 32 Bit Framebuffer-Support und erweiterte die maximale Texturgröße von den altertümlichen 256x256 auf 2048x2048 Pixel – richtige HiRes-Texturen wurden nun also auch auf einer Voodoo möglich. Um die Texturbandbreite dabei jedoch nicht gleich zu überlasten und das Feature damit sinnvoll zu gestalten, implementierte man, wie auch die Konkurrenz, ein Texturkompressionsverfahren.

Die Voodoo3 unterstützte zwar bereits sogenannte NCC (narrow channel compression), jedoch wurde dieses proprietäre Verfahren nie richtig von Spielen unterstützt. Im VSA-100 fand nun auch die breit unterstützte S3 Texture Compression (S3TC) Verwendung. Da jedoch für die Nutzung von S3TC in OpenGL-Spielen Lizenzgebühren an S3 Graphics anfielen, entwickelte 3dfx ein ähnliches Verfahren namens FXT. Metabytes bekannter OpenGL Glide-Wrapper "WickedGL [9]" konvertierte auf Wunsch des Users jegliche Texturen von OpenGL Spielen in das FXT-Format.

Als erster Voodoo-Chip besitzt der VSA-100 zwei unabhängige Pixelpipelines, womit er pro Takt an zwei verschiedenen Pixeln arbeiten kann. Das ist oftmals effizienter als die Multi-Texturing-Pipeline der Voodoo3. Das Design wurde also breiter und dafür etwas kürzer. Die Konkurrenz arbeitete bereits mit Quadpipelines, um Polygone zu texturieren. Das klingt fortschrittlich, ist es in diesem Falle jedoch nicht:

Eine Quadpipeline ist grob gesehen eine einzige Pipeline, die vierfach ausgelegt ist. Es wird pro Takt ein Pixelquad, also eine Anordnung von 2x2 Pixeln (in der Abbildung blau gekennzeichnet), berechnet. So sparte man zwar viele Transistoren für die Steuerlogik, erkaufte aber die Limitierung, dass alle Pixelpipelines die gleiche Operation durchführen müssen. Das führt, besonders bei kleinen Dreiecken, zu einem Verschnitt (in der Abbildung als weißes Pixel im blauen Rahmen erkennbar). Diesem Verschnitt unterliegt der VSA-100, wie alle Prä-GeForce-Renderer, nicht.

Obwohl die Voodoo5 6000 die Zahl "5" trägt, ist sie dennoch ein Angehöriger der vierten Generation der Voodoo-Serie. Vermutlich wollte 3dfx die Mehrchipvarianten namentlich von der Einzelvariante (Voodoo4 4500) abgrenzen, um deren Leistungsfähigkeit für den Käufer zu unterstreichen.

Mit dem Slogan "Fillrate is King" bewarb 3dfx die VSA-100-Reihe. Aufgrund der Verspätung schaffte man es aber leider nicht, diese Serie gegen den eigentlich vorgesehenen Gegner, die GeForce 256 von nVidia, antreten zu lassen. Diese wäre aus einer derartigen Konfrontation vermutlich nicht einmal mit einem blauen Auge davongekommen.

Aber im Leben kommt es oftmals anders als man denkt: Nichts desto trotz erfüllen unsere Voodoo5 6000 Karten diesen Leitspruch, denn eine Füllrate von 1,46 Gigapixeln pro Sekunde und eine Bandbreite von 11,7 Gigabyte/s, verbunden mit den Effizienzvorteilen von SLI, sprechen eine klare Sprache. Keine SingleChip HighEnd Grafikkarte aus dieser Zeit wäre im Stande gewesen, hier mit der Voodoo 5 6000 mitzuhalten. Doch dazu mehr im Benchmarkteil.

[8]

Texturfilterung

Was kann man nun bezüglich der Bildqualität von einer Grafikkarte erwarten, deren Featureset schon zur Vorstellung als veraltet angesehen wurde? Tatsächlich ist die Bildqualität mit anderen Grafikkarten derselben Generation nur bedingt vergleichbar – dies ist jedoch nicht unbedingt im negativen Sinn gemeint.

Die Voodoo5 bietet mit den offiziellen Treibern standardmäßig keinen trilinearen Filter, auch wenn die Grafikkarte natürlich dazu in der Lage wäre. Allerdings kann dies ein VSA-100 nur bei Singletexturing in einem Rechenzyklus erledigen. Trotzdem wurde dem Chip die Möglichkeit zur Verfügung gestellt, die scharfen Detailgrad-Übergänge in texturierten Flächen zu mildern. So bieten die Treiber ein Feature namens "Mipmap-Dithering" an, welches die Mipmaps zu 50% mit der nächstkleineren Mipmapstufe überblendet.

Der offensichtliche Nachteil an diesem Modus ist eben das Dithering, welches die überblendeten Teile im Bild mit einer mehr oder minder stark sichtbaren Granularität versieht, die sich selbst nicht durch hohe Supersampling-Modi vollständig ausgleichen lässt. Auf der Haben-Seite verbucht dieser Modus einen niedrigen bis (je nach Anwendung, beispielsweise Quake III Arena) praktisch inexistenten Leistungsverlust bei gleichzeitiger Steigerung der Bildqualität.

Der weitaus interessantere Modus ist eine Art brilinearer Filter, der entsteht, wenn zwei VSA-100 im Supersampling-Modus rechnen und ein Chip das Mipmap-LOD-Bias um -0.5 versetzt. Dies funktioniert nur deswegen, da im Gegensatz zum herkömmlichen Supersampling Anti-Aliasing bei Voodoo5-Karten mehrere Bilder im T-Buffer gleichgewichtet zusammengemischt werden. Als Ergebnis ensteht ein Bild mit 1-Bit-LOD-Fraction, was von der Definition her tatsächlich als trilinearer Filter durchgeht. Wobei man jedoch erwähnen muss, dass 1-Bit-LOD-Fraction auf texturierten Flächen zwar eine deutliche Verbesserung zu einem rein bilinearen Filtering bringt, aber für eine gleichmäßige lineare MIP-Map-Interpolation noch nicht ausreichend ist.

Diese partielle LOD-Verschiebung ist jedoch nur mit SLI Anti-Aliasing möglich. Das heißt, dass eine Voodoo4 4500 nicht in der Lage ist, nach dem "Unum necessarium" Prinzip trilinear zu filtern, da jene Grafikkarte nur einen VSA-100-Chip hat und somit auch nur ein LOD-Bias-Register existiert. Andererseits bedeutet das wiederum, dass eine Voodoo5 6000 statt zwei Bildern mit unterschiedlichem LOD-Bias sogar vier solcher Bilder zusammenrechnen kann. Damit hat man anstatt eines zusätzlichen Mipmap-Übergangs gleich drei solcher Abstufungen mehr, also eine LOD-Fraction von 2 Bit.

Einer konsequenten Nutzung dieses Features stehen jedoch die Treiber im Weg: So hat man bei aktivem Anti-Aliasing diese performancemäßig sehr günstige, aber optisch minimalistische trilineare Filterung zwar mit jedem Originaltreiber, korrekt funktioniert sie aber nur bei einem LOD-Bias von 0.0 oder -1, da Änderungen am LOD-Bias unglücklicherweise nur auf den ersten Grafikchip appliziert werden und der zweite Grafikchip fix mit einem LOD von -0.5 rechnet. Glücklicherweise existiert jedoch ein modifizierter Glide-Treiber, welcher das LOD-Bias auch auf dem zweiten Grafikchip korrekt mit verschiebt.

Manche Leser werden sich schon die Frage gestellt haben, warum man das LOD-Bias überhaupt verschieben sollte, da ja 0.0 dem Optimum entspricht. Die Antwort ist simpel: Während die Konkurrenz ihr Supersampling Anti-Aliasing einfach durch eine interne Erhöhung der Auflösung (Oversampling) mit abschließendem Downsampling realisierte und dabei automatisch auch eine höhere Texturqualität erreichte, entsteht durch die 3dfx-Technik keine automatische Schärfung der Texturen, sondern lediglich eine Überabtastung der Texel. Diese lässt sich nun wunderbar mit einer Verschiebung des Mipmap-LOD-Bias ausgleichen. Theoretisch liegt die maximal mögliche Verschiebung bei -1 pro vier SSAA-Samples.

Praktisch entscheidet dies jedoch der persönliche Geschmack, denn der ideale Kompromiss zwischen maximal möglicher Schärfe und möglichst großer Texturruhe ist bei jedem Spiel woanders zu suchen. In der Praxis hat sich eine LOD-Verschiebung um -0.5 für 2x AA und -1.5 für 4x AA bewährt. Die erste Mipmap-Überblendung entsteht bei 4x Anti-Aliasing somit im Bereich von -2 bis -2.5, was ungefähr einer Schärfe von 4xAF entspricht (natürlich ohne dessen Texturruhe zu erreichen). Durch diese vergleichsweise große Verschiebung von -1.5 wird zwar das Nyquist-/Shannon-Abtasttheorem verletzt, allerdings bezieht sich das ohnehin auf den theoretischen Worstcase in Form von höchstfrequenten Texturen (beispielsweise pixelgroße Schwarz/Weiß-Schachbrettmuster).

So liegt mit vier Supersamples die tatsächlich maximal mögliche Schärfe, bei der man in keinem Fall eine Unterfilterung riskieren muss, nach konservativer Rechenmethode bei 2x AF [ld(n)=x]. Dies gilt jedoch nur bei einem "Ordered-Grid" Anti-Aliasing. Eine weniger konservative Rechenmethode würde neben den tatsächlichen Samplepostionen noch die, im Vergleich zur Basemap zwangsläufig verringerte, Amplitude der Mipmaps mit einbeziehen, was zumindest in dem Bereich, wo schon aus den Mipmaps gesampelt wird, automatisch eine höhere LOD-Verschiebung zulässt. Damit ließe sich zwar auch kein vierfaches "Lehrbuch-AF" errechnen, allerdings war dies in Anbetracht der durchschnittlichen Texturschärfe in den Spielen zu 3dfx-Zeiten oft auch gar nicht notwendig.

Das Streben nach scharfen Texturen fing auch nicht erst mit dem Aufkommen des anisotropen Filters an, im Gegenteil: Schon im Spiel Unreal wurden diverse Kniffe eingesetzt, um damalige Hardwarelimits etwas zu umgehen. Neben dem mittlerweile kaum noch notwendigen Detailtexturing (zusätzliche Texturüberlagerung zur Verbesserung der Nahdarstellung von Oberflächen) und dem heutzutage noch eher einsetzbaren Macrotexturing (zusätzliche Texturüberlagerung zur Verbesserung der Distanzdarstellung von Oberflächen) appliziert die Unreal Engine 1.x in Glide automatisch ein Mipmap-LOD-Bias von -1.5.

Dies bedeutet, dass mit bilinearer Filterung ohne Supersampling Anti-Aliasing bis zu 16 Texel der Basetextur sich ein einziges Bildschirmpixel teilen mussten. Ideal ist ein Verhältnis von 1:1, also kann man praktisch von 16facher Unterfilterung reden. Nach heutiger Bemessung ist das natürlich untragbar, aber 1999 wurde 3dfx für die gute Bildqualität in Unreal Tournament gelobt und ironischerweise hoben sich die 3dfx-Beschleuniger auch performancemäßig ab und gewannen trotz der durch das verschobene Mipmap-LOD-Bias bedingten höheren Rechenlast alle Benchmarks (wobei man fairerweise anmerken muss, dass die Unreal-Engine ziemlich perfekt auf Glide und damit Voodoo-Karten zugeschnitten war).

[8]

Anti-Aliasing

Was ist am Anti-Aliasing der Voodoo5 6000 nun so besonders, dass selbst sechs Jahre nach dem Ableben von 3dfx es kein Hersteller geschafft hat, dessen Qualität in allen Belangen zu überbieten?

Durch das Überlagern mehrere Bilder im "T-Buffer" getauften Multisample-Buffer kann man – im Gegensatz zum einfachen, als Oversampling bekannten "Ordered Grid Supersampling Anti-Aliasing" (OGSSAA) – die AA-Samplepositionen innerhalb eines Rasters frei bestimmen. Das Anti-Aliasing entsteht dabei durch eine leichte Verschiebung der Szenerie. Durch dieses "Sparse Grid" werden schon mit zwei Subpixeln (also 2x SGSSAA) sowohl die X- als auch die Y-Achse jeweils doppelt so fein abgetastet, während man bei rechtwinkliger Anordnung der Subpixel (OGSSAA) dafür tatsächlich 2x2 = 4 Subpixel (und gleichermaßen verdoppelten Rechenaufwand) benötigt.

Ein "sparse grid" ist sozusagen eine Sparversion von einem "ordered grid". Allerdings wird dabei sinnvoll gespart: Während sich die Kantenglättungsqualität bei den wichtigsten Winkeln nur unwesentlich verschlechtert, wird erheblich Leistung eingespart. So kann ein 2x OGSSAA prinzipbedingt nur eine Achse höher abtasten und dementsprechend entweder vertikale oder horizontale Winkel glätten. Um mit einem Ordered Grid die Kantenauflösung von 8x SGSSAA zu erreichen, müsste man schon 8x8 (= 64x) OGSSAA einsetzen, was ein guter Indikator dafür ist, dass OGSSAA im Consumermarkt eher ein Checklistenfeature war und nur eingesetzt wurde, um technische Unzulänglichkeiten auszugleichen. So erreichte nVidia die Texturqualität eines 64x OGSSAA schon mit dem 8xAF der GeForce3. Zur weiteren Vertiefung dieses Themas: In einem früheren Artikel [10] unsererseits wird neben den Grundlagen über Anti-Aliasing unter anderem auch auf die Unterschiede zwischen den verschiedenen Masken eingegangen.

3dfx steht mit seiner AA-Methode mittlerweile nicht mehr alleine da. Der R200 (Radeon 8500) sollte ursprünglich ebenfalls Supersampling Anti-Aliasing mit einem rotierten Gitter bieten, schaffte dies jedoch nur in Spielen, die keinen Nebel einsetzten. Aktuell bietet bloß S3 mit 9x SGSSAA einen Modus an, der das 3dfx'sche 8x SGSSAA optisch sogar übertreffen könnte. Jedoch ist dieser praktisch kaum einsetzbar, da im Vollbildmodus die Sampleverteilung scheinbar willkürlich ist, was in einer schlechten Bildqualität resultiert. Überredet man ein Spiel allerdings zum Laufen im Fenstermodus, offenbart sich ein Anti-Aliasing, das dem der Voodoo5 6000 als einziges mindestens ebenbürtig ist.

Natürlich bieten ATI und nVidia mittlerweile effizientere AA-Modi an, jedoch lassen sich relativ problemlos Situationen konstruieren, wo das AAA/TSAA nicht funktioniert (OpenGL) – einmal abgesehen davon, dass durch diese Verfahren sowieso nur Alphatests (Texturen mit binärem Alpha-Wert, also pro Bildpunkt entweder vollständig durchsichtig oder komplett undurchsichtig) geglättet werden. Der neue 8x-MSAA-Modus des G80 bietet zwar auf Polygonkanten eine 8x8-höhere Achsenauflösung, lässt aber andere Bildinhalte komplett unbehandelt, wo bei 3dfx' 8x AA noch acht Super-Samples zum Einsatz kommen.

Am nächsten kam dem 3dfx-8xAA nVidias mit dem NV40 eingeführter (und am G80 aktuell nicht mehr verfügbarer) 16xS-Modus mit aktiviertem TSSAA. Dieser bot auf Alphatests und Polygonkanten genauso wie 3dfx eine jeweils 8fach höhere Achsenauflösung, hatte aber im Gegensatz zu 3dfx' 8xAA nur vier Textursamples anstatt acht (wobei man natürlich mit AF nachhelfen kann). Festzuhalten bleibt auch, dass selbst der "normale" 16xS-Modus (ohne TSAA) nicht einmal 3dfx'sches 4xAA vollständig übertreffen konnte, da er durch den OGSSAA-Anteil Alphatestkanten statt 4x nur 2x so hoch auflösen konnte – bei mehr Rechenaufwand wohlgemerkt!

So blieb bis zum Erscheinen des G70 (und der damit verbundenen Einführung von TSAA, rückwirkend auch auf NV4x-Chips) Bildqualitätsfetischisten nur die Möglichkeit, auf sehr ineffizientes 16x OGSSAA zurückzugreifen, welches genau wie 3dfx' 4xAA eine EER [11] von 4x4 auf das gesamte Bild bietet. Dies jedoch kombiniert mit dem Vorteil, dass immerhin 16 Textursamples anstatt vier zum Einsatz kommen, was in Anbetracht der akzeptablen Texturfilterung unter der HighQuality-Treibereinstellung ohnehin Verschwendung gewesen wäre. Und natürlich abgesehen davon, dass bei diesem Modus etwa 94% der verfügbaren Füllrate allein für das Antialiasing benötigt wurden, was eine GeForce 6800 GT ungefähr auf das Leistungsniveau einer Voodoo4 4500 herunterdrückte (350 zu 333 MTexel/s). Interessant ist hierbei, dass eine Voodoo5 6000 (bei 166 MHz Takt) mit 4x SGSSAA ebenfalls genau der Rohleistung einer Voodoo4 4500 ohne Anti-Aliasing entspricht.

[8]

22-Bit-Postfilter & Z-Buffer

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 [12] 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.

[8]

Testsystem, Benchmark-Software, -Settings und Kontrahenten

Wer die Materie schon länger verfolgt und vielleicht selbst mit dem Erwerb einer Voodoo5 6000 liebäugelt, der weiß sicher von dem großen Problem, das gemeinhin "Mainboard" genannt wird. Beim Kauf eines solchen kann man schon bei aktuellen Grafikkarten verzweifeln, aber mit der Intention, eine Voodoo5 6000 zu betreiben, ist es ungleich komplizierter. Diese Grafikkarte ist und bleibt ein Prototyp – und das merkt man immer wieder. Das bedrohlichste Problem betrifft die Wahl des richtigen Unterbaus, denn nur ein Bruchteil aller Motherboards arbeitet mit der Voodoo5 6000 zusammen.

Wie alle offiziell erschienenen Voodoo5-Grafikkarten passt sie zum einen nur in AGP 2.0 fähige Slots, braucht also 3,3 Volt Betriebsspannung. Diese Tatsache wird zusätzlich durch ein Problem verschärft, das Kenner "Latch-Up" nennen: Steckt man eine Voodoo5 6000 in ein Mainboard, das zwar einen theoretisch kompatiblen AGP-Slot und Chipsatz aufweist, jenes aber nicht auf gängigen Kompatibilitätslisten steht, ist die Wahrscheinlichkeit groß, dass die HiNT-PCI-Bridge in Sekunden überhitzt und das Zeitliche segnet. Das ist weniger erfreulich, denn dieses unscheinbare Bauteil dient der Kommunikation der vier VSA-100-GPUs untereinander – ohne sie bleibt das Bild schwarz. Warum dieser Bug auftritt und inwieweit man dies bei einem planmäßigen Release der Karte hätte eindämmen können, bleibt ein Rätsel.

Die HiNT HB1-SE66 PCI-PCI-Bridge: Sie ist das Bindeglied zwischen den vier Grafikprozessoren und dem AGP-Slot. Sie gaukelt letzterem ein einzelnes PCI Device vor, das fortan im PCI66-(AGP1x)-Modus läuft (Bild: © PC Games Hardware).

Unter den letzten verbliebenen 3dfx-Anhängern gilt VIAs KT333-Chipsatz als Nonplusultra zum Bau der leistungsstärksten Voodoo-Rechner. Dieser Chipsatz unterstützt den Athlon XP mit Barton-Kern und FSB166, kann also einige der schnellsten Sockel-A-Prozessoren aufnehmen. Obacht: Der KT400 und alle neueren Chipsätze setzen bereits konsequent auf AGP 3.0 und können daher nicht verwendet werden! Unser Benchsystem umfasst ein MSI KT3 Ultra2 samt Mobile Athlon XP (Barton-Core) 2600+ und 2x 512 MiB PC3200 und ist damit das beste, was man einer AGP-Voodoo vorsetzen kann.

Um gleich vorweg zu klären, warum wir eine Grafikkarte des Jahres 2000 mit fast drei Jahre neueren Komponenten paaren: CPU-Skalierung ist das Stichwort. Die relativ potente Infrastruktur erlaubt uns einen Direktvergleich zwischen einer HighEnd-CPU der damaligen Zeit und dem, was man der Grafikkarte anno 2003 als letzte Aufrüstung hätte zur Seite stellen können. Die Ende 2000 schnellste verfügbare CPU war der Athlon Thunderbird mit 1,2 GHz, unser Nonplusultra wird im folgenden der auf rund 2,6 GHz übertaktete Barton sein.

Da wir keinen Thunderbird zur Verfügung hatten, simulierten wir ihn annähernd, indem der Barton die Hälfte der Tests mit nur einem Gigahertz lief. Wir wollten damit klären, welche Grafikkarte mehr von einem deutlich schnelleren Prozessor profitieren kann. Dabei hatten wir natürlich stets das bei unseren Tests aktivierte Hardware-T&L der GeForces im Hinterkopf – und ob man diesen Mangel durch die höhere Prozessorenpower ausgleichen kann.

Das Testsystem zusammengefasst:
• Mobile Athlon XP (Barton-Core) 2600+ auf 1,0 und 2,6 GHz
• MSI KT3 Ultra2 (VIA KT333)
• 2x 512 MiB PC3200/DDR400
• Windows 98 SE & Windows XP

Unser Ziel in Sachen Benchmarks stand fest: Es musste endlich ein komplettes Bild der Leistungsfähigkeit des 3dfx-Flaggschiffs her. Um das zu erreichen, war neben den verschiedenen CPU-Taktungen auch ein umfangreicher Spieleparcours von Nöten, der neben damals aktuellen Blockbustern auch aufzeigt, wie sich die de facto stehengebliebene Treiberentwicklung auf neuere Spiele auswirkt. Genau hier standen wir vor einer wichtigen Frage: Windows 98 SE oder Windows XP als Test-Betriebssystem? Wir entschieden uns aufgrund der Aktualität für Windows XP.

Man sollte beim Betrachten der folgenden Zahlen aber immer bedenken, dass die Voodoo-Treiber speziell auf Windows 98 optimiert wurden. Offizielle XP-Treiber existieren schlicht und ergreifend nicht, denn 3dfx verschied bereits ein Dreivierteljahr vor Release des Betriebssystems – wir testen also sozusagen Beta-Hardware mit Alpha-Treibern. Warum dennoch Windows XP zum Einsatz kam? Die Antwort verbirgt sich hinter vier Buchstaben: SFFT. Damit ist nicht etwa eine ähnlich lautende Zeitschrift gemeint, sondern ein 3dfx-treuer Hobbyprogrammierer aus London. Seit etwa zwei Jahren spinnt er mit seinen "SuperFurryFurryThing"-Alpha-Treibern anhand des ins Netz gelangten Treiberquellcodes das weiter, was anfangs mal ein Direct3D-Core für Windows 2000 war.

Ihm ist zu verdanken, dass aktuellere Direct3D-Spiele überhaupt starten und einige Bugs verschwanden. Windows-98-Treibern nahmen sich zwar auch einige Modder an, über mehr als kleinere Tweaks ging das jedoch nie hinaus. Dass der Treiber aber natürlich alles andere als fehlerfrei ist, zeigen die folgenden Zahlen ebenfalls. Bei besonders gravierenden Unterschieden bieten wir zur Veranschaulichung optional einige Windows-98-Werte. Kurz gefasst lässt sich die Treibersituation nach unserem Kenntnisstand folgendermaßen zusammenfassen: Windows XP ist mit dem SFFT bei neuen Spielen kompatibler, Windows 98 dafür bei der damaligen Software oft schneller.

Für OpenGL nutzten wir weiterhin den schnellen WickedGL. Dieser schon vorweg erwähnte OpenGL-zu-Gilde-Wrapper verhilft den Voodoo-Karten in OpenGL zu neuen Leistungshochs ohne sichtbar Qualität zu kosten. Die Konkurrenz im Form von Radeon und Kyro bekam die jeweils neuesten dafür freigegebenen Treiber als Partner. Etwas anders bei den GeForces, denn dort entpuppte sich der zuerst getestete ForceWare 91.47 als fiese Leistungsbremse. Um dennoch einen halbwegs neuen, aber schnellen Treiber zu nutzen, wählten wir die ForceWare 71.84. Dies ist übrigens auch der letzte Treiber, welcher GeForce2 GTS und Ultra offiziell unterstützt.

Die Treiber zusammengefasst:
• Voodoo: SFFT Alpha 41 (Direct3D) & WickedGL 3.02 (OpenGL)
• GeForce: ForceWare 71.84 WHQL
• Radeon: Catalyst 6.5 WHQL
• Kyro 2: v22.0033 Beta

Geplant war die Voodoo5 6000 als Konkurrent zu nVidias damaliger Spitzengrafikkarte GeForce2 Ultra, daher darf sie als wichtigster Counterpart zu unserem Titelgeber nicht fehlen. Wir gehen aber noch ein ganzes Stück weiter: Wie hätte sich die Voodoo5 6000 im Falle eines verspäteten Rampages im Frühjahr 2001 gegen die GeForce3 und später Radeon 8500 geschlagen? Und hätte sie auch gegen eine GeForce4 Ti4200 eine Chance? Zusätzlich gehen wir bis hinunter zur originalen GeForce 256 und Voodoo4 4500.

Die Testkarten im Detail:
• Voodoo5 6000 AGP (4x 32 MiB, 183/183 MHz)
• Voodoo5 5500 AGP (2x 32 MiB, 166/166 MHz)
• Voodoo5 5500 PCI (2x 32 MiB, 166/166 MHz)
• Voodoo4 4500 AGP (32 MiB, 166/166 MHz)
• GeForce4 Ti4200 (128 MiB, 250/222 MHz)
• GeForce4 MX440 (64 MiB, 270/202 MHz)
• GeForce3 (64 MiB, 200/230 MHz)
• GeForce3 Ti200 (64 MiB, 175/200 MHz)
• GeForce2 Ultra (64 MiB, 250/230 MHz)
• GeForce2 GTS (32 MiB, 200/166 MHz)
• GeForce2 MX (32 MiB, 175/166 MHz)
• GeForce 256 SDR (32 MiB, 120/166 MHz)
• Radeon 8500 (64 MiB, 275/275 MHz)
• Kyro 2 (64 MiB, 175/175 MHz)

Als Benchmark-Spiele kamen dabei folgende acht Titel zum Einsatz:

• Dungeon Siege 2
• Heavy Metal FAKK2
• Max Payne
• Max Payne 2
• Need for Speed: Porsche
• Serious Sam: The Second Encounter
• Ultima IX
• Unreal Tournament
• Unreal Tournament 2004

Unsere zum Test ausgewählten Benchmark-Spiele testeten wir in folgenden Einstellungen jeweils mit 1,0 und 2,6 GHz CPU-Takt:

• 1024x768x16
• 1024x768x16 + 4xAA
• 1024x768x32
• 1024x768x32 + 4xAA
• 1600x1200x16
• 1600x1200x32

Einzelfälle machten natürlich einen Strich durch diese Rechnung: Max Payne 2 läuft beispielsweise nur in 32 Bit, Unreal Tournament 2004 zu ruckelig in 1600x1200 (zudem bei den Voodoos nur in 16 Bit) und Dungeon Siege 2 bietet bei den meisten Testkarten nur maximal 1280x1024 an. Weiterhin lief bei den nVidia-Karten bis zur GeForce2 bei einigen Spielen kein 4xAA, daher benchten wir hier mit 2xAA. Jene Karten, welche auch 4xAA darstellten, testeten wir zusätzlich damit.

Achtung: Das "4xAA"-Setting umfasst bei den Voodoos 4xRGSSAA und ein LOD von -1,5, bei den GeForces bis einschließlich der GeForce2 Ultra ein 2x2 OGSSAA plus 2xAF. So erreichen wir ein ähnliches Qualitätsniveau: Die Voodoos glätten die Kanten deutlich schöner, dafür liegen die GeForces bei den Texturen leicht vorn (wie vorstehend ausgeführt). Das 2xAA-Ausweichsetting besteht aus 2xRGSSAA/LOD -0,5 bei den Voodoos und 2xOGSSAA/2xAF bei den GeForces. Um den Vorteil der MSAA-fähigen nVidia-Karten ab der GeForce3 nicht ganz unter den Tisch fallen zu lassen, rechnen diese mit 4xS Anti-Aliasing und 2xAF bzw. 2xRGMSAA/2xAF. Daher bei den Zahlen immer die Bildqualität vor Augen führen!

[8]

Benchmarks Dungeon Siege 2

• Spielversion: 2.20
• Schatten: Einfach
• Rest maximal

[8]

Benchmarks Dungeon Siege 2 (Forts.)

Unter Dungeon Siege 2 ergibt sich eine schwere Niederlage für die gesamte 3dfx-Bastion: Obgleich die Grafik dieses 2005-er Titels nicht sonderlich anspruchsvoll wirkt, haben die Voodookarten hier offensichtlich ihre Probleme. Dabei fallen mehrere Dinge auf: Erstens scheint die reine Texelleistung bzw. Bandbreite nicht primär zu limitieren. Der CPU-Takt hat enormen Einfluss auf die Frameraten, wobei Hardware T&L das Limit bei den GeForces elegant umschifft.

Im Vergleich zwischen Voodoo5 5500 AGP und PCI sowie der kleinen Schwester Voodoo4 4500 AGP offenbart weiterhin ein Phänomen, das bereits hier [13] und hier [14] aufgezeigt wurde: Der Grafikbus limitiert. Die Voodoo4 AGP schafft es in 800x600x16 schon fast auf das Niveau der eigentlich doppelt so starken Voodoo5 5500 AGP – vorbei an der Voodoo5 5500 PCI! Dass sich die Voodoo5 6000 nur mit Anti-Aliasing deutlich von der Voodoo5 5500 absetzen kann und sonst nur minimal schneller ist, ist ein weiteres Indiz hierfür.

Ernste Treiberschwächen und ein voller VRAM zeigen sich zudem spätestens in 1280x1024 bei 32 Bit, wo die Voodoos auf ein Sechstel der 16-Bit-Leistung zurückfallen. Die Voodoo5 6000 kämpft wieder am meisten mit den SLI-Problemen: Selbst die Voodoo4 rennt ihr davon und die Voodoo5 5500er Karten sind in 1280x1024x32 fast doppelt so schnell. Tests unter Windows 98 SE fallen hier leider weg, da das Spiel unter diesem Betriebssystem nicht startet.

Screenshots GeForce2
[15] 2xAA, 2xAF, 16 Bit [16]	[17] 2xAA, 2xAF, 32 Bit [18]	[19] 4xAA, 2xAF, 16 Bit [20]	[21] 4xAA, 2xAF, 32 Bit [22]
Screenshots GeForce3
[23] 2xAA, 2xAF, 16 Bit [24]	[25] 2xAA, 2xAF, 32 Bit [26]	[27] 4xS AA, 2xAF, 16 Bit [28]	[29] 4xS AA, 2xAF, 32 Bit [30]
Screenshots GeForceFX
[31] 2xAA, 2xAF, 16 Bit [32]	[33] 2xAA, 2xAF, 32 Bit [34]	[35] 4xS AA, 2xAF, 16 Bit [36]	[37] 4xS AA, 2xAF, 32 Bit [38]	[39] 8xS AA, 2xAF, 16 Bit [40]	[41] 8xS AA, 2xAF, 32 Bit [42]
Screenshots Kyro 2
[43] 2xAA, 2xAF, 16 Bit [44]	[45] 2xAA, 2xAF, 32 Bit [46]	[47] 4xAA, 2xAF, 16 Bit [48]	[49] 4xAA, 2xAF, 32 Bit [50]
Screenshots Radeon 8500
[51] 2xAA, 2xAF, 16 Bit [52]	[53] 2xAA, 2xAF, 32 Bit [54]	[55] 4xAA, 2xAF, 16 Bit [56]	[57] 4xAA, 2xAF, 32 Bit [58]
Screenshots Voodoo5
[59] 2xAA, 16 Bit [60]	[61] 2xAA, 32 Bit [62]	[63] 4xAA, 16 Bit [64]	[65] 4xAA, 32 Bit [66]

Ganz anders als man bei den Benchmarks, spielt 3dfx auch in diesem Spiel in der Bildqualität ganz oben mit. Einziges Manko: Unsere Fixierung auf LOD -0.5 bei 2xAA. Wie auch schon bei Max Payne wird wieder gedithert (oder gar trilinear gefiltert?) und unsere Schärfeberechnung aus dem Bildqualitätsteil erübrigt sich. Den Screenshots nach zu urteilen wäre ein Wert von -0.75 sicher noch völlig im grünen Rahmen, vielleicht sogar auch noch -1. Ansonsten lassen wir die Screenshots für sich selbst sprechen :).

[8]

Benchmarks Heavy Metal FAKK2

• Spielversion: 1.02
• Modelldetails: Standard
• Texturfilter: bilinear
• Rest maximal
• EAX 2 aktiviert

[8]

Benchmarks Heavy Metal FAKK2 (Forts.)

Dank Hardware T&L liegen die GeForces hier in 1024x768 stets in Führung, woran auch die maximale Übertaktung der CPU nichts ändern kann. Je weiter die Belastung in Richtung Grafikkarte wandert, desto gefährlicher wird allerdings die Voodoo5 6000. Spätestens in 1600x1200x16 herrscht bei 1 GHz CPU-Takt Gleichstand mit der GeForce2 Ultra. Mit 2,6 GHz im Rücken schnuppert sie schließlich GeForce3-Luft. Wir testeten übrigens mit den Standard-Modelldetails sowie bilinearer Filterung. Ersteres verdanken wir der Tatsache, dass Non-T&L-Karten keine höheren Details darstellen. Und um niemanden zu benachteiligen, glichen wir zudem den Filter an den maximal bilinearen Filter der Voodoos an.

Screenshots GeForce2
	[67] 2xAA, 2xAF, 16 Bit [68]	[69] 2xAA, 2xAF, 32 Bit [70]	[71] 4xAA, 2xAF, 16 Bit [72]	[73] 4xAA, 2xAF, 32 Bit [74]
Screenshots GeForce3
	[75] 2xAA, 2xAF, 16 Bit [76]	[77] 2xAA, 2xAF, 32 Bit [78]	[79] 4xS AA, 2xAF, 16 Bit [80]	[81] 4xS AA, 2xAF, 32 Bit [82]
Screenshots GeForceFX
	[83] 4xS AA, 2xAF, 16 Bit [84]	[85] 4xS AA, 2xAF, 32 Bit [86]	[87] 8xS AA, 2xAF, 16 Bit [88]	[89] 8xS AA, 2xAF, 32 Bit [90]
Screenshots Kyro 2
	[91] 4xAA, 2xAF, 16 Bit [92]	[93] 4xAA, 2xAF, 32 Bit [94]
Screenshots Radeon 8500
	[95] 4xAA, 2xAF, 16 Bit, Performance [96]	[97] 4xAA, 2xAF, 32 Bit, Performance [98]	[99] 4xAA, 2xAF, 16 Bit, Quality [100]	[101] 4xAA, 2xAF, 32 Bit, Quality [102]
Screenshots Voodoo5
	[103] 2xAA, 16 Bit [104]	[105] 2xAA, 32 Bit [104]	[106] 4xAA, 16 Bit [107]	[108] 4xAA, 32 Bit [109]
Screenshots Voodoo5 & Radeon X1900 XTX
	[110] 8xAA, 16 Bit [111]	[112] 8xAA, 16 Bit, keine Mipmaps [113]		[114] 6xAA, 16xAF, 32 Bit [115]

Bei Heavy Metal FAKK2 handelt es sich um eines der seltenen Spiele, wo sich 3dfx' 8xAA ablichten lässt. Hier schlägt aber auch das "Überblendungsproblem" zu, weswegen wir neben einen Screenshot mit LOD -1 auch einen ohne Mipmaps anbieten. Tatsächlich kann man jedoch Heavy Metal FAKK 2 wunderbar mit 8xAA und ~5xAF Schärfe durch LOD -2 und 2 Bit LOD-Fraction genießen – leider aber, wie schon so oft, nicht auf Screenshots bannen. Die mit einer Voodoo5 5500 PCI angefertigten 4xAA / LOD -1.5 Screenshots zeigen dabei ungefähr die Richtung an, in welche sich die Texturqualität bewegt.

[8]

Benchmarks Max Payne

• Spielversion: 1.05
• alle Details an
• 16-Bit-Texturen bei 16 Bit aktiviert
• 32-Bit-Texturen bei 32 Bit Farbtiefe

Um es auf den Punkt zu bringen: Max Paynes erste Tour durch die Unterwelt schmeckt den Voodoos unter Windows XP ganz und gar nicht. Während die Voodoo5 5500 etwa die Leistung der GeForce2 MX liefert, konkurriert die Voodoo5 6000 mit der GeForce2 GTS, nicht aber der GeForce2 Ultra. Erschwerend hinzu kommt das schon bekannte SLI-Problem in 1600x1200, wodurch 3dfx' Flaggschiff das Schlusslicht bildet. Bei 1024x768x32 und 4xAA sowie 1600x1200x32 kämpfen die Voodookarten zudem mit einem überfüllten VRAM, welcher sich gelegentlich mit weißen Flächen bemerkbar macht.

[8]

Part 2

Sonntag, 21. Januar 2007

 / von Mr. Lolman [1] & Raff [2] & robbitop [3]

 

Unsere Testläufe mit Windows 98 SE offenbaren, dass der XP-Treiber bei den Voodoos für einen nennenswerten Leistungsverlust sorgen kann. Die folgenden Werte illustrieren demzufolge das Geschehen unter Windows 98 SE:



[8]

Part 3

Sonntag, 21. Januar 2007

 / von Mr. Lolman [1] & Raff [2] & robbitop [3]

 



[8]

Part 4

Sonntag, 21. Januar 2007

 / von Mr. Lolman [1] & Raff [2] & robbitop [3]

 

Unter Windows XP noch weit abgeschlagen, kommt die Voodoo5 6000 in der Windows-98-Umgebung in die Gefilde der GeForce2 Ultra, die Mehrheit der Tests verliert sie aber auch mit 2,6 GHz CPU-Takt. Man sieht weiterhin, dass die GeForce2 Ultra unter Windows 98 nicht nennenswert schneller ist, die Ergebnisse halten sich in etwa die Waage.

Screenshots GeForce2
[116] 2xAA, 2xAF, 16 Bit [117]	[118] 2xAA, 2xAF, 32 Bit [119]	[120] 4xAA, 2xAF, 16 Bit [121]	[122] 4xAA, 2xAF, 32 Bit [123]
Screenshots GeForce3
[124] 2xAA, 2xAF, 16 Bit [125]	[126] 2xAA, 2xAF, 32 Bit [127]	[128] 4xS AA, 2xAF, 16 Bit [129]	[130] 4xS AA, 2xAF, 32 Bit [131]
Screenshots GeForceFX
[132] 2xAA, 2xAF, 16 Bit [133]	[134] 2xAA, 2xAF, 32 Bit [135]	[136] 4xS AA, 2xAF, 16 Bit [137]	[138] 4xS AA, 2xAF, 32 Bit [139]	[140] 8xS AA, 2xAF, 16 Bit [141]	[142] 8xS AA, 2xAF, 32 Bit [143]
Screenshots Kyro 2
[144] 2xAA, 2xAF, 16 Bit [145]	[146] 2xAA, 2xAF, 32 Bit [147]	[148] 4xAA, 2xAF, 16 Bit [149]	[150] 4xAA, 2xAF, 32 Bit [151]
Screenshots Radeon 8500
[152] 2xAA, 2xAF, 16 Bit [153]	[154] 2xAA, 2xAF, 32 Bit [155]	[156] 4xAA, 2xAF, 16 Bit [157]	[158] 4xAA, 2xAF, 32 Bit [159]
Screenshots Voodoo5
[160] 2xAA, 16 Bit [161]	[162] 2xAA, 32 Bit [163]	[164] 4xAA, 16 Bit [165]	[166] 4xAA, 32 Bit [167]

Während einerseits für die Leistungstests zur Wahrung der Vergleichbarkeit bilineare Filterung eingesetzt wurde, ist Max Payne auch ein wunderbares Beispiel für die Notwendigkeit einer trilinearen Filterung, weswegen wir für die Screenshotvergleiche diese auch aktivierten. Beim 3dfx Mipmap-Dithering egalisieren sich jedoch obige LOD-Berechnungen – ein Screenshot mit einem LOD-Bias von -0.5 ist somit nur so scharf, wie er auch mit einem trilinearen Filter wäre (~1,4xAF), was zumindest beim 3dfx 2xAA Screenshot ziemlich deutlich zu erkennen ist.



[8]

Benchmarks Max Payne 2

• Spielversion: 1.01
• Mirrors: Off
• Post-Processing: Off
• Pixel Shader Skins: Off
• Rest: High/On

3dfx' Flaggschiff macht durch den erhöhten Prozessortakt einen Satz von rund 100 Prozent und ist damit in 1024x768 Pari mit der GeForce2 Ultra. Auch die Voodoo5 5500 kann den Konkurrenten GeForce2 GTS in Schach halten. Mit zusätzlich eingeschaltetem 4x Supersampling lässt die Voodoo5 6000 schließlich das gesamte Feld hinter sich. Bitte beachten, dass GeForce3 und GeForce4 MX/Ti stets nur einen 2x-OGSS-Anteil plus 2x Multisampling (4xS) rendern müssen! Weiterhin sollte man hier erstmal den Blick auf die Werte mit 2,6 GHz konzentrieren. Denn wie auch unsere Zeitleiste zeigt, kam das Spiel Ende 2003 heraus und eine derartige CPU war einsetzbar.

Geradezu desaströs ist der Wert der Voodoo5 6000 hingegen in 1600x1200x32. Unglücklicherweise bringt es keiner der von uns getesteten Treiber zustande, Auflösungen über 1024x768 in annehmbarer Geschwindigkeit darzustellen. Das Problem scheint die SLI-Kommunikation der vier Chips empfindlich zu blockieren – so sehr, dass selbst das SingleChip-Modell Voodoo4 4500 schneller ist. Erfreulicherweise sind wenigstens Glide und OpenGL davon nicht betroffen.

Screenshots GeForce2
		[168] 2xAA, 2xAF, 32 Bit [169]	[170] 4xAA, 2xAF, 32 Bit [171]
Screenshots GeForce3
		[172] 2xAA, 2xAF, 32 Bit [173]	[174] 4xS AA, 2xAF, 32 Bit [175]
Screenshots GeForceFX
		[176] 4xS AA, 2xAF, 32 Bit [177]	[178] 8xS AA, 2xAF, 32 Bit [179]
Screenshots Kyro 2
		[180] 2xAA, 2xAF, 32 Bit [181]	[182] 4xAA, 2xAF, 32 Bit [183]
Screenshots Radeon 8500
		[184] 2xAA, 2xAF, 32 Bit [185]	[186] 4xAA, 2xAF, 32 Bit [187]
Screenshots Voodoo5
		[188] 2xAA, 32 Bit [189]	[190] 4xAA, 32 Bit [191]

Bei Max Payne 2 gilt das Gleiche wie schon bei Max Payne 1: Gegen eine stärkere LOD-Verschiebung bei den Voodoos spricht die durch das Mipmap-Dithering erhöhte Granularität des Bildes und die dementsprechend umso negativere Auswirkung einer LOD-Verschiebung. -0.75 wäre für 2xAA in vielen Szenen gerade noch in Ordnung – für eine mit 2xAF vergleichbare Schärfe bräuchte man aber trotzdem ein LOD von -1, was zumindest nach heutigen Maßstäben in den meisten Situationen untragbar wär.

[8]

Benchmarks Need for Speed: Porsche

• Spielversion: Inoffizieller Enhanced + Chrome Patch
• alle Details an
• nur 16 Bit, da einige Karten kein 32 Bit anbieten
• 3D-Sound aktiviert

Und wieder: SLI-Probleme bei der Voodoo5 6000 in 1600x1200 – die Voodoo5 5500 ist hier schneller. Dafür ist die Voodoo5 6000 in 1024x768 mit 4xAA allen anderen Karten meilenweit voraus, wobei der enorme Einbruch der GeForce4 Ti fast unerklärlich ist. Die GeForce4 MX ist sogar durchgehend sehr langsam, was sich aber stets reproduzieren ließ. Im übrigen testeten wir alle Karten unter Direct3D und installierten den neuesten (inoffiziellen) Patch sowie einen Chrom-Effekt für die Autos. 3dfx-Karten steht überdies ein (etwas schnellerer) Glide-Modus zur Verfügung. Da bei diesem aber Fraps [192] den Dienst verweigert, fielen diese Messungen leider aus. Mit der Radeon 8500 im Rechner wurde uns weiterhin 1600x1200x16 leider vorenthalten – dafür glänzt sie aber in den restlichen Disziplinen.

[8]

Part 2

Sonntag, 21. Januar 2007

 / von Mr. Lolman [1] & Raff [2] & robbitop [3]

 



[8]

Part 3

Sonntag, 16. März 2008

 / von Mr. Lolman [1] & Raff [2] & robbitop [3]

 

Ohne SLI-Probleme kann sich die Voodoo5 6000 stets an die Spitze setzen, wobei vor allem der 4xAA-Wert beeindruckt. Erstaunlicherweise profitiert hier sogar die GeForce2 Ultra vom anderen Betriebssystem, obwohl man eigentlich meinen sollte, dass die Windows XP Treiber mittlerweile durchgehend besser optimiert wurden.

Screenshots GeForce2
		[193] 4xAA, 2xAF, 32 Bit [194]	[195] 4xAA, 2xAF, 32 Bit [196]
Screenshots GeForce3
		[197] 4xS AA, 2xAF, 16 Bit [198]	[199] 4xS AA, 2xAF, 32 Bit [200]
Screenshots GeForceFX & Radeon X1900 XTX
		[201] 4xS AA, 16xAF, 16 Bit [202]	[203] 6xAA, 16xAF, 32 Bit [204]
Screenshots Kyro 2
		[205] 4xAA, 2xAF, 16 Bit [206]	[207] 4xAA, 2xAF, 32 Bit [208]
Screenshots Radeon 8500
		[209] 4xAA, 2xAF, 16 Bit [210]	[211] 4xAA, 2xAF, 32 Bit [212]
Screenshots Voodoo5
		[213] 4xAA, 16 Bit [214]	[215] 4xAA, 32 Bit [214]	[216] 8xAA, 16 Bit [217]

Im Gegensatz zu den Benchmarks konnten die 3dfx-Screenshots im – bezüglich der Performance deutlich zu präferierenden – Glide-Modus erzeugt werden. Zumindest unter 16 Bit, aber dies mit Erfolg: NFS Porsche ist das dritte Spiel im Bunde, wo es uns möglich war, das 3dfx 8xAA länger als nur für die Dauer des Spiels am Schirm zu halten. Trotz der unschlagbar schönen Kanten (am Scheibenwischer scheitern Adaptive-AA-Methoden teilweise) wird die Freude durch eine Kleinigkeit getrübt: Wieder einmal ein Mipmap-Verschiebungsproblem. Hier wird einem abermals vor Augen geführt, dass die Glide-Treiber nie vollständig auf die Voodoo5 6000 optimiert werden konnten. Der Radeon 8500 Screenshot schlägt deswegen so überdeutlich aus der Reihe, weil statt sichtbarer Scrolldown-Menüs leere Flächen anzeigt werden und damit die Auswahl von Strecke und Fahrzeug mehr oder weniger auf "Gut Glück" geschah.



[8]

Benchmarks Serious Sam: The Second Encounter

• Spielversion: 1.07
• "Normal"-Grafiksetting

[8]

Benchmarks Serious Sam: The Second Encounter (Forts.)

Hier zeigt sich das gleiche Bild wie schon bei Heavy Metal FAKK2: Mit einem Gigahertz Prozessortakt verweisen die GeForces alle anderen Karten auf die Plätze, sofern in 1024x768 und ohne Anti-Aliasing gebencht wird. In 1600x1200x16 gewinnt die Voodoo5 6000 schließlich den Anschluss an die GeForce2 Ultra und schlägt sie obendrein vernichtend in 32 Bit sowie in 1024x768 mit 4xAA. Mit 2,6 GHz führt die GeForce2 Ultra nur noch in 1024x768x16 mit ca. 11 Prozent Vorsprung, muss sich jedoch bei allem darüber geschlagen geben. Die GeForce3 entkommt der Voodoo5 600 in 1600x1200 nur knapp, nVidias GeForce4 Ti bleibt aber stets gänzlich außer Konkurrenz.

Screenshots GeForce2
	[218] 2xAA, 2xAF, 16 Bit [219]	[220] 2xAA, 2xAF, 32 Bit [221]	[222] 4xAA, 2xAF, 16 Bit [223]	[224] 4xAA, 2xAF, 32 Bit [225]
Screenshots GeForce3
	[226] 2xAA, 2xAF, 16 Bit [227]	[228] 2xAA, 2xAF, 32 Bit [229]	[230] 4xS AA, 2xAF, 16 Bit [231]	[232] 4xS AA, 2xAF, 32 Bit [233]
Screenshots GeForceFX
	[234] 4xS AA, 2xAF, 16 Bit [235]	[236] 4xS AA, 2xAF, 32 Bit [237]	[238] 8xS AA, 2xAF, 16 Bit [239]	[240] 8xS AA, 2xAF, 32 Bit [241]
Screenshots Kyro 2
	[242] 4xAA, 2xAF, 16 Bit [243]	[244] 4xAA, 2xAF, 32 Bit [245]
Screenshots Radeon 8500
	[246] 4xAA, 2xAF, 16 Bit [247]	[248] 4xAA, 2xAF, 32 Bit [249]
Screenshots Voodoo5
	[250] 2xAA, 16 Bit [251]	[252] 2xAA, 32 Bit [251]	[253] 4xAA, 16 Bit [254]	[255] 4xAA, 32 Bit [256]

Serious Sam: The Second Encounter ist ein weiteres Spiel, in welchem man 8xAA ablichten kann. Jedoch würde der Screenshot die tatsächliche Qualität schon zu sehr verfälschen: Entweder in Form von Regenbogenfarben oder einfach durch das schon von FAKK2 her bekannte Mipmap-Problem. Außerdem erkennt Serious Sam: TSE die Multitexturingfähigkeit von WickedGL nicht korrekt und erlaubt somit auch kein Mipmap-Blending, wie man auch anhand des 2xAA-Screenshots der Voodoo5 sehen kann. Anhand der Benchmarkergebnisse gehen wir natürlich davon aus, dass Multitexturing trotzdem aktiv ist.

[8]

Benchmarks Ultima IX

• Spielversion: 1.18f
• Sichtweite getweakt auf 10000
• 16 Bit: 16-Bit-Texturen
• 32 Bit: Komprimierte Texturen
• Voodoos: Glide, Rest: Direct3D

[8]

Benchmarks Ultima IX (Forts.)

Die Kyro II legt ohne Supersampling Anti-Aliasing schon mit 1 GHz CPU-Takt eine unglaubliche Performance zu Tage, wenn man ihre theoretische Rohleistung beachtet – dabei scheint sie auch alles darzustellen. Mit 2,6 GHz im Rücken kommt sie aber an ihre Grenzen, die bei der Konkurrenz oftmals weiter oben liegen. Die Topkarten des Testfeldes könnten womöglich noch 3 oder mehr Gigahertz in Mehrleistung umsetzen.

Screenshots GeForce2
[257] 2xAA, 2xAF, 16 Bit [258]	[259] 4xAA, 2xAF, 16 Bit [260]
Screenshots GeForce3
[261] 2xAA, 2xAF, 16 Bit [262]	[263] 4xS AA, 2xAF, 16 Bit [264]
Screenshots GeForceFX
[265] 2xAA, 2xAF, 16 Bit [266]	[267] 2xAA, 2xAF, 32 Bit [268]	[269] 4xS AA, 2xAF, 16 Bit [270]	[271] 4xS AA, 2xAF, 32 Bit [272]	[273] 8xS AA, 2xAF, 16 Bit [274]	[275] 8xS AA, 2xAF, 32 Bit [276]
Screenshots Kyro 2
[277] 2xAA, 2xAF, 16 Bit [278]	[279] 2xAA, 2xAF, 32 Bit [280]	[281] 4xAA, 2xAF, 16 Bit [282]	[283] 4xAA, 2xAF, 32 Bit [284]
Screenshots Radeon 8500
[285] 2xAA, 2xAF, 16 Bit [286]	[287] 2xAA, 2xAF, 32 Bit [288]	[289] 4xAA, 2xAF, 16 Bit [290]	[291] 4xAA, 2xAF, 32 Bit [292]
Screenshots Voodoo5
[293] 2xAA, 16 Bit [294]	[295] 2xAA, 32 Bit [296]	[297] 4xAA, 16 Bit [298]

Neben der anderen Farbgebung unter Glide fällt sofort die perfekt geglättete Hängebrücke bei den Kyro-Screenshots auf. Der Kyro-Treiber appliziert hier automatisch Alphablending, was jedoch mit fehlerhaften Kanten an den Blättern erkauft wird. Leider war es uns nicht möglich, einen fehlerfreien 3dfx 8xAA-Screenshot anzufertigen. Neuere Glide2-Treiber erstellen zwar Screenshots ohne Falschfarben, stellen im Spiel jedoch keine transparenten Texturen dar, was auf eine Inkompatibilität zum Chromakeying (eine Art Alphatesting) hinweist.

[8]

Benchmarks Unreal Tournament

• Spielversion: 4.36
• alle Details an
• EAX aktiviert
• APIs: Glide (Voodoos), Direct3D (Rest)
• OpenGL unterschlägt die Detail Textures, daher irrelevant

[8]

Benchmarks Unreal Tournament (Forts.)

Ein Sieg auf ganzer Linie für die Voodoo5 6000: Dank Glide liegt sie durchgängig auf GeForce3-Niveau, mit 4xAA schlägt sie überraschenderweise sogar die GeForce4 Ti. Der GeForce2 GTS scheint in 1600x1200 und mit 4xAA beim Sprung auf 32 Bit der VRAM auszugehen. Warum allerdings die GeForce3-Karten trotz 4xS so langsam sind, können wir auch nicht erklären: Die Frameraten waren allerdings stets reproduzierbar.

Screenshots GeForce2
		[299] 4xAA, 2xAF, 16 Bit [300]	[301] 4xAA, 2xAF, 32 Bit [302]
Screenshots GeForce3
		[303] 4xS AA, 2xAF, 16 Bit [304]	[305] 4xS AA, 2xAF, 32 Bit [306]
Screenshots GeForceFX
	[307] 4xS AA, 2xAF, 16 Bit [308]	[309] 4xS AA, 2xAF, 32 Bit [310]	[311] 8xS AA, 2xAF, 16 Bit [312]	[313] 8xS AA, 2xAF, 32 Bit [314]
Screenshots Kyro 2
		[315] 4xAA, 2xAF, 16 Bit [316]	[317] 4xAA, 2xAF, 32 Bit [318]
Screenshots Voodoo5 & Radeon X1900 XTX
	[319] 4xAA, 16 Bit [320]	[321] 8xAA, 16 Bit [322]		[323] 6xAA, 16xAF, 32 Bit [324]

In Unreal Tournament sind gleich mehrere Dinge auffällig: Es ist wieder eines der Spiele, in welchen man 8xAA korrekt abbilden kann. Auch bei der Farbdarstellung gibt es Besonderheiten: So hat in dem Spiel anscheinend jeder Grafikchip seine eigene Interpretation von korrekt applizierten Gammawerten. Die Darstellung in 16 Bit ist hier durchgehend heller als in 32 Bit. Bei 3dfx-Karten wirkt sich dies wieder einmal nur auf Screenshots aus – so sind alle 32 Bit Glide-Screenshots viel zu dunkel, und eine nachträgliche Aufhellung ist bei einem Bildqualitätsvergleich nicht nur tabu, sondern würde auch zu massivem Colorbanding führen. Da auf den 3dfx 32-Bit-Screenshots im Originalzustand quasi nichts zu erkennen ist, haben wir hier gleich komplett darauf verzichtet – im Spiel selber schaut das jedoch normal aus.

[8]

Benchmarks Unreal Tournament 2004

• Spielversion: 3369
• alle Details an
• nur 1024x768, weil 1600x1200 oft unspielbar ist
• nur 16 Bit, da der Voodoo-Treiber 32 Bit verweigert

Obwohl Unreal Tournament 2004 gemessen am übrigen Testfeld ein recht aktuelles Spiel ist, kann die Voodoo5 6000 überzeugen – zumindest dann, wenn man ihr eine starke CPU zur Seite stellt. Das Erscheinungsdatum des Spieles (Anfang 2004) erlaubt dies jedenfalls. Ohne Anti-Aliasing kann sie es dann mit GeForce2 Ultra und GeForce3 aufnehmen, um schließlich mit zugeschaltetem 2xAA fast in die Gefilde der GeForce4 Ti4200 (2xMSAA + 2xAF) vorzustossen. Kleiner Wermutstropfen: Egal was man einstellt, die Voodoos geben immer nur 16 Bit aus. Da dieses aber kaum von 32 Bit zu unterscheiden ist, stört das in der Praxis kaum. Die Kyro II offenbart weiterhin einige Texturfehler.

Beobachtern der Zahlen fällt sicherlich (neben dem Fehlen von 1600x1200 aus Performance-Gründen) noch etwas anderes auf: Die GeForce3 kann sich nicht von ihrem Vorgänger absetzen, aber die GeForce4 Ti ist dem restlichen Testfeld weit überlegen. Wir vermuten, dass Unreal Tournament 2004 aufgrund der großen Polygonmengen stark auf den erhöhten Vertex-Durchsatz der GeForce4 Ti reagiert. Dieser beträgt in unserem Fall Faktor 2,5 (verglichen mit der standardmässigen GeForce3).

Screenshots GeForce2
		[325] 2xAA, 2xAF, 16 Bit [326]	[327] 2xAA, 2xAF, 32 Bit [328]
Screenshots GeForce3
		[329] 2xAA, 2xAF, 16 Bit [330]	[331] 2xAA, 2xAF, 32 Bit [332]
Screenshots GeForceFX
	[333] 2xAA, 2xAF, 16 Bit [334]	[335] 2xAA, 2xAF, 32 Bit [336]	[337] 8xS AA, 16 Bit [338]	[339] 8xS AA, 32 Bit [340]
Screenshots Kyro 2
		[341] 2xAA, 2xAF, 16 Bit [342]	[343] 2xAA, 2xAF, 32 Bit [344]
Screenshots Voodoo5 & Radeon 8500
	[345] 2xAA, 16 Bit [346]		[347] 2xAA, 2xAF, 16 Bit [348]	[349] 2xAA, 2xAF, 32 Bit [350]

Unreal Tournament 2004 ist ein gutes Beispiel für die Probleme, welche bei massivem Alphablending unter 16 Bit Farbtiefe entstehen. So hat jeder Hersteller für jeden Grafikchip eine andere Vorstellung, die Probleme einer zu geringen Präzision in den Griff zu bekommen. Bei den Kyros schlägt hier deutlich der Vorteil des internen 32-Bit-Renderings zu Buche. Auffällig ist mit 16 Bit Farbtiefe eine Grünverschiebung bei den Voodoos, die jedoch nur unter Direct3D aufzutreten scheint, sowie eine Violettverschiebung der GeForce2-Karten. Weiterhin stellt 3dfx die Waffe am schönsten dar, während sich die Kyro das Beleuchten derselbigen gleich komplett spart. Mit letzterer trifft man ohnehin (je nach Level) mehr oder minder schwere Textur-Abstinenzen an.

[8]

CPU-Skalierung und Durchschnittswerte

Die vorstehenden Zahlen offenbaren viele Siege, aber auch viele Niederlagen unseres Titelgebers. Um einen Überblick darüber zu bekommen, wer im Durchschnitt die Nase vorne hat, haben wir uns einige Statistiken ausgedacht. Diese veranschaulichen einerseits die Durchschnitts-Frameraten aller Spiele sowie den prozentualen Gewinn bei Erhöhung des CPU-Taktes. Da wir aber niemanden ein zweites Mal mit der Zahlenkeule erschlagen wollen, beschränkten wir uns auf die interessantesten Karten für diesen Artikel: Die Voodoo5 6000, den Hauptkonkurrenten GeForce2 Ultra und dessen Nachfolger GeForce3.

Obwohl wir zur Berechnung der Durchschnitts-fps bei der Voodoo5 6000 die Werte aus den Windows-98-Tests integrierten, verliert die Voodoo5 6000 in diesem Vergleich an Boden. Gut zu sehen ist, dass sie in 1024x768 bei mehr CPU-Leistung am meisten zulegt und damit praktisch gleichauf mit der GeForce3 ist. In 1600x1200 schlägt allerdings der SLI-Bug voll durch: Die unterirdischen Werte aus Dungeon Siege 2 und Max Payne 2 sorgen dafür, dass der hervorragende Eindruck bei den damaligen Titeln im Schnitt untergeht.

Dennoch: Das Niveau der GeForce2 Ultra wird fast erreicht. Unterschieden werden muss nur klar zwischen neuen und alten Spielen. Bei ersteren profitieren die GeForce-Karten klar von ihren aktuellen Treibern, während die Voodoos das Nachsehen haben. Betrachtet man jedoch nur die Spiele um den Releasezeitpunkt der Karten, dann sieht das Bild vor allem in 1600x1200 anders aus.

[8]

Benchmarks mit 8x SGSSAA/LOD -2

Dieser Abschnitt widmet sich abermals der herausragenden Kantenglättung der Voodoo5 6000. Wäre 8xAA in den damaligen Spielen stets nutzbar gewesen? Wenn ja, in welcher Auflösung? Und wieviel Luft bliebe für zukünftige Spiele? Die folgenden Zahlen geben Aufschluss:

Wie man sieht, hätte die Rohleistung für durchgängig ausreichende Frameraten in 800x600x16 gereicht. Das mag auf den ersten Blick schwach erscheinen, allerdings lässt das 8xAA bereits in dieser Auflösung kaum einen Wunsch offen. Höhere Auflösungen wären natürlich auch möglich gewesen – garniert mit dem ebenfalls sehr guten 4xAA.

[8]

Fazit

Hier ist es nun, das volle Leistungsspektrum der Voodoo5 6000. Ein eindeutiges Fazit lässt sich allerdings nicht finden, daher wollen wir zuerst einige Teilergebnisse erläutern.

Es ist nicht zu übersehen, dass 3dfx' Spitzenkarte nicht überall vorn liegt, die absolute Performance-Krone wäre folglich auch durch den Markteintritt der Voodoo5 6000 nicht an 3dfx (zurück)gegangen. Nun, woran liegt das? Ganz einfach: Die Voodoo5 6000 steht und fällt mit der sie umgebenden Infrastruktur sowie den genutzten Spielesettings. Das ist primär auf den Mangel von Hardware-T&L zurückzuführen. Unsere Testspiele der Jahre 2000 und 2001 zeigen bei 1,0 GHz CPU-Takt klar, dass Nutzer kleinerer Auflösungen mit Affinität zu hohen Frameraten damals mit einer GeForce2-Grafikkarte besser bedient waren.

Diese sind dort ungeschlagen schnell, während die Voodoo5-Serie oft auf die CPU warten muss. Gerade die Voodoo5 6000 weist eine so hohe Rohleistung auf, dass sie mit der (simulierten) HighEnd-CPU des Jahres 2000 bei 32 Bit und hohen Auflösungen nur geringe Einbrüche zu verzeichnen hat. Dank der damals enorm hohen Bandbreite von 11,7 Gigabyte/s und effektiv nutzbaren 1,46 Gigapixeln/s kann sie spätestens in 1600x1200x16 zur GeForce2 Ultra aufschließen und sie in 1600x1200x32 durchgängig schlagen. In dieser Auflösung liegen stellenweise sogar riesige Abgründe zwischen den beiden Kontrahenten, wie in Heavy Metal FAKK2 und Unreal Tournament zu sehen.

Diese Lücke schließt erst die GeForce3: Mit ihren gravierenden architektonischen Verbesserungen, allen voran dem Crossbar Memory Controller, überholt sie ihren direkten Vorgänger deutlich. Erstaunlicherweise gelingt es ihr aber nicht durchgängig, die Voodoo5 6000 zu schlagen. Sogar der kleinsten GeForce4 Ti kommt die Voodoo5 6000 in Einzelfällen bedrohlich nahe. Man kann also festhalten, dass die Voodoo5 6000 genau dort punktet, woran man auch heutzutage eine gute Grafikkarte beurteilt: In hohen Auflösungen und bei maximal möglicher Bildqualität.

Wie erwartet, profitiert die Voodoo5 6000 weiterhin am meisten von der CPU-Aufrüstung. Während Voodoo5 5500, GeForce2 GTS und alle Grafikkarten darunter mit einem Gigahertz CPU-Takt bereits fast vollständig ausgelastet sind, kann gerade 3dfx' "Quad-SLI" auch in den fordernsten Einstellungen einige fps gutmachen. Die Zahlen zeigen im Grunde das, was wir versuchten zu erreichen: Der Vorsprung der GeForce2-Serie schwindet bei 2,6 GHz deutlich. Die Voodoo5 6000 hätte demnach damals mit demselben Problem zu kämpfen gehabt, welches aktuell nVidias GeForce 8800 GTX (SLI) befällt: Erst sehr hohe Auflösungen und/oder eine radikal übertaktete CPU zeigen das wahre Potenzial – die Voodoo5 6000 war also auf recht paradoxe Art und Weise "zukunftssicher". Paradox deswegen, weil man dies von ihr mangels diverser Features nicht erwartete.

Weiterhin zeigt sich bei den aktuelleren Spielen klar der Zahn der Zeit in Sachen Treiber: SLI-Probleme und Inkompatibilitäten vergrößern den Abstand zu den GeForce-Karten – leider genau dort, wo sie bei den älteren Spielen punkten kann (1600x1200). Wie die Ergebnisse bei Dungeon Siege 2, Max Payne 1/2 und Unreal Tournament 2004 mit optimierten Treibern aussehen würden, kann niemand so genau sagen. Sicher ist allerdings, dass eine per Treiber forcierbare Texturkompression oft enorme Vorteile mit sich bringen würde, denn die 32 MiB VRAM pro Chip reichen in 32 Bit und höheren Auflösungen oft nicht mehr aus.

Besonderes Augenmerk sollte man weiterhin auf die Effizienz des 3dfx-SLI legen, denn sie liegt unter optimalen Konditionen sogar über der sagenhaften 100%-Marke! Die Voodoo5 5500 performt bei gleicher Taktung (166/166 MHz) dank verdoppelter Einheiten ziemlich genau zwei Mal so schnell wie die Voodoo4 4500 – vorausgesetzt es liegt keine CPU/Interface-Limitierung vor. Bei der Voodoo5 6000 haben wir es davon ausgehend mit dem theoretischen Faktor 2,2 zu tun. Wer die Benchwerte genau betrachtet, der wird beispielsweise bei Max Payne 2 mit 4xAA jedoch eine praktische Leistungssteigerung von 150% feststellen. Genau erklären können wir dieses erstaunliche Verhalten auch nicht, wir gehen aber davon aus, dass dies dem VRAM-"Pool", welcher bei jeder Steigerung der GPU-Anzahl vergrößert wird, zu verdanken ist.

Wie wir bereits im Extrateil zur Bildqualität ausführten, hat 3dfx' VSA-Serie in diesem Bereich eine Reihe Vorteile. Schon eine Voodoo4 4500 kann es beim Anti-Aliasing dank rotiertem Muster qualitativ knapp mit einer GeForce2 Ultra aufnehmen (aber natürlich nicht bei der Geschwindigkeit der Ausführung). Was allerdings Voodoo5 5500 und insbesondere Voodoo5 6000 an AA-Qualität auffahren, ist auch aktuell noch Oberklasse und speziell von den anderen Karten gleichen Alters unerreicht.

Kombiniert mit der guten 16/22-Bit-Optik, die nur in Einzelfällen von der intern stets mit 32 Bit rechnenden Kyro übertroffen wird, sind das zwei klare Pluspunkte. Abzüge gibt es bei der Texturfilterung: Die Kombination aus hochwertigem Supersampling und LOD-Verschiebung bringt zwar gute Qualität, eine GeForce2 mit aktiviertem 2x2 OGSSAA und zusätzlich aktivierter 2facher anisotroper Filterung liegt aber durchschnittlich hauchdünn vor der Texturqualität, welche die Voodoo5 6000 bei 8x SGSSAA samt einem LOD von -2 erreicht.

Kombiniert man diese Ausführungen, kommt heraus, dass die GeForce2 Ultra insgesamt das "rundere" Paket bietet. Schon mit schwachen CPUs sehr schnell, in jedem Mainboard lauffähig, ausreichend Leistung für 1600x1200 und gelegentlich etwas AA/AF – insgesamt keine gravierenden Schnitzer also. Die Voodoo5 6000 hingegen wäre Ende 2000 die mit Abstand schnellste Karte für hohe Auflösungen, Anti-Aliasing und das allseits geforderte 32 Bit gewesen. Diese brachiale Rohleistung muss man bei neuerer Software allerdings mit der Lupe suchen, da die Treiber trotz eifriger Fan-Arbeit erhebliche Defizite aufweisen. Würde 3dfx noch unter den Lebenden verweilen, dann stünde die Voodoo5 6000 dank deren Optimierung vermutlich deutlich besser
da.

3dfx mag zwar mittlerweile länger tot als lebendig sein, aber noch immer gibt es weltweit einige treue Fans, welche deren Fahne hochhalten. Allen gemein ist die Vergötterung der Grafikkarte, die soeben eine durchaus beachtliche Vorstellung ihrer Leistungsfähigkeit demonstrierte. Wir glauben, dass selbst der größte Kritiker nach dem Lesen dieses Artikels zugeben muss, dass die "Göttin" auf ihre ganz eigene Art extrem beeindruckend ist – nicht wahr?

An dieser Stelle wollen wir noch von einer unserer beiden Testkarten Abschied nehmen. Sie starb am Sonntag, den 7. Januar 2007 beim Wiedereinbau ins System. Unsere Hoffnungen liegen nun bei ihrem Meister, der auch schon der anderen Karte zu neuem Leben verhalf.

Danksagung
Wir danken unserem Forumsmitglied Juerg [351] für die Bereitstellung eines Makros, welches die Arbeit an den Benchmark-Diagramm erheblich vereinfachte.

[8]