ATi Radeon 9000 & 9700 Preview

1. August 2002 / von aths / Seite 3 von 5

   128 Bit floating point Rendering

Man mag sich fragen, wo nach 16- und 32-Bit-Rendering das 64-Bit-Rendering bleibt. Dazu ist zu sagen, dass das 128 Bit Rendering rein intern abläuft. Der Framebuffer bleibt nach wie vor 32-bittig. Im Parhelia-Preview wurde eine neue Aufteilung des 32-Bit-Framebuffers angesprochen, welche eine erhöhte Farbtreue gewährleistet. Allerdings kann dieser spezielle Framebuffer nicht für alles verwendet werden. Doom III beispielsweise muss aus bestimmten Gründen weiterhin bei 8 Bit pro Kanal bleiben, anstatt jede Grundfarbe mit 10 Bit und den Alpha-Kanal mit 2 Bit zu speichern. Die Radeon 9700 unterstützt dieses neue Framebuffer-Format wie jede andere zukünftige DirectX9-Karte natürlich auch.

Die Radeon 9700 ist nun der erste floating point Renderer im Consumer Markt. Was bringt floating point gegenüber dem alten fix point (Integer) Verfahren? Bislang wurden die Farbkanäle linear quantisiert. Das bedeutet, dass der Bereich von 0 - 100% Intensität einfach in z.B. 256 gleich große Abschnitte unterteilt wurde. Das ist zwar hardwareseitig sehr einfach zu realisieren, birgt aber eine Menge Nachteile in sich. Um das begreifbar zu machen, möchten wir uns einmal vom Rendering lösen:

Und uns dem Geld zuwenden! Die €uro-Staffelung geht ja so: 1-2-5-10-20-50 Cent und 1-2-5-10-20-50-100-200-500 €uro. Es gibt Münzen und Scheine zusammengerechnet 15 unterschiedliche Geld-Einheiten, Die größte davon ist 500 €uro. Angenommen, wir legen fest, dass die gleiche Anzahl (15) an Geldeinheiten linear gestückelt werden muß: Dann wäre die kleinste Einheit 33,33 €uro. Das bringt natürlich gewaltige Probleme, da man bei jedem kleinen Einkauf immer mindestens 33,33 €uro oder bei großen Einkäufen immer ein exaktes Vielfaches von 33,33 €uro löhnen muß :-). Ein anderer Weg wäre, einfach eine kleinere Geldeinheit als Mindestgröße zu nehmen, bei immer noch gleicher Anzahl an insgesamten Geldeinheiten (15): Gehen wir hier von 10 Cent aus, damit auch kleine Beträge zahlbar bleiben. Dann betrüge der Wert des höchsten Geldstückes (15 insgesamt) aber gerade einmal 1,50 €uro. Bei größeren Einkäufen müsste man säckeweise Geld mitführen, um die ganzen Eineinhalb-€uro-Einheiten bei sich zu haben. Es ist leicht zu sehen, dass eine lineare Aufteilung generell bestimmte Nachteile hat. Der letzte Weg wäre nun, einfach extrem viele Geldeinheiten einzuführen, beispielsweise 0,10 bis 100 €uro in 10-Cent-Schritten. Doch das würde für unser Grafikkarten-Beispiel ja bedeuten, mit einer extrem hohen Bittiefe rechnen zu müssen - weit über 128 Bit. Nun besteht aber beim Geld die Möglichkeit, einen Wert mit mehreren Scheinen und Münzen zu bezahlen. Für die Grafikkarte kann ein Grundfarb-Wert aber mit natürlich nur einer einzigen Zahl dargestellt werden. Nehmen wir der Einfachheit halber an, dass die Grafikkarte jede Grundfarben-Intensität gerundet auf ein volles Prozent auflöst, so dass wir 101 Zustände (0 - 100%) haben. Wenn nun die Intensität von 1,3% dargestellt werden soll, muss auf 1% gerundet werden. Um die Intensität von 50,3% darzustellen, muss auf 50% gerundet werden. Das Problem: Im ersten Beispiel beträgt die Abweichung immerhin relative 23% (1,3 zu 1,0), während im zweiten Beispiel die Intensität nur noch relative 1,2% (50,3 zu 50,0) verfälscht wird. Eine Verfälschung dieser Art nennt man übrigens auch Quantisierungsfehler. Mit anderen Worten behandeln herkömmliche Grafikkarten die kleinen Werte viel ungerechter als die großen Werte. Je kleiner der Wert, desto ungenauer wird gerechnet.

