Der lange Weg zum HDR-Rendering

1. Januar 2006 / von aths / Seite 3 von 3

   Definition von High Dynamic Range

24 dB für herkömmliches lineares RGB: Das ist, wie schon gesagt, für viele Sachen zu wenig. Für Medium Dynamic Range sollte es schon das Doppelte sein, also 4,8 dB. Für High Dynamic Range dann wiederum das Doppelte, demnach 96 dB.

FX16, also 16 Bit als Festkomma, englisch Fixpoint (oder Integer) ist demnach nur Medium Dynamic Range, MDR. Wie sieht es bei FP16 aus, wobei FP für Floatingpoint (Gleitkomma) steht? Das hängt davon ab, wie das Format implementiert ist. Die DirectX-Spezifikation verlangt folgenden Aufbau: 1 Bit Vorzeichen, 5 Bit Exponent, 10 Bit normalisierte Mantisse. Die Mantisse kann im Extremfall durchweg Nullen enthalten, oder durchweg Einsen. Ihr Wert beträgt demnach 1,0 oder (gerundet) 1,999. Der 5-Bit-Exponent kann 2⁵=32 Werte darstellen, wovon aber zwei Werte für Spezialfälle reserviert sind (nämlich Null und Inf/NaN). Der kleinste Wert ist 1,0 multipliziert mit dem kleinsten Exponenten, der größte Wert ist 1,999 multipliziert mit einem Exponenten, der 2³⁰ mal größer ist. Runden wir die größte darstellbare Mantisse 1,999 auf 2, haben wir eine Dynamik von insgesamt 2³¹=93 dB. Für HDR-Farbe haben wir soeben aber 96 dB definiert.

FP16 laut DirectX-Spezifikation ist für HDR-Farbe also nicht ausreichend. FP-Formate kann man jedoch auch mit Denorm-Support implementieren. Damit ist der kleinste darstellbare Wert (ungleich Null) bei einer 10-Bit-Mantisse um 2¹⁰=1024 mal kleiner, womit die Dynamik um ca. 30 dB zunimmt (Faktor 1000 wären exakt 30 dB). Mit 123 statt 93 dB haben wir das HDR-Kriterium von mindestens 96 dB erfüllt.

Wir wissen nicht genau, welche Karten an welchen Stellen Denorms beim FP16-Format unterstützen. Unser Kenntnisstand ist, dass NV3x beim FP16-Format durchweg Denorms unterstützt, allerdings gibt es bei der GeForceFX auch nur wenige Units, die mit FP16 umgehen können. Beim NV40 ist uns nicht klar, ob das FP16-Blending (was NV3x nicht kann) Denorms berücksichtigt. Beim R520 wissen wir nicht, ob, und wenn ja, welche Einheiten FP16-Denorms unterstützen. Für breitere Formate (FP24, FP32) verzichten die GPU-Entwickler auf jeden Fall auf Denorms, da die Dynamik ohnehin höher und für die gedachten Zwecke völlig ausreichend ist.

Für Pixelshader 2.0 wird mindestens FP24-Genauigkeit verlangt, wobei für FP24 der Exponent 7 Bit breit ist. Die Dynamik beträgt damit 382 dB, selbst ohne Denorm-Support. FP32 auf GPUs bietet dank 8-Bit-Exponent sogar fast 768 dB. Mit Denorms (was laut IEEE 754 Spezifikation auf CPUs unterstützt werden muss) sogar 1219 dB. Für GPUs spielen Denorms, wie schon gesagt, jedoch höchstens beim FP16-Format eine Rolle.

Wie man unschwer erkennt, sind FP-Formate sehr gut geeignet, um aus wenigen Bits eine hohe Dynamik zu zaubern. Doch wie sagt man: There is no lunch for free. Ein vorzeichenloses FP-Format mit 10 Bit ist in gewissen Bereichen schlechter als das Standard-Festkomma-Format mit 8 Bit.

Natürlich ist dann auch FP16 in bestimmten Bereichen schlechter als FX16. Aber für fast alle Zwecke ist das FP-Format besser, meist sogar deutlich. Der einzige Grund, irgendwo nur FX16 und nicht FP16 zu unterstützen, lautet: Man möchte Transistoren sparen. FX16 ist, das kann man drehen und wenden wie man will, nur für MDR-Rendering geeignet. Das ist besser als LDR, aber nicht um Welten.

