Zum 3DCenter Forum
Inhalt




Matrox Parhelia Preview

14. Mai 2002 / von aths / Seite 5 von 7



   PixelShader

Die Rendering-Pipelines des Parhelia besitzen PixelShader 1.3 Funktionalität. Sie erfüllen hier auf keinen Fall DirectX9-Anforderungen, weshalb der Parhelia insgesamt gesehen nicht DirectX9-kompatibel ist. Dass die PixelShader Version 1.4 nicht erfüllt wird, ist ebenso bedauerlich, hier stehen die Besitzer einer ATi Radeon 8500 weiterhin allein auf weiter Flur.

Allerdings muss man dazusagen, dass die Architektur des Parhelia-Chips auch nicht auf PixelShader 1.4 ausgelegt ist. Denn dieser erfordert die Fähigkeit, bis zu 6 Texturen pro Rendering-Durchgang laden zu können. Die Pipelines des Parhelia können jedoch nur 4 Texturen pro Rending-Durchgang auf ein Dreieck kleben. Damit steht der Parhelia gleichwertig neben der GeForce4 sowie der GeForce3 (jene beherrscht allerdings nur PixelShader 1.1).

Der große Unterschied zur GeForce 3/4 ist, dass weniger Takte benötigt werden, um ein PixelShader-Programm mit mehreren Texturen oder Befehlen abzuarbeiten. Wir erwarten hier also eine sehr gute PixelShader-Performance. Das ist relevant, da derart texturierte Pixel großen Rechen- und damit Zeitaufwand beim Rendering erfordern. Die GeForce 3/4 kann konkret pro Pipeline und Takt zwei PixelShader-Instuktionen verarbeiten, in der Regel findet dann ein Pipeline-Combining statt. Effektiv werden dann aus den originalen vier Pipelines der GeForce 3/4 zwei, die dafür aber 4 Instruktionen pro Takt verarbeiten.

Eine einzige Parhelia-Pipeline kann jedoch bereits 5 Shader-Instruktionen ausführen. Ein Combining, sprich das Zusammenlegen von Pipelines, ist damit nur dann erforderlich, wenn mehr als 5 Shader-Instruktionen benötigt werden. Ansonsten verfügt der Parhlia weiterhin über 4 effektive Pipelines, statt nur über 2 wie bei der Konkurrenz. Kommen PixelShader zum Einsatz, reicht zudem für die meisten Textur-Zugriffe der bilineare Filter aus. Deshalb ist Parhelias Architektur trotz dieser Einschränkung des bilinearen Filterns der GeForce 3/4 Architektur in Bezug auf den PixelShader überlegen.

Solange DirectX9 zudem nicht entgültig abgeschlossen ist (der Beta-Test ist noch nicht einmal angelaufen), wird es keine DirectX9-kompatible Hardware zu kaufen geben. Es ist derweilen allerdings sicher, dass eine neue PixelShader-Version zu DirectX9 hinzu gehören wird (PixelShader 2.0). Diese wird eine neue Architektur benötigen, welche sich eher an Version 1.4 orientiert. Denn 1.4 ist nicht einfach nur eine erweiterte Variante von 1.3, sondern ein deutlich anderes Konzept. Um es stark vereinfacht zu sagen: Während man sich mit den "alten" Shadern nur die Effekte selbst schreibt, schreibt man in ATi´s PixelShader 1.4 Variante in der Radeon 8500 auch die Berechnung, wie diese Effekte erzeugt werden, selbst. Das ist aufwändiger, dafür ist aber man noch freier.

Matrox setzt hier auf die "alte" PixelShader Architektur, womit der Markt nun entgültig unübersichtlich wird. Bislang sah es so aus, dass wegen der GeForce3 PixelShader 1.1 verwendet wird und unter Umständen noch Shader für 1.4 und damit extra für die Radeon 8500 (und einer möglicherweise hochgetakten Neuauflage) geschrieben werden. Mit GeForce4, Parhelia und wohl auch dem SiS Xabre sowie dem 3Dlabs P10 gewinnt Version 1.3 aber auch eine größere Basis. Lohnt es sich denn überhaupt, für diese Karten mit PixelShader 1.3 extra Shader zu schreiben, da die PixelShader 1.3 in dem Sinne ja nur eine Erweiterung von PixelShader 1.1 darstellen?

Das hängt entscheidend von den gewünschten Effekten ab. Alle wichtigen Beleuchtungs- und Bumpmapping-Effekte lassen sich schon mit 1.0 gestalten, wobei 1.1 längere Programme bei kürzerer Schreibweise ermöglicht. Das Update auf PixelShader 1.3 führt "nur" neue Befehle ein. Diese lassen sich vor allem in Bezug auf prozedurale Texturen nutzen, ermöglichen aber auch Z-korrektes Bump Mapping. Wir erlauben uns in Ermangelung einer besseren Alternative dazu ein Beispiel aus dem nVidia Tidepool-Demo zu zeigen:



Bild: PixelShader 1.3 mit Z-korrektem Bump Mapping
Mouseover: PixelShader 1.1 ohne Z-korrektem Bump Mapping
Klick: Beide Bilder zusammen.

Fassen wir zusammen: Kompatibel mit DirectX 8.1, verfügt der Parhelia über Pipelines mit PixelShader 1.3 Funktionalität. Das ist weder besonders gut, noch besonders schlecht. Mit einer Ausnahme, allerdings äußern wir folgendes unter Vorbehalt: Offenbar kann der Parhelia dank Pipeline Combining einen kompletten PS1.3 Shader effektiv in einem Takt rendern. Eine kombinierte Parhelia-Pipeline kann nämlich alle 4 erforderlichen Texturen laden und verfügt über 10 PixelShader-Stages (8 würden ausreichen, der Rest ist unter Umständen in OpenGL verwendbar). Die GeForce 3/4 benötigt für dieserart komplexe Shader-Programme mehrere Takte.



   Anisotrope Filterung

Beim PixelShader gingen wir bereits auf die Pipelines ein, doch dies wollen wir hier in Bezug auf die Filtertechniken des Parhelia-Chips konkretisieren. Zur Erinnerung: Matrox hat zwar die Anzahl der TMUs pro Pipeline verdoppelt, allerdings haben diese einen recht einfachen Aufbau: Sie können jeweils nur bilinear filtern.

Soll allerdings trilineare Filterung genutzt werden, bleibt effektiv nur die von GeForce2 GTS/Pro/Ultra bekannte 4x2-Architektur. Vergleicht man die Texelfüllrate bei trilinearer Filterung, so bleibt dem Parhelia verglichen mit der aktuellen Konkurrenz pro Takt nur mehr Bandbreite, nicht aber mehr Füllrate. Höhere anisotrope Stufen sind demnach zwar möglich, jedoch werden dadurch weitere TMUs in Beschlag genommen.

Man kann jedoch auch nicht einfach sagen: "Ich spiele grundsätzlich mit trilinearer Filterung, und in diesem Falle ist die Parhelia-Architektur auch nicht besser als die einer GeForce 3/4." Für Lightmaps findet beispielsweise kein MIP-Mapping statt, demzufolge werden sie auch nicht trilinear gefiltert. Während die GeForce3 pro Takt 4 doppelt texturierte Pixel ausgeben kann, kann der Parhelia 4 dreifach texturierte Pixel ausgeben - solange sich zwei bilinear gefilterte Texturen darunter befinden.

Der Parhelia ist in der Lage, pro Pixel bis zu 64 Textur-Samples zur Filterung zu lesen. Umgerechnet ergibt das entweder 8x anisotroper Filter mit MIP-Map-Interpolation ("trilinear") oder 16x anisotroper Filter ohne MIP-Map-Interpolation ("bilinear"). Matrox´ Implementation vom anisotropen Filter schafft also die gleiche Stufe wie die GeForce 3/4 (8x "trilinear") bzw. die Radeon 8500 (16x "bilinear").

Eine TMU, die bilinear filtern kann, liefert exakt 4 Texture-Samples. Um auf 64 Samples pro Pixel zu kommen, müssen alle 16 TMUs denselben Pixel bedienen. Soll pro Takt eine doppelte Texturierung stattfinden, bleiben zum Filtern natürlich nur noch je 32 Samples. Das heisst konkret: Hochwertige anisotrope Filterung kostet kräftig Leistung. Die Framerate wird mit anisotropen Filter voraussichtlich deutlich einbrechen. Allerdings wahrscheinlich von einem sehr hohem Niveau aus, so daß auch anisotrope Filterung mit dem Parhelia gut nutzbar sein wird. Und Bandbreiten-Probleme wie bei der Konkurrenz sind beim Parhelia denn eher nicht zu erwarten :-).






Kommentare, Meinungen, Kritiken können ins Forum geschrieben werden - Registrierung ist nicht notwendig Zurück / Back Weiter / Next

Shortcuts
nach oben