Vorschau auf Matrox Parhelia: DirectX 9 nicht ganz erfüllt

4/6

13.5.2002 20:00 Uhr Carsten Spille

Parhelia im Detail

Und nun wollen wir uns näher mit des Pudels Kern befassen, dem internen Aufbau des Parhelia. Ohne große Worte lassen wir die Zahlen erst einmal auf uns einwirken...

350MHz Chiptakt
~300MHz-DDR RAM-Takt
0,15µ Fertigungsprozess
~ 80 Millionen Transistoren
256Bit-DDR Speicherinterface
~19,2GB/s Speichertransferrate
1,4GPixel/s Pixelfüllrate
5,6GTexel/s Texelfüllrate
4 Pipelines mit je 4 TMUs (Texture Mapping Unit)
8xAGP Unterstützung (abwärtskompatibel)
4 Vertexshader 2.0
Pixelshader 1.3 (!)
Dot3 & Environment Mapped Bump-Mapping Support
festverdrahteter DX8-Vertexshader für Matrix Blending und Skinning
40Bit interne Rendering-Genauigkeit (je 10Bit für R,G,B und Alpha)
2 400MHz UltraSharp (TM) RAMDACs
DVD & HDTV Unterstützung mit 10Bit-Präzision
max. Auflösung 2048x1536@85Hz
2 interne TDMS Transmitter mit jeweils bis zu 1920x1024x32Bit
2 völlig unabhängige Monitorcontroller
Triple Head mit bis zu 3840x1024x32Bit für Surround Gaming
Adaptives Fragment Supersampling FSAA (bis zu 16x)
n-Patch Unterstützung mit adaptiver Tesselation (LOD-Anpassung) und Displacement Mapping
Glyph Antialiasing für Schriftartenschärfung
DirectX 8 und OpenGL 1.3 Unterstützung mit der Option auf einige DirectX9 Feature

Interessant ist zum Einen der offensichtliche Verzicht auf Pixelshader 2.0. Warum das so ist, wird sicher vorerst Matrox' Geheimnis bleiben, vielleicht wollte man nur schnell den Chip ankündigen um zumindest beim Paperlaunch einen Vorsprung vor der Konkurrenz zu haben oder man plant, bis sich DirectX-9 durchgesetzt hat, bereits eine verbesserte Version des Parhelia.

Möglicherweise war man auch während der Entwicklung noch nicht mit endgültigen Spezifikationen für den Pixelshader 2.0 von Microsoft versorgt worden, da sich DirectX9 ja schon das eine oder andere Mal ein wenig verzögert hat.

Weiterhin erstaunte es uns, dass solch ein Silizium-Monster mit 80 Millionen Transistoren mit 350MHz angepeiltem Arbeitstakt noch in 0,15µ hergestellt werden soll. nVidia scheint hier mit 63Millionen Transistoren bei 300MHz bereits nahe am Limit zu operieren, von den Kosten aufgrund der riesigen Chipfläche mal ganz abgesehen.

Pixel- und Vertexshader

Wie in den Spezifikationen schon erwähnt, wird der Vertexshader beim Parhelia nicht weniger als vierfach vorhanden sein, unterstützt durch eine DX8-Blending und Skinning-Einheit, wahrscheinlich ein Überbleibsel aus dem G550 um Software-kompatibel zur eigenen Head-Casting Engine zu bleiben.

Wichtig für DirectX 9 sind vor allem die Programmierbarkeit der Vertex-Shader mit Programmen, die bis zu 256 Instruktionen in einer C-ähnlichen Hochsprache bestehen können. Hier gibt sich Matrox keine Blöße.

Nach der normalen Rendering-Einheit mit jeweils 4 TMUs kommen die Pixelshader, die jeweils pro Pipeline einmal vorhanden sein müssen. Interessant ist jedoch das Konzept, diese bei Bedarf von 5 4-stufigen zu 2 10-stufigen kombinieren zu können. Bekannt ist dieses Vorgehen von frühen Chips mit single-pass Multitexturing, die ebenso ihre Pipelines kombinieren konnten, um somit Multitexturing zu ermöglichen. Das Problem, das analog zu diesen hier auch auftritt ist, dass komplexere Pixelshader-Programme mit mehr als 5 Instruktionen effektiv nur mit der halben Leistung abgearbeitet werden.

Inwiefern sich das negativ auswirken wird, also wie stark sich die Entwickler auf diese längeren Pixelshader-Programme stützen werden, läßt sich derzeit natürlich noch nicht mit Sicherheit sagen.

Sicher ist jedoch, dass Matrox hier weder den für DirectX 9 erforderlichen Pixelshader 2.0 noch den schon länger bekannten Pixelshader 1.4, wie er bereits in der ATi Radeon8500 enthalten ist und der damit kaum noch auf weitere Verbreitung hoffen kann, mit eingebaut hat. Was in der Hauptsache fehlt, ist die Möglichkeit, abhängige Texturzugriffe und mehr als 4 Texturenaufrufe pro Renderingpass zu verwenden. Warum Matrox so entschieden hat, darüber haben wir schon ein wenig spekuliert aber definitiv läßt sich dazu noch nichts sagen, außer Matrox sieht den Parhelia vorerst nur als Machbarkeitsstudie für ein folgendes, voll DirectX 9 kompatibles Produkt an.

Speicheranbindung

Hier noch einmal zur Verdeutlichung das Speicherinterface im direkten Vergleich zu denen der aktuellen Konkurrenz.

Auch hier wird deutlich, dass Matrox auf rohe Gewalt setzt, denn aus der Featureliste und dem Blockdiagramm lassen sich keinerlei Bandbreitenschonende Maßnahmen, wie ATis Hyper-Z oder nVidias LMA erkennen. Ob sich Matrox damit nicht trotz der immensen Rohpower ein Kuckucksei ins Nest hat legen lassen, bleibt natürlich abzuwarten, aber gerade angesichts der Effizienz der Tricks von ATi und (zumindest in diesem Falle) besonders nVidia scheint das keine allzu kluge Entscheidung gewesen zu sein.

Erinnern wir uns, allein durch die Aufspaltung des 128Bit-DDR Memory-Controllers in vier kleine 32Bit-Controller gewinnt man bei nVidia teilweise sehr deutlich an Leistung hinzu. Das läßt den Schluß zu, dass an der Behauptung, die meiste Bandbreite werde durch nicht vollständig ausgenutzte Speicherzugriffe verschwendet, durchaus etwas Wahres dran ist und mit einem doppelt so breiten Interface würde dieser verschwendete Prozentsatz sicher nicht abnehmen, eher im Gegenteil.

Im Lichte der für eine GPU dieser Komplexität geradezu spartanisch anmutenden 80 Millionen Transistoren ist es auch zu bezweifeln, das man bei Matrox diesen Mangel durch große Chipinterne Caches wird kompensieren können, für die wohl kaum genügend Fläche vorhanden sein würde.
Update: Ein einziger Punkt deutet allerdings entgegen unserer ursprünglichen Behauptung doch auf das Vorhandensein eines effizienten Speichercontrollers hin. Dies findet sich im Blockdiagramm in dem grünen Balken oberhalb des vierfachen Vertexshader und wird als "8 way parallel DMA Engine" bezeichnet. Wollen wir um Matrox' Willen hoffen, dass unser erstes Urteil doch ein wenig zu Vorschnell war!