Grenzen beim 32-Bit-Rendering - und Auswege

4. Januar 2002 / von aths / Seite 2 von 2

   Die Lösungs-Möglichkeiten

Eine TileBased Rendering-Architektur, wie im KYRO-Chip höchst erfolgreich verwirklicht, rendert schon heute grundsätzlich in 32 Bit und hat einen 32-Bit-Framebuffer. Würde man gewisse Datenpfade breiter auslegen, sowie den vorhandenen "RAM on chip" verdoppeln, könnte 64-Bit-Rendering ohne Geschwindigkeits-Verlust realisiert werden. Der Verlust würde sich trotz allem in der Geldbörse bemerkbar machen.

Der Kyro-Chip rechnet heute mit 8-Bit-Genauigkeit pro Kanal. Eine Verdopplung erfordert aufwändigere Logik zur Berechnung. Das verbraucht Schaltkreise und macht den Chip größer. Vom zusätzlichen RAM onchip (!) ganz zu schweigen. Die Anbindung zum Framebuffer müsste doppelt breit ausgelegt werden, was zusätzliche Kosten verursacht. Deshalb wäre zu überlegen, ob man nicht ein paar Bits "irgendwie" einsparen kann.

Gucken wir mal in die Trickkiste: Herkömmliches "16-Bit-Rendering" rendert intern sowieso mit 32 Bit. Lediglich der Framebuffer speichert nur 16 Bit pro Pixel. Um die Darstellung zu verbessern, also Color Banding zu verhindern, wird das Ergebnis häufig gerastert in den Framebuffer geschrieben. Beträgt die "Kommastelle" 0.5, werden abwechselnd die beiden nächstbesten Farben gewählt. Das wäre hier auch denkbar: Intern wird mit 64 Bit gerechnet. Das Ergebnis kommt, gerastert, mit 48 oder sogar nur 32 Bit in den Framebuffer. (Ein nachträglicher Filter könnte dann die Qualität noch etwas verbessern. Jedenfalls kann der Voodoo3-Postfilter sein 16-Bit Bild in gewissen Grenzen verschönern.)

Beim Overbright Lighting wurde für das Vorzeichen ein komplettes Bit verbraten. Anstatt mit 4 Bit den Bereich von -8.0 bis +8.0 abzudecken, könnte man ein Bit einsparen und von -2.0 bis 6.0 rechnen. Es gibt allerdings keine Anzeichen, dass dieses "Biasing" tatsächlich zum Einsatz kommt.

Bislang ging dieser Artikel von einem Datentyp aus, der nur Ganzzahlen (eigentlich Fixkommadarstellung) beherrscht. Mit Floating Point, also Fliesskommazahlen könnte man einen Bereich (auf Kosten eines anderen) viel feiner auflösen. Die Rechenlogik würde zwar verkompliziert. Im Gegenzug käme man vielleicht mit 48 Bit aus, was schmalere Datenpfade erlaubt und an anderer Stelle die Kosten wieder senkt.

Mit DirectX9 besteht die Möglichkeit, durch eine Art "Gamma korrektes Rendering" den Farbraum besser als bisher ausschöpfen zu können. Trotz dieser Vorteile erfordert das aber auch eine hohe Genauigkeit. Hier ist ein Floating Point Datentyp auf jeden Fall von Vorteil.

Um keine Missverständnisse aufkommen zu lassen: Fliesskomma-Farben bringen viele Vor- und einige Nachteile. Die Vorteile scheinen jedoch zu überwiegen, so dass früher oder später sowieso damit zu rechnen ist.

Es ist offensichtlich am einfachsten, zunächst die interne Rechengenauigkeit zu erhöhen. Obwohl der Framebuffer weiterhin 32-bittig bleibt, profitiert man beim Multitexturing schon durch geringere Rundungsfehler. Denn gerundet wird dann erst beim Schreibzugriff auf den Framebuffer. Können mehrere Texturen in einem Pass aufgetragen werden, heisst das ja, diese Zwischendurch-Zugriffe und damit die Zwischendurch-Rundungen einzusparen. In der Tat rechnen alle modernen Chips intern schon genauer. Die Ausnahme ist ausgerechnet der KYRO I/II Chip. Gerade weil er 8x Multitexturing anbietet, würde eine höhere interne Bit-Auflösung sehr nützlich sein. Je mehr Texturen eine Pipeline pro Pass auftragen kann, desto mehr nützt interne höhere Rechengenauigkeit auch, wenn der herkömmliche 32-Bit-Framebuffer zum Einsatz kommt.

Wie man sieht, ist die Frage, ab wann denn nun genau die Grenzen durch 32 Bit sichtbar werden, nicht pauschal zu beantworten. Es hängt davon ab, wieviele Texturen in einem Pass aufgetragen werden können und natürlich wie genau intern gerechnet wird. Bleibt der Framebuffer 32-bittig, nutzt hohe Genauigkeit nichts, wenn nur eine Textur aufgetragen werden kann. Genauso wenig nutzt 8x Multitexturing, wenn die Genauigkeit weiterhin 32-bittig bleibt. (Das gilt nur für die Bildqualität, 8x Multitexturing bringt bei Anwendung spürbare Effizienz-Vorteile.)