Drückt man beide Augen zu, kann man auch das "magere" FP16-Format mit nur 93 dB noch als gerade so HDR-tauglich sehen. Allerdings bietet unser menschliches Auge etwa 140 dB, also deutlich mehr. Das "gute" FP16-Format mit Denorm kommt dem dank seiner 123 dB umfassenden Dynamik spürbar näher. Wir sehen, dass bei FP16 nicht Schluss sein wird. Da die von der Grafikkarte gebotene Bandbreite jedoch grundsätzlich ein Flaschenhals ist, dürfte uns FP16 als Textur- und Framebuffer-Format auf längere Sicht erhalten bleiben.

   Welche Grafikkarten können HDR-Rendering?

Da jede DirectX9-Grafikkarte im Pixelshader mindestens FP24-Genauigkeit unterstützen muss, und jede relevante DirectX9-Karte auch FP32-Texturen einlesen kann, ist dynamisches HDR-Rendering im Prinzip auf jeder DirectX9-Karte möglich. Die Frage ist nur, zu welchem Preis. Analysieren wir die Arbeitsschritte:

1. HDR-Eingangsdaten lesen.
2. Eingangsdaten in einem HDR-tauglichen Zahlenformaten verrechnen.
3. Daten im HDR-Format zwischenspeichern.
4. Vom im Schritt 3 angelegten Zwischenspeicher Kenngrößen (z. B. den Mittelwert) feststellen.
5. Die im Schritt 3 angelegten Zwischendaten je nach im Schritt 4 ermittelten Parametern auf ein vom Monitor darstellbares LDR-Format umrechnen.

Bei Schritt 1 ist die Frage, welche Daten in hoher Dynamik vorliegen müssen, konkret ob man auch HDR-Texturen braucht (Vertex-Daten können sowieso in hoher Dynamik angegeben werden, das gilt auch für die beleuchtete Materialfarbe). Sofern man HDR-Texturen braucht, muss man fragen, ob man diese filtern muss. Texturfilterung findet in der TMU statt. Lightmaps sollte man grundsätzlich filtern. Um die Rechenlast zu reduzieren, sollten statische Lichteinflüsse nach wie vor als Lightmap vorliegen. Damit benötigt man für HDR-Rendering also "HDR-TMUs".

Bei 2. haben wir kein Problem, da FP24-Genauigkeit eine für unsere Zwecke extrem hohe Dynamik bietet.

3. ist zunächst unproblematisch, denn ein FP16-Format als Rendertarget bieten alle wichtigen DirectX9-Karten. Wenn es zum Alphablending kommt, müssen natürlich "HDR-Alphablender" vorhanden sein.

4. Zur Mittelwertbildung könnte man die Automipmapping-Funktion der GPU nutzen, welche wiederum auf die bilineare Texturfilterung zurückgreift. Dazu brauchen wir wieder "HDR-TMUs".

5. Das Herunterrechnen von HDR auf LDR, kurz "Tonemapping", könnte mit einer dedizierten Unit gemacht werden – wenn es die denn gäbe. Mangels Tonemapper muss dies im Pixelshader erledigt werden.

NV40 und G70 bieten FP16-TMUs und FP16-Alphablender, R520 bietet nur FP16-Alphablender und die Möglichkeit, Multisampling-Antialiasing zu nutzen.

Kann man auch "HDR-TMUs" und "HDR-Alphablender" im Pixelshader emulieren? Ja. Allerdings kostet dies erheblich Performance. Texturfilterung im Pixelshader kostet mindestens viermal so viele Takte (soweit wir wissen, in der Realität sogar achtmal so viele Takte) verglichen mit "HDR-TMUs". Um Alphablending nachzustellen, sind umständliche Umkopier-Funktionen notwendig, was die Leistung ebenfalls drückt.

Uns interessiert primär, welche Karten zu HDR-Rendering in Echtzeit fähig sind. Spielt Zeit keine Rolle, könnte man schließlich auch die CPU rendern lassen. Um aus dynamischem HDR-Rendering sinnvoll Nutzen zu ziehen, lohnt es nun nicht, LDR-Spiele fix auf HDR-Rendering umzuschreiben. Denn der auf LDR-Rendering optimierte LDR-Content würde ja weiterhin genutzt. Man hätte immerhin reduziertes Colorbanding, aber viel mehr nicht. HDR-Rendering spielt daher primär bei Spielen eine Rolle, die speziell dafür entwickelt werden. Allerdings wird man bei neu entwickelten Spielen allgemein auf Grafikpracht setzen, was die GPU belastet.

   Features? Welche Features?

