64 Bit Rendering - Sinn oder Unsinn?

26. Juli 2001 / von aths / Seite 2 von 2

Der erste Schritt Richtung 64 Bit ist dabei schon vollzogen: Geforce-Karten rechnen intern mit 36 Bit, Voodoo4/5-Karten mit 40, und der bislang nicht gebaute Rampage mit 52 Bit. Für DirectX werden jetzt schon 48 Bit empfohlen (also 12 je Kanal). Jedoch werden diese 48 Bit bisher von keiner erhältliche Grafikkarte - auch nur in ihrer Pipeline - unterstützt. Zumal das eigentliche Übel nur beseitigt werden kann, wenn der Framebuffer ebenfalls eine entsprechend grössere Breite erhält.

Speicher ist billig, dies sollte auf den ersten Blick nicht das Problem sein. Allerdings nimmt auch die erforderliche Speicherbandbreite zu. Also die Grösse, wieviel Gigabyte pro Sekunde vom lokalen Grafikkarten-RAM zum Grafik-Chip hin- und her übertragen werden müssen. Diese Größe ist bereits heute der Engpass aller Standard-Grafikkarten. Da mit einfacher Verdoppelung der Interface-Breite (von aktuell 128 Bit auf 256 Bit) die Kosten wegen zusätzlichen Pins und Leiterbahnen extrem steigen (und zu allem Unglück auch noch die Effizienz abnimmt) steht eine Lösung hier noch aus. Die Voodoo5 umging das Problem seinerzeit mit zwei getrennten Speicherinterfaces.

Der Rampage, der in einer Dual-Version sowohl auf Multichip als auch auf DDR-RAM setzt, weist vermutlich einen Weg in die richtige Richtung. Zusätzlich wäre hier der Vorteil des unabhängigen RAM-Zugriffs zu nennen. Greift eine der vier Pipelines einer beliebigen Geforce (die MX als Ausnahme hat nur deren zwei) auf den Grafikkarten-RAM zu, können das die anderen Pipelines in diesem Moment nicht. Trennt man hier die Pipelines (Voodoo5: 2 Chips mit je 2 Pipelines) und damit den Zugriff, verkürzen sich diese Wartezeiten. Was sich natürlich positiv auf die Leistung auswirkt, zumal zwei 128-Bit-Interfaces spürbar weniger Füllbytes zu übertragen haben als ein 256 Bit breites. Das ist allerdings damit zu bezahlen, dass alle Texturen (und der Z-Buffer) mehrfach gespeichert sein müssen. Noch dazu muss der Grafikchip MultiChip-fähig sein, dieses wurde dem Endkunden bislang nur bei der Voodoo2, der Rage Fury MaXX und dem VSA-Chip der Voodoo5 ermöglicht.

Doch das Problem einfach mit brutalem Silizium-Einsatz durch mehrere Chips und jeder Menge zusätzlichem Speicher zu lösen, ist letztlich sehr kostenaufwändig. Einfach zwei Grafikchips auf einer Platine zu verbauen, nur, um 64-Bit-Rendering zu ermöglichen, wird den Gamer nicht begeistern. Hardwareseitiges Deferred Rendering für Hidden Surface Removal (KYRO I/II Prinzip: einfach gesagt, entfernen von unsichtbaren Flächen vor dem Rendern), mindert die erforderliche Renderleistung und steigert die Ausbeute pro Hardware-Einsatz erheblich. Es ist offensichtlich, dass bisherige Brute-Force-Renderer, die ja noch immer bei 32 Bit an Leistung verlieren, hier mit ihrem Latein am Ende sind. 64-Bit-Rendering erfordert also in jedem Fall Effizienz steigernde Maßnahmen. Die heutige noch übliche Verschwendung (durch Overdraw, "Übermalen", sind nur ca. 1/3 der berechneten Pixel auch letztlich zu sehen!) kann man sich nicht mehr leisten. Durch hardwareseitiges HSR lässt sich der Overdraw zumindest stark senken, auch wenn er wegen der Transsparenz-Effekte weiterhin eine Rolle spielt.

Vielleicht wird sogar eine Framebuffer-Komprimierung zum Einsatz kommen: Ein Vorbild könnte hier die von ATI mit dem Radeon eingeführte Z-Buffer-Komprimierung sein. Allerdings speichern diese Puffer jeweils völlig anderartig aufgebauten Daten, so dass den Ingenieuren hier noch einiges an Arbeit zur Verbesserung der Komprimierung bevorsteht. Bei Tile-Base-Renderern würde die Komprimierung für die Bandbreite auch wenig bringen, da hier pro Tile ("Kachel") der Framebuffer-Ausschnitt komplett im Chip abgebildet ist.

Zudem waren die HighTech-Grafikkarten schon immer dafür gut, dem Endkunden sehr knappen (und damit teuren) Speicher anzudrehen. Möglicherweise setzen die Hersteller hier lieber weiterhin auf die teuersten Speicher-Bausteine anstatt auf intelligente Techniken (anders kann ich mir den Pro- und Ultra-Wahn nicht erklären: den schnellen Speicher auf den entsprechenden Grafikkarten braucht sonst kein Mensch und wird so mit Marketing unters Volk gebracht). Zum Glück fällt beim Kyro-Konzept sowohl das Problem der Speicherbandbreite bezüglich des Framebuffers weg, ebenfalls das des Z-Buffers (weil der Kyro auch ohne arbeiten kann) - und dank 8-fachem Multitexturing können ohne einen "Speicherzugriff zwischendurch" 8 Texturen aufgetragen werden. Lösungsansätze für das Bandbreiten-Problem sind also so oder so bereits vorhanden.

Doch Bandbreite ist nicht das einzige Problem: Um grosse Texturen in den lokalen RAM zu bekommen, werden sie nach mehr oder weniger guten Verfahren komprimiert. So spart man RAM (und ausserdem Bandbreite, da weniger Daten zu übertragen sind). Im Endeffekt bleibt die Farbauflösung der komprimierten Texturen aber bei 15 oder 16 Bit. Für 64-Bit-Rendering nur 16-Bit-Texturen einzusetzen, ist natürlich nicht befriedigend. Es müssten also neue Texturkompressions-Standards entwickelt werden, die mit 24 Bit Farbtiefe ("Truecolor" bzw. "Echtfarben") speichern.

AGP-Texturing (Abzweigen von RAM als Textur-Speicher für die Grafikkarte) mag neuerdings nicht mehr an der AGP-Bandbreite scheitern. Jedoch muss man auch den vergleichsweise recht langsamen Zugriff auf den Hauptspeicher in Betracht ziehen: Es lohnt einfach nicht, Texturen permanent aus dem RAM zu beziehen, die Wartezeiten sind schlicht zu lang. Der lokale Speicher von 64-Bit-Grafikkarten muss also auf jeden Fall ausreichend dimensioniert sein, wenn keine Leistung verschenkt werden soll. Zum Glück ist nicht davon auszugehen, dass man den RAM verdoppeln muss, um die gleiche Menge Texturen speichern zu können. Denn beim Einsatz von Kompression erhöht sich der Bedarf um weniger als 100%. Dafür muss der interne Textur-Cache auf jeden Fall von der Grösse her verdoppelt werden, um die gleiche Effizienz zu erreichen. Das vergrössert spürbar die DIE-Fläche (die eigentliche Silizium-Fläche im Chip) und ist ein nicht zu unterschätzender Kostenfaktor. Hohe Taktraten erfordern aber kleine Bauweisen und möglichst wenig Layer (Schichten der Logikschaltungen im Chip.) Doch im Zuge der allgemeinen Entwicklung sollte die Verdopplung des Caches, wenn nicht heute, dann eben morgen, kein wirkliches Problem darstellen.

Bei allen technischen Details zu einer 64-Bit-Hardware stellt sich noch immer die Frage: Was haben wir davon? Bei 64 Bit (16 Bit pro Kanal) sinkt der durchschnittliche Rundungsfehler auf gut 0,00076 % ab. Das ist (logischerweise) 256 mal weniger als beim bisherigem 32-Bit-Rendering. Man kann also sehr viel mehr Blend-Operationen und Transparenz-Berechnungen vornehmen, ehe sich der Rundungsfehler so weit aufschaukelt, dass er sichtbar werden würde. Wegen dem fehlenden grossen Qualitätsschub von 16 zu 32 Bit fehlt im Moment allerdings die Akzeptanz, dass 64 Bit über kurz oder lang unausweichlich sind. Das wird sich aber ändern, wenn die Zahl der Texturen pro Dreieck erheblich ansteigt. Bei 400% Vergrösserung kann man bei jedem Spiel die Unterschiede zwischen 16 und 32 Bit erkennen.

Ob man bei heutigen Games 32 Bit von 64 Bit auseinander halten kann, ist jedoch fraglich. Denn auch wenn das Marketing möglicherweise von einer Verdoppelung der Qualität sprechen wird, so ist das eindeutig übertrieben. Dieser Artikel hofft gezeigt zu haben, dass 64 Bit langfristig dennoch seine Daseinsberechtigung haben wird. Obwohl man heute dringender Qualitäts-Steigerung mit besseren Texturfilter-Algorithmen (wie z.B. 128-tap anisotropic filtering) oder natürlich vor allem Anti-Aliasing (also Kantenglättung, je nach Verfahren auch zusätzliche Texturfilterung) nötig hätte.

So ist wohl nicht davon auszugehen, dass sich 64-Bit-Karten schnell durchsetzen werden. Wenn es die ersten zu kaufen gibt, wird man die Spiele, welche dieses unterstützen, noch nicht in nennenswerter Anzahl vorfinden. Noch heute sind teilweise auf 16 Bit beschränkte Grafikkarten im Einsatz, und die Besitzer sind in der Regel noch immer mit diesen zufrieden.

aths, 26. Juli 2001. Mehr Texte (nicht nur) von mir auf www.aths.net/attic.