Um sowohl Bandbreite als auch Speicherplatz zu sparen, wird sehr wahrscheinlich eine Framebuffer-Komprimierung zum Zuge kommen. David Kirk (er ist Chef-Entwickler bei nVidia) ließ zumindest die Möglichkeit offen, dass der NV20 (GeForce3) das schon heute beherrscht. Von ATi wird für den Radeon8500-Nachfolger ebenso eine Framebuffer-Komprimierung erwartet.

Weil eine Render-Architektur, die das Bild in Tiles (Kacheln) zerlegt, den aktuellen Framebuffer-Ausschnitt komplett im Chip hat, eignet sich dieses Verfahren wieder einmal besonders, um Probleme zu umschiffen. Denn bei einem onchip-RAM ist der Zugriff so schnell, dass eine Komprimierung nicht notwendig wäre.

"Framebuffer-Komprimierung" fasst eine ganze Sammlung an Möglichkeiten zusammen. Schon eine Rundung oder Rasterung von einem 16-16-16 RGB-Format auf 10-12-10 ist streng genommen eine Komprimierung. Das beste wäre, eine verlustlose Methode zu nutzen. Dabei kann allerdings keine bestimmte Komprimierungs-Rate gewährleistet werden. Daher könnte auch eine verlustbehaftete Komprimierung mit konstanter Komprimierungsrate zum Einsatz kommen. Es liessen sich auch bestimmte Eigenschaften der menschlichen Farbwahrnehmung ausnutzen, um keine RGB-Werte, sondern andere Farbformate in den Backbuffer zu schreiben. Die Umrechnung könnte die Hardware in Echtzeit machen. Dabei könnte berücksichtigt werden, dass das Auge viel empfindlicher auf Helligkeits- als auf Farbunterschiede reagiert. Der sichtbare Verlust muss natürlich kleiner sein, als eine Rundung auf das herkömmliche 32-Bit-Format mit sich bringt.

Eine noch aufwändigere Methode wäre, den Framebuffer in Blöcke zu zerteilen. Das bietet sich natürlich ganz besonders bei einem TBR-System (wie z.B. PowerVR- oder Gigapixel-Chips) an. Das würde dann eine erweiterte Komprimierung erlauben, die nicht einzelne Pixel, sondern immer gleich ganze Kacheln komprimiert und dabei aus verschiedene Algorithmen den besten für diese Kachel auswählt. (Ähnlich einer Texturkomprimierung nach FXT1-Standard.) Allerdings ist diese Methode wohl zu aufwändig, als dass sie zum Einsatz kommen wird. (Außerdem haben TBR-Systeme bekanntlich keinen Mangel an Bandbreite zum Framebuffer.)

   Zusammenfassung

32-Bit-Rendering reicht nicht mehr lange aus. Bei der Umstellung des Farbformates ist zu berücksichtigen, dass man Intensitäten > 1.0 handhaben kann. Das Datenformat könnte gleich ein Floating Point Typ sein, weil das mehr Vor- als Nachteile bringt. Der eigentliche Knackpunkt bleibt bei herkömmlicher Render-Architektur die Bandbreite zum Framebuffer. Hier kann eine Komprimierung zumindest mildernd wirken.

Dieser Aufwand für erhöhte Rechengenauigkeit ist nicht nur als Trick zu sehen, um den Kunden teure Spezialhardware zu verkaufen. Schon vor längerer Zeit äußerte sich John Carmack in einer inzwischen berühmten Kolumne, in der er 64 Bit Rendering fordert. Der als Visionär geltende Programmierer möchte in Zukunft viel mehr Texturschichten pro Pixel einsetzen, als heute üblich. Er und andere 3D-Engine-Designer wollen in Zukunft auch viel mehr Transparenz-Effekte verwenden, und mit mehreren farbigen Lichtquellen arbeiten. 32-Bit-Rendering ist hier eindeutig überfordert und liefert zu schlechte Qualität. So schreibt John Carmack davon, dass er bei Tests auf einer GeForce bereits (Color-) Banding sah.

Eine Karte, die erhöhte Rendergenauigkeit bietet sollte über mindestens 128 MB verfügen. Denn spätestens wenn Anti-Aliasing ins Spiel kommt, wird der Platz für Texturen eng.

Bessere Render- oder Raytracing-Software hat sich von 32 Bit längst gelöst und rechnet intern genauer. Das wird auch bald für 3D-Hardware gelten: Die Anforderungen sind gegeben. Statt nur einer Lösung bieten sich, wie so oft, verschiedene Wege an.

(c) aths, 4. Januar 2002. Mehr Texte (nicht nur) von mir auf the attic.