Besonders problematisch wird das, weil oft multiplikative Blending-Operationen durchgeführt werden, wobei mit einer Zahl kleiner 1 multipliziert wird. Das Ergebnis wird also im Endeffekt kleiner - und damit ungenauer. Es wäre günstiger, wenn die kleinen Werte geringere Abstände zueinander aufweisen würden, als die großen - ähnlich den Geldstücken, wo die Abstände auch immer kleiner werden, je geringer der Betrag wird. Dann würde bei geeigneter Aufteilung der Quantisierungsfehler gleichmäßig auf alle Intensitäten verteilt. Es gäbe weniger "Ungerechtigkeit", was sich in erhöhter Farbtreue zeigen würde - und hier setzt das floating point Format an.

Das floating point Format ist abgesehen vom Vorzeichen aus zwei Angaben zusammengesetzt, nämlich Exponent und Mantisse. Wir möchten hier keine große Numerik betreiben, sondern nun beschreiben, wie sich dies letztlich auswirkt: Während das fix point Format im gesamten Bereich gleich große Abstände zwischen den einzelnen diskreten Werten aufweist, liefert das floating point Format stufenweise größerwerdende Abstände (der Exponent gibt den Bereich an, die Mantisse die Stelle im selektierten Bereich). Der Quantisierungsfehler wird so zwar nicht vollkommen gleichmäßig, aber jedenfalls deutlich gleichmäßiger als beim fix point Format auf alle diskreten Werte verteilt.

Allerdings gibt es auch Nachteile: So entsteht z.B. das "Loch um die Null". Das bedeutet, dass der Abstand von der Null zur nächsten darstellbaren Zahl spürbar größer ist als der Abstand von der ersten zur zweiten darstellbaren Zahl. Um diese (und andere) Unzulänglichkeiten auszugleichen, muss die Bittiefe gegenüber fix point erhöht werden. Sinnvoll erscheinen uns beispielsweise 16 Bit pro Kanal (64 Bit insgesamt).

Nun rechnet die Radeon 9700 intern aber schon 32 Bit pro Kanal (128 Bit insgesamt), was erst einmal etwas übertrieben scheint. Allerdings gibt es ja die Möglichkeit, bis zu 8 unterschiedliche Texturen pro Pass, also mit voller interner Rechengenauigkeit, zu verarbeiten. Durch diese hohe Flexibilität können zukünftige DirectX9-Engines wahrscheinlich sowieso alles in einem Pass rendern, ansonsten wird zumindest jede Lichtquelle in einem Pass gerendert. Da diese Ergebnisse dann zum Endpixel nur noch additiv (und nicht multiplikativ) verknüpft werden müssen, macht es sich auch nicht so schlimm bemerkbar, dass der Framebuffer nur fix point Werte speichert.

Als weiland der 32-Bit-Modus eingeführt wurde, konnte man seinerzeit kaum Qualitätsverbesserungen ausmachen. Denn die Texturen enthielten nur Farben aus dem 16-Bit-Farbraum. Zu jenen Zeiten wurde höchstens zweifach texturiert, so dass Colorbanding durch 16 Bit Rendering kaum festzustellen war. Heutzutage kommen bei einigen Spielen bereits so viele Texturschichten zum Einsatz, dass Colorbanding selbst beim 32 Bit Rendering sichtbar wird.

Selbst wenn zunächst weiterhin nur 32-Bit-Texturen eingesetzt werden, so kann 128-Bit-Rendering jedoch schon heute die Grafik verbessern. Richtig sinnvoll wird die neue Rechengenauigkeit aber erst bei 64-Bit-Texturen. Bei der Frage, wie sinnvoll dies nun wieder ist, sollte nicht übersehen werden, dass auch Normalen-Maps als Texturen gespeichert werden. Normalen-Maps kommen beim Bump Mapping zum Einsatz. Die bisherige Auflösung ist jedoch für eine Vielzahl Effekte deutlich zu gering, wie man z.B. bei nVidias Chamäleon-Demo sehen kann:

Aus der Nähe betrachtet arbeitet bisheriges Bump Mapping zu ungenau, weil die Textur-Formate die einzelnen Kanäle zu grob auflösen. Texturen werden auch gerne als so genannte LookUp-Tabellen verwendet, um beispielsweise bestimmte mathematische Funktionen (für PixelShader-Effekte) zu speichern. Hier wirkt sich eine verbesserte Genauigkeit durch 64-Bit-Texturen natürlich ebenfalls aus. Es wird für DirectX9 sogar 128-Bit-Texturen geben, deren praktischen Sinn wir allerdings derzeit noch nicht sehen: Ohne Textur-Kompression sind die Bandbreiten-Anforderungen für diese inakzeptabel groß und mit Textur-Kompression gibt es dann wieder Qualitätsverlust.