Vor dem Aufkommen von Pixelshadern sah es so aus: Grafikeffekte benötigten spezielle Einheiten, die bestimmte Features bereitstellten. Von diesem "Das Feature ABC ermöglicht Effekt XYZ"-Denken müssen wir uns jedoch verabschieden. HDR-Rendering ist kein Grafikeffekt, der dank eines speziellen Features ermöglicht wird. HDR-Rendering ist eine vereinheitlichte, gegenüber LDR-Rendering viel genauere Lichtberechnung, die prinzipiell nur wenige (jedoch bereits recht transistorintensive) Features erfordert. Um die GPU genügend zu entlasten, benötigt man dann doch wieder zusätzliche spezielle Units, die Features wie FP16-Blending und FP16-Texturfilterung bereitstellen.

Beim Environmental Bumpmapping nutzte man zu DirectX6- und DirectX7-Zeiten bestimmte Units in den Rechenwerken für Texturoperationen und im Combiner. Seitdem es Pixelshader gibt, wird die Funktionalität dieser Units auf allgemeiner verwendbare Operationen abstrahiert. Das gilt insbesondere ab Pixelshader 1.4, Version 1.1 - 1.3 sind, böse gesagt, nur vereinheitlichte Multitexturing-Setups.

Die Spezialunits, die man heute braucht, um HDR-Rendering effizient und performant zu ermöglichen, wird es früher oder später so nicht mehr geben, da der Chip deren Funktionalität dann in anderen Mehrzweck-Units integriert. Im gewissen Rahmen ist das auch heute schon der Fall: FP16-Texturfilterung und FP16-Blending lassen sich auch zur Beschleuningung von Berechnungen nutzen, die mit Grafik nichts zu tun haben.

Stellt man die Frage "Ist diese und jene Karte für HDR-Rendering" geeignet, kann man angesichts verfügbarer Hardware nicht "ja" oder "nein" antworten. Alle bisherigen GPUs bieten nur eine Teillösung:

• NV40 und G70 bieten vom Featureset her für HDR-Rendering das meiste (der NV40 enthält zudem eine nicht richtig funktionierende, daher deaktivierte Tonemapping-Unit). Die Verwendung von vierkanaligen FP16-Texturen als Eingangsmaterial und Framebuffer-Format zieht natürlich im Vergleich zu FX8 eine verdoppelte Bandbreitenlast nach sich. Damit wird die Framerate bei Verwendung von HDR-Rendering im Vergleich zum LDR-Rendering deutlich gedrückt. Kantenglättung ist schwierig zu realisieren. Das ist inbesondere deshalb tragisch, da HDR-Rendering für bessere Kontraste sorgen sollte – Kantenglättung wäre besonders hilfreich, um den damit deutlicher hervortretenden Treppeneffekt zu vermeiden.

• R520 bietet keine FP16-Texturfilterung, nur FX16-Texturen können in den TMUs gefiltert werden. FX16 ist aber klar nur ein MDR-Format. HDR-Texturen müssten aufwändig im Pixelshader gefiltert werden, wobei bilineare Filterung schon sehr aufwändig, anisotrope Filterung praktisch unmöglich ist. Kantenglättung wird im Prinzip geboten, bishin zu 6x sparse Multisampling. In welcher Endgeschwindigkeit das resultiert, wissen wir noch nicht.

Die erhöhte Bandbreitenlast beim HDR-Rendering kommt vor allem beim Tonemapping zum Tragen. Dass das Schreiben von 64 Bit pro Pixel doppelt so lange dauert wie das Schreiben von 32 Bit pro Pixel, wäre angesichts der vielen Takte, welche die Pixelberechnung ohnehin benötigt, schon fast zu vernachlässigen. Doch zur Umrechnung des HDR-Framebuffers in das Truecolor-LDR-Format sind neben einigen Takten zur Arithemetik-Rechnungen im Pixelshader auch bandbreitenlastige Lese- und Schreibzugriffe in den Grafikkarten-Speicher erforderlich.

