Bitboys´ Glaze3D & Avalanche

27. September 2002 / von Leonidas / Seite 4 von 7

   Moderner Glaze3D

Daß es nicht zur Ur-Glaze3D kam, liegt wohl an den Zeitverzögerungen des Projekts und der darauffolgenden Erkenntnis der Bitboys, daß das ursprüngliche Glaze3D-Design sich nicht mehr weit vor allem anderem positionieren kann, so wie dies ursprünglich geplant war. Insbesondere die GeForce1 mit ihrem erstmaligen Einsatz von DDR-RAM läutete eine ganz neue Zeitrechnung bezüglich der Speicherbandbreite ein. Letzteres war jedoch das wohl beste Argument des Ur-Glaze3D und nach dem Release der GeForce1 war die Schlagkräftigkeit dieses Arguments fast schon eingeholt wurden.

So traten denn auch die Bitboys kurz nach der Präsentation der Daten zur GeForce1 ihrerseits im Oktober 1999 mit einem vollkommen neuem Chip-Konzept an. Weiterhin nannte sich der Chip "Glaze3D", beinhaltete aber so viele Änderungen, daß man richtigerweise von einem eigenen Konzept sprechen muß, zur besseren Unterscheidung von uns "moderner Glaze3D" genannt. Als ursprünglicher Auslieferungstermin für den modernen Glaze3D wurde dabei die erste Hälfte des Jahres 2000 genannt, der Chip wäre also gegen die GeForce2 und die originale Radeon angetreten.

Bot der Ur-Glaze3D noch 2 Rendering-Pipelines mit je 2 Textureneinheiten, sollten es beim modernen Glaze3D dann 4 Rendering-Pipelines mit je 2 Textureneinheiten sein - im übrigen genauso wie bei GeForce2 bis GeForce4 Ti. Mittels eines Chiptaktes von 150 MHz wäre so eine Füllrate von 1200 MTexel/sec bilinear bzw. 600 MTexel/sec trilinear erreichbar gewesen. Allerdings war eine trilineare Texturenfilterung wie schon beim Ur-Glaze3D nicht ohne Leistungsverlust möglich.

Spielte dies beim Ur-Glaze3D wohl noch keine Rolle, so brachte die ATi- und nVidia-Konkurrenz des Jahres 2000 diese Fähigkeit wie selbstverständlich mit. Die Füllrate einer GeForce2 GTS liegt bei bilinearer Filterung bei 1600 MTexel/sec - und bei trilinearer Filterung auf demselben Wert, während der moderne Glaze3D hier nur 600 MTexel/sec hätte bieten können. Daß heißt, trotz daß die Renderingleistung vom Ur-Glaze3D zum modernen Glaze3D klar zunahm, hatten andere Grafikchip-Designer in dieser Zeit schnellere Sprünge hingelegt.

Auch aus diesem Grund wurde der moderne Glaze3D gleich prinzipiell als MultiChip-Design geplant. Schon von Anfang an standen drei Versionen zur Debatte: Glaze3D 1200 mit einem Chip, Glaze3D 2400 mit zwei Chips und Glaze3D 4800 mit 4 Chips. Schon mit der mittleren Version hätten die Bitboys den Nachteil bei der Renderingleistung weitestgehend egalisieren können, die Werte der höchsten Variante Glaze3D 4800 sind so überragend, daß sie erst in diesem Frühling von der GeForce4 Ti4600 egalisiert wurden.

Zu erwähnen wäre zur MultiChip-Technologie der Bitboys noch, daß diese nicht die Nachteile der 3dfx-Lösungen aufweisen sollte. So mußten Texturen im Gegensatz zu 3dfx´ SLI nur einmal gespeichert werden. Bei SLI mußten diese jeweils pro Chip extra gespeichert werden, was sehr viel Speicherplatz unnütz verschwendete. Desweiteren sollten sich die Glaze3D-Chips die Arbeit nicht zeilenweise wie SLI, sondern in Tiles (Kacheln) teilen, womit der Glaze3D inklusive seiner Nachfolger sozusagen einen Tile Based Immediate Renderer darstellt (Tile Based Deferred Renderer = KYRO-Serie).

Der Vorteil dieser Methode wäre gewesen, daß ein hoher Prozentsatz an Dreiecken komplett in den jeweiligen Tiles gelegen hätte, insbesondere bei sehr detaillierter Grafik mit vielen kleinen Dreiecken. Damit wäre auch ein hoher Prozentsatz an Dreiecken ausschließlich in einem Chip eine MultiChip-Verbundes bearbeitet worden. Bei 3dfx´ SLI-Lösung ergibt die zeilenweise Abarbeitung, daß mehr oder weniger jedes Dreieck immer von allen Chips mitberechnet werden muß, was eine wesentlich höhere Ineffektivität dieser Lösung ergab. Einen Nachteil hatte die Glaze3D-Lösung allerdings: Die Geometriedaten mußten für jeden Glaze3D-Chip extra berechnet werden. Hier hatte wieder 3dfx einen Vorteil, da die Geometrie-Berechnung dort nur einmal erledigt werden mußte.

Desweiteren sollten die Rendering-Einheiten die schon vom Ur-Glaze3D bekannten Features 32 Bit Rendering, 32 Bit Z-Buffer, 8 Bit Stencil Buffer, bilinearer und trilinearer Filter (für letzteres werden zwei Rendering-Durchgänge benötigt), AGP-Support, Enviroment BumpMapping und eine Texturengröße von maximal 4096x4096 bieten. Dazu sollte Anti-Aliasing als Supersampling-Variante und unter Ausnutzung eines Accumulation Buffers (wie 3dfx bei der Vooodo5), die Texturenkompression DXTC und 8 Texturen per Pass (Rendering-Durchgang) möglich sein.

Geblieben war die programmierbare Geometrie-Einheit des Ur-Glaze3D, allerdings sollte diese nun in einen extra Chip ausgelagert werden, "Thor" genannt. Gern wurde dieser Geometrie-Einheit in seinerzeitigen Artikeln nur DirectX7-Fähigkeiten zugesprochen, jedoch deuten die damaligen Aussagen der Bitboys-Ingenieure eigentlich klar an, daß diese Geometrie-Einheit mehr als nur festverdrahtete T&L-Funktionen zu leisten imstande sein sollte.

Da auch schon im Pyramid3D und im Ur-Glaze3D wirklich programmierbare Geometrie-Einheiten schlummerten, wird wohl auch der Thor-Chip als programmierbare Einheit geplant gewesen sein. Die Thor-Einheit sollte zudem wahlweise sein - daß heißt, es sollten Glaze3D-Grafikboards mit und ohne Geometrie-Beschleunigung möglich sein, wobei die Thor-Einheit vorzugsweise erst in der größtmöglichen Konfiguration mit 4 Glaze3D-Chips zum Einsatz kommen sollte.