Das Floating-Point-Format im Detail

Teil 2 von 3 / 8. März 2004 / von aths / Seite 9 von 13

   FP32 aka "Single" - Das Standard-Format  (Forts.)

CPUs, die FP32 nach der IEEE-Definition unterstützen, bieten weitere Feinheiten. So wird intern mit einer breiteren Mantisse gerechnet (dank "hidden bits") und mit einer Hilfe ("sticky bit") die interne Mantisse genauer auf das entgültige gespeicherte Format gerundet. Wenn man zwei Werte verrechnet, muss ja beachtet werden, dass das Komma der beiden Zahlen an jeweils einer unterschiedlichen Position stehen kann. Falls beide Inputs den gleichen Exponenten haben, ergeben sich keine Probleme. Ansonsten muss eine Mantisse vor der Rechnung verschoben werden, und zwar von demjenigen Input, der den kleineren Exponenten hat.

Beim Shiften der Mantisse fallen "hinten" einige Bits praktisch raus. Genauigkeitsverlust ist unvermeidbar, da die Darstellung von größeren Zahlen ja nur möglich ist, in dem die Abstände zwischen den tatsächlich darstellbaren Werte bei größeren Zahlen immer weiter zunehmen. Der absolute Fehler ist bei großen Zahlen demzufolge größer. Ein weiteres Feature ("guard bit") stellt nun sicher, dass, wenn das Ergebnis mit der FP-Zahl exakt dargestellt werden könnte, die Rechnung auch exakt ausgeführt wird. Zusätze Hilfestellung beim Abschneiden der "hidden bits" von der Mantisse leistet dabei ein "round bit".

Es gibt auch weitere Exceptions, zum Beispiel zur Behandlung von Underflows. Natürlich verkompliziert all das die FP-Schaltungen. Wir wissen zwar, dass CineFX nicht zwischen SNaN und QNaN unterscheidet (sondern einfach nur "NaN" kennt, weil das ausreicht). Was wir nicht wissen ist, welche der eben vorgestellten Features unterstützt werden. Man könnte auf sie komplett verzichten, wenn man bereit wäre, einige Ungenauigkeiten zu akzeptieren. Da FP32 auch "pur" von Haus aus sehr genau ist, hat nVidia wahrscheinlich den Transitor sparenden Weg gewählt.

An dieser Stelle eine kurze Bemerkung zum "Inf": In der Mathematik ist x / 0 nicht Inf, sondern nicht definiert. Eine "Mathematiker-Logik" müsste bei 1 / 0 also NaN zurück geben. Man entschied sich bei FP-Logiken jedoch, bei x / 0 den Grenzwert des Ergebnisses als Ergebnis selbst zu nehmen. Ein Mathematiker kann zwar zeigen, dass das zu kurz gegriffen ist und sich logische Widersprüche finden lassen. Aber wir müssen den IEEE-Standard akzeptieren, wie er nun einmal ist. Bei x / 0 ein Inf und kein NaN zurückzugeben, ist für viele numerische Aufgaben eben sinnvoller. 0 / 0 ergibt allerdings das korrekte NaN, da weder das Ergebnis noch der Grenzwert durch eine Zahl oder "∞" sinnvoll dargestellt wäre.

   Welche Zukunft hat FP32?

CineFX-Shader haben fast keine FP16-Units. Gerechnet wird meist direkt mit FP32 (oder eben FX12). Eine Konvertierungs-Stage in der Pipeline wandelt die Werte dann ineinander um. Diese Konvertierung nutzt Denorms für FP16. Das ist sinnvoll, weil FP16-Werte sonst sehr eingeschränkt wären, wenn man sich der Null nähert. Wie bereits besprochen, verzichtet nVidia bei FP32 auf Denorms. Trotzdem kann jedes FP16 bei der Konvertierung zu FP32 wertemäßig unverändert bleiben, Rundungsfehler gibt es nur bei der Rückumwandlung. Denorms und interne FP32-Rechnungen tragen dazu bei, dass der Einsatz von FP16 in vielen Fällen ohne merkliche Genauigkeitsverluste möglich ist.

Zwei Einschränkungen gibt es jedoch: ADD und RSQ (Addition und Reziproke der Quadratwurzel) laufen auf GeForceFX-Karten um so vieles schneller, dass es offenbar eine FP16-ADD-Einheit gibt und RSQ bei FP16-Genauigkeit weniger Takte braucht. Ob auch die FP16-Multiplikation schneller ist, ist derzeit ungeklärt.

Langfristig wird jeder Grafik-Chip durchgehend FP32 anwenden. Das ist mit DirectX Next praktisch unvermeidbar, da es hardwaremäßig dann nur noch "Shader" gibt. Für die Kompatibilität stehen bis zur Version 3.0 scheinbar noch getrennte Pixel- und Vertex-Shader zur Verfügung. Shader 4.0 bei DirectX Next sind dann aber "unified", die bisherige klare Trennung zwischen Vertex- und Pixel-Berechnung wird aufgehoben.

Vertex Shading braucht unbedingt FP32 (da FP24 für Vertex-Daten viel zu ungenau ist). Mit den gleichen Units wird dann auch Pixel Shading erledigt werden - ATIs FP24 stellen insofern eine Zwischenlösung für DirectX9 dar. FP32-Rechenwerke sind deutlich aufwändiger als FP24-Units. FP32-Rechenwerke sind jedoch nicht langsamer als FP24-Werke. Sie benötigen lediglich deutlich mehr Schaltkreise.

Wenn man die Trennung zwischen Pixel- und Vertexshader aufgibt, ist die FP32-Genauigkeit unbedingt erforderlich. Da GeForceFX-Karten ein Feature namens "Render to Vertexbuffer" kennen, brauchen sie FP32-Genauigkeit im Pixelshader schon heute, auch wenn wir "erst" bei DirectX9 sind. FP32 wird wegen der Bedingungen von DirectX Next ab R5XX aber auch in ATI-Chips im Pixel Shader präsent sein. Den Chip-Entwicklern steht damit viel Arbeit ins Haus, derart aufwendige Einheiten in großer Zahl auf der GPU zu platzieren.

Doch nur weil die Zukunft FP32 gehört, wäre es Unsinn, deshalb FP24 schlechtreden zu wollen. Wie man ja in der Praxis sieht, steht ATI mit FP24-Pixelshader-Hardware gut da. Für Vertex Shading und andere Sachen, die wirklich mehr Genauigkeit brauchen, sind natürlich FP32-Einheiten im Radeon-Kern implementiert.

   Einsatzmöglichkeiten von FP32

Die meisten "Allerwelts-Berechnungen", die Floating-Point-Zahlen nutzen, arbeiten mit FP32-Genauigkeit. Im 3D-Bereich spielt das Format aus Performance-Gründen eine besonders große Rolle: Die CPU könnte zwar genauer rechnen, doch wird das in der Regel nicht genutzt, sondern auf FP32-Genauigkeit limitiert. Da das FP32-Format weit verbreitet und "genau genug" ist, nutzen moderne Grafikkarten FP32 für viele Rechnungen, die mit Textur-Koordinaten zu tun haben.

Dazu zählt die perspektivische Korrektur, wie auch die Berechnung der Sampling-Koordinaten beim anisotropen Filtering. Anständiges ansiotropen Filtering ist beispielweise ohne FP32 nicht zu machen. Die noch Fixpoint-basierten AF-Berechnungen von R100 und R200 können daher auch kaum zufriedenstellen. ATIs R300 setzt hier wahrscheinlich auf FP32, nVidia ab der GeForce3 ohnehin. Wir vermuten allerdings, dass GeForce 1/2 und GeForce4 MX eine einfachere Logik für Textur-Zugriffe verwenden, als die nVidia-Chips ab der GeForce3.

Praktisch alle Vertex-Berechnungen (Transformation von Dreiecken, die Beleuchtung usw.) laufen schon jetzt generell mit FP32 - jede T&L-Einheit nutzt durchweg FP32 (DirectX9-Vertex-Shader kennen zusätzlich Integer-Konstanten). Einige Vorarbeiten für die T&L-Einheit muss nach wie vor die CPU übernehmen, welche hierfür ebenfalls auf bewährte Single-Genauigkeit setzt. AMDs erste 3DNow-Version unterstützte überhaupt nur FP32 - gegenüber Intels MMX, welches nur Integer-Zahlen (bis 32 Bit pro Zahl) verstand, war das natürlich ein gewaltiger Fortschritt. In OpenGL kann das Single-Format selbst für Dinge eingesetzt werden, die später von der GPU intern als Fixpoint behandelt werden. Dazu zählen zum Beispiel die Farbwerte für den Framebuffer-Clear.

Auf der PC-Schiene ist die 32 Bit breite "Single"-Genauigkeit im übrigen schon seit dem Intel 8087 verfügbar. Der 8087 ist eine Floating-Point-Unit (FPU), welche seinerzeit separat zu den ersten Intel-Prozessoren angeboten wurde, bevor diese FPU dann mit den 80486er Prozessoren in selbige integriert wurde. Da die FP-Thematik eigentlich aus dem CPU-Bereich kommt, widmen wir uns im nächsten Teil unter anderem speziellen CPU-typischen FP-Formaten. Dort klären wir auch, was der Einsatz von Floating-Point-Formaten uns nun speziell im 3D-Bereich bringt. Und ob es bald Framebuffer geben könnte, die FP-Formate unterstützen.