Leider ist das "Feature-bringt-Effekt"-Denken noch weit verbreitet. Darauf setzen viele Entwickler, die einen Überstrahl-Effekt implementieren, und das gerne als Effekt der "HDR-Fähigkeit", oder – noch schlimmer – als HDR-Rendering verkaufen. Tatsache ist: Dieser Überstrahl-Effekt ist nicht unbedingt auf echtes HDR-Rendering angewiesen. Beim HDR-Rendering lässt sich zwar auch das Überstrahlen vernünftig integrieren – doch die wahren Vorteile liegen nicht in diesem Blend-Effekt, sondern in der Gewährleistung eines kontrast- und detailreichen Bildes trotz dynamischer Beleuchtung.

Weil es derzeit keine Grafikkarte gibt, deren Leistung bei echtem HDR-Rendering ausreicht, um bei hohen Auflösungen und Nutzung von "Grafikpracht-Effekten" durchweg flüssige Grafik zu bieten, und solche Karten in absehbarer Zukunft zumindest im Massenmarkt-Segment auch nicht zu erwarten sind, bieten aktuelle für HDR-Rendering bekannte Spiele aus Qualitätssicht keine optimale HDR-Rendering-Implementierung. Stattdessen wird getrickst: Lightmaps liegen, wenn überhaupt, bestenfalls als MDR-Format vor, für das Tonemapping wird ein vergleichsweise schnelles aber nicht allzu hochwertiges Verfahren genutzt und so weiter. Obwohl HDR-Rendering für die Qualität ein echtes Plus bedeutet, wird es erst dann "richtig" und vor allem standardmäßig in Spielen genutzt, wenn man für HDR-Rendering brauchbare GPUs auch für andere Zwecke sinnvoll nutzen kann.

Nicht übersehen werden sollte an dieser Stelle das Problem der chipinternen Bandbreite: Der NV40 zum Beispiel zeigt bei Nutzung von Vierkanal-FP16-Formaten einen besonders starken Leistungabfall. Um das aufwändige HDR-Rendering in guten Implementierungen zu ermöglichen, die statt einer begrenzten Auswahl an Effekten durchweg die HDR-Vorteile bringen, muss die Hardware sorgfältig auf die neuen Anforderungen abgestimmt werden. Die für Direct3D 10 gedachten Karten sind zwar per se geeignet für HDR-Rendering – doch können wir nicht nicht davon ausgehen, dass die ersten D3D10-Einsteiger- und Mittelklasse-Lösungen genügend Rohleistung offerieren.

   Ausblick

Um die benötigte Bandbreite zu reduzieren, wird es über kurz oder lang Texturkomprimierungsformate für FP16-Texturen geben. Wenn auch ATI endlich FP16-TMUs bietet und sich Nvidia bequemt hat, FP16-Multisampling zu ermöglichen, und man sich vielleicht dereinst auf die Funktionalität einer Tonemapping-Unit einigt (oder die Pixelshader-Geschwindigkeit weiter verbessert), dann übersteigt die optische Zusatzqualität vom HDR-Rendering den Geschwindigkeitsnachteil im Vergleich zum LDR-Rendering.

In World of Warcraft zum Beispiel wird in der Nacht die Gewöhnung des Auges an die Dunkelheit so simuliert, dass das Bild einfach nicht so dunkel gemacht wird wie es eigentlich sein müsste, und die Farbtönung angepasst (von Sonnengelb ins bläuliche) – doch helle Lichtquellen, wie Lagerfeuer, erscheinen in der Nacht im Vergleich mit der Umgebung nicht so hell, wie sie sein müssten.

Mit "HDR-Rendering" wird oft der modern gewordene Überstrahl-Effekt assoziiert, doch tatsächlich sorgt dynamisches HDR-Rendering für bessere Kontraste und realistischere Helligkeiten, sowie für praktisch Colorbanding-freie Oberflächen. "HDR" für sich genommen sagt gar nichts, und HDR-Rendering ist kein Effekt, sondern das Rechnen mit hoher Genauigkeit und einem großen Wertebereich. Wenn sich HDR-Rendering durchgesetzt hat, wird uns die Beleuchtung in traditionellen LDR-Spielen merkwürdig flach und statisch vorkommen.