Matrox Parhelia Preview

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

   Grundarchitektur

Die grundlegende Render-Architektur lässt sich grafisch am einfachsten beschreiben, deshalb lassen wir hier vor allem Bilder statt Worte sprechen. Zunächst als Beispiel die Voodoo1, Voodoo3, Riva TNT 1/2, Savage 2000, GeForce1, GeForce2 MX und GeForce4 MX, in Klammern dabei die effektive Bitbreite der jeweiligen RAM-Interfaces:

Nun zur Architektur der GeForce2-Serie (GeForce2 GTS, Pro und Ultra, nicht GeForce2 MX) und der GeForce 3/4 sowie der Radeon 8500. Die GeForce 3/4 kann im Gegensatz zur GeForce2-Serie ebenfalls ihre Pipelines zusammenschalten, um mit halbierter Pipeline-Zahl dann 4 Texturen pro Takt zu ermöglichen.

Der Matrox Parhelia sieht dagegen folgendermaßen aus:

Die Frage, ob die TMUs (Texture mapping unit = Textureneinheit) sinnvoll verteilt sind, ist allerdings berechtigt. Auf den ersten Blick böte eine Architektur mit 8 Rendering-Pipelines á 2 Textureneinheiten einige Vorteile, denn diese 8 x 2 Anordnung böte ein effizienteres Rendering: Nur bei einer ungeraden Texturen-Anzahl bliebe dann Elektronik brach liegen. Bei Matrox´ Design besteht diese Ineffizienz jedoch bei jeder nicht durch 4 teilbaren Zahl. Doch eine "breite" Architektur hat auch Nachteile: Die komplette Rendering-Einheit kann nämlich immer nur eine einzige Dreiecks-Zeile zur gleichen Zeit rendern.

Im Zuge höherer Geometrie-Details, sprich höherer Polygonzahlen, werden die Dreiecke naturgemäß immer kleiner. Je breiter die Architektur, sprich je mehr Pipelines vorhanden sind, desto größer ist die Gefahr, dass einige komplett nichts zu tun bekommen. Matrox ging also den Weg "hoch statt breit". Das hat angesichts der PixelShader 1.3 Fähigkeiten zudem einige angenehme Auswirkungen. Denn um die bis zu 4 Texturen, die ein PixelShader 1.3 Programm nutzen kann, zu laden, vergeht so nur ein einziger Takt (da je 4 TMUs vorhanden). Da pro Pipeline und Takt optimalerweise 4 Texturen geladen werden sollten, ist im übrigen wieder die extreme Bandbreite des Parhelia sehr von Nutzem.

Es ist jedoch hier immer zu beachten: Die TMUs des Parhelia können jeweils nur bilinear filtern. Für trilineare Filterung werden immer zwei TMUs benötigt. Die TMUs einer GeForce- oder Radeon-Karte können prinzipiell trilinear filtern. Ginge man davon aus, dass man grundsätzlich nur noch trilinear spielen würde, scheint die Parhelia-Architektur ohne Vorteile gegenüber der GeForce 3/4 und der Radeon 8500 zu sein. Diese Vorteile gibt es in kleinerem Maße aber dennoch, wir werden diese Feinheiten dann beim PixelShader und bei der Frage der anisotropen Filterung genauer betrachten (Update: Irrtum - nur die TMUs der GeForce1 beherrschen eine trilineare Filterung in einem Taktzyklus, alle andere Grafikchips von ATi & nVidia benötigen hierfür 2 TMUs oder 2 Taktzyklen).

Fast uneingeschränkt wesentlicher als die vorhergehenden Betrachtungen, welche nur etwas über die Füllrate aussagen, ist natürlich der Blick auf die Speicherbandbreite. Matrox setzt hier ähnlich wie 3Dlabs´ P10-Chip auf ein HighEnd-Performance versprechendes, aber eben auch sehr kostspielig zu realisierendes 256bittiges DDR-RAM Interface, welches aus logischer Sicht ein 512bittiges Interface darstellt (deswegen auch die Bezeichnung "512 Bit Renderer"). Warum aber schlug man diesen kostenintensiven Weg ein?

Nun, zunächst lassen sich durch dieses superbreite Speicherinterface an anderer Stelle wieder Kosten sparen. ATi & nVidia sind immer davon abhängig, wie hoch sich der derzeit beste DDR-RAM der Speicherhersteller takten lässt und bezahlen diesen Speicher auch dementsprechend teuer. Matrox kann dank doppelter Zugriffs-Breite auch deutlich langsamere Bausteine einsetzen und erreicht trotzdem mehr Bandbreite. Zudem kann auch das Layout eines Boards mit geringeren Taktraten einfacher ausfallen als eines Boards mit sehr hohen Taktraten, für letzteres steigt nun einmal auch der Aufwand bei der Grafikboard-Herstellung.

Zudem gilt bei aktuellen Spielen: Bandbreite braucht man bekanntlich für faktisch alles. Erst recht für Qualitätsmerkmale wie anisotropes Filtering oder Anti-Aliasing. Nutzt man diese Features, gilt: Mehr Bandbreite = Mehr Frames. So ist 4x Anti-Aliasing selbst auf der GeForce4 noch stark bandbreitenlimitiert. Wer Anti-Aliasing-Benchmarks gewinnen will, darf also nicht an der Speicherbandbreite sparen. Hinzu kommt, dass Matrox pro Takt bis zu 16 (wenn auch nur bilinear gefilterte) Texturwerte lesen kann. Zudem sind auch PixelShader, was Speicherbandbreite angeht, nicht zimperlich in ihren Anforderungen.

Matrox´ Lösung über ein breiteres Interface ist, Multichip-Desings oder HSR einmal ausgeschlossen, die einzige Möglichkeit, einem Grafikchip einen entscheidenden Geschwindigkeitsschub zu verpassen. Sicher erscheint es momentan nicht so, als würden ATi & nVidia die immer neuen HighEnd-RAMs mit immer kürzeren Zugriffszeiten respektive immer höheren Taktfrequenzen ausgehen. Dennoch ist es über den Weg der reinen Takterhöhung kaum möglich, mal eben so die doppelte Speicherbandbreite wie mit einem doppelt so breiten Interface zur Verfügung zu stellen, auch wenn jene nur einen theoretischen Wert darstellt.

Einen theoretischen Wert stellt die Speicherbandbreite besonders im Vergleich 256bittige Chips und 512bittige Chips vor allem deshalb dar, da die Effizenz des Interfaces mit der größeren Breite des Interface abnimmt. Konkretes Extrem-Beispiel: Sind nur 64 reale Bit in den Speicher zu schreiben, verbraucht man bei einem 256bittigem Chip trotzdem dafür einen ganzen Schreibvorgang und damit alle kompletten 256 Bit. Davon sind dann natürlich 196 Bit sinnlose Füllbits. Bei einem 512bittigem Chip wären dies allerdings schon 448 sinnlose Füllbits in diesem Extrem-Beispiel - die Effizienz nimmt deutlichst ab (25 Prozent zu 12,5 Prozent -> nur in diesem speziellem Beispiel!).

In der Realität ist dieser Effizienz-Verlust nicht so hoch wie in vorherigem Beispiel, aber er war immerhin ausreichend dafür, dass nVidia bei der GeForce3 eine der unbeachtesten GeForce3-Innovationen einführte: Den "Crossbar Memory Controller". Dieser unterteilt das logisch gesehen 256bittige Speicherinterface in 4 Abschnitte á 64 Bit, womit man die Effizienz in obigen Beispiel auf (unrealistische) 100 Prozent steigern würde, was in der Praxis immerhin auf ca. 10 bis 20 Prozent reine Mehr-Performance hinausläuft.

Auch Matrox´ Parhelia-Chip scheint nach leider nicht ganz eindeutigen Angaben in den offiziellen Unterlagen auf das selbe System zur Erhaltung der Effizienz des superbreiten 512bittigen Speicherinterfaces zurückzugreifen. Nach derzeitigem Wissensstand verfügt der Parhelia über ein Speicherinterface, welches in 4 Abschnitte á 128 Bit unterteilt ist. Damit dürfte die Effizienz dieses sehr breiten Speicherinterfaces ausreichend gewahrt bleiben.

Ebenso ist die Frage, ob Parhelia Occlusion-Technologien besitzt, derzeit völlig offen. Entweder wollte Matrox nicht gleich das ganze Pulver verschießen, oder (und das ist wahrscheinlicher) der Parhelia hat keine. Auch wenn Matrox das nicht erwähnt, so vermuten wir, dass der Parhelia wenigstens den Z-Test vor dem Rendervorgang ausführt.

Kommen wir nun zu einer besonderen Feinheit des Parhelias: Das 40-Bit-Rendering. Das ist neu, dann wieder nicht, dann aber wieder doch. Doch der Reihe nach :-).

Intern mit erhöhter Genauigkeit zu rendern, ist keine wirkliche Neuheit - der VSA-100 Chip der Voodoo 4/5 macht das seit eh und je. Microsoft empfahl für DirectX8 internes 48-Bit-Rendering, für DirectX9 wird nun 40-Bit-Rendering als Mindestanforderung verlangt. Obwohl der Parhelia kein vollständiger DirectX9-Chip ist, so erfüllt er diesen Teil der Anforderungen (anderen Quellen zufolge wird DirectX9 allerdings sogar internes 64-Bit-Floatingpoint-Rendering verlangen). Matrox fand hierfür blumige Begriffe wie "GigaColorTechnologie". Schauen wir uns nun einmal an, was sich hinter dieser "aussagekräftigen" Bezeichnung verbirgt.

Die 40 Bit gelten für 4 Kanäle, so dass pro Kanal 10 Bit bleiben. PixelShader 1.0 - 1.3 erfordern allerdings zwingend ein Vorzeichen-Bit. Damit bleiben theoretisch nur 9 Bits für die Farbauflösung. Uns ist derzeit schleierhaft, wie Matrox die 1 Milliarde gleichzeitig darstellbaren Farben berechnet hat, diese gelten offenbar nur für den 2D-Modus. Die 9 Bits (ohne das Vorzeichen) ergeben denn eigentlich "nur" 130 Millionen Farben. Ebenfalls noch unklar ist derzeit, wie das Vorzeichen-Bit gehandhabt wird. Möglicherweise kann Parhelia nämlich mit Farben "dunkler als Schwarz" umgehen. Diese sind zwar für den Gamer-Markt fast komplett uninteressant, können in bestimmten professionellen Bereichen allerdings durchaus Sinn machen.

Matrox bietet allerdings eine weitere Neuigkeit, welche 40-Bit-Rendering erst so richtig interessant werden lässt: Denn bislang wurden die Farbwerte beim Schreiben in den Framebuffer immer auf 8 Bit pro Kanal reduziert. Matrox bietet nun mit dem Parhelia einen Framebuffer-Modus mit der Aufteilung ARGB 2-10-10-10. Die originale Gesamtbreite für ein Farbwort blieb bestehen (32 Bit), doch durch eine Reduzierung der Genauigkeit des Alpha-Kanals wurde Platz für die höhere Genauigkeit der eigentlichen Farbwerte geschaffen. Konkret: Auch wenn mehrere Rendering-Durchgänge erforderlich sind, verliert die Darstellung des Parhelia dadurch nicht an Qualität, da die Zwischenergebnisse nicht für das Schreiben in den Speicher gerundet werden müssen.