[HLSL] 4x 8-Bit Floating-point in 32Bit kodieren?

[Nasenbaer]

Hi,
auch Speicherplatzgründen würde ich gerne in einer normalen 32 FP-Zahl (bzw. einfach in RAW 32Bit Speicher) 4 floating points speichern. Es gibt ja schon fp16-Zahlen als "half" aber ich denke ich könnte sogar mit der Hälfte auskommen. Sinn dahinter ist, dass ich natürlich Speicher sparen will und die Genuigkeit vollkommen ausreichen würde. Für Berechnungen würde ich die Zahlen dann natürlich erst in fp32 umwandeln damit man die ganze Arithmetik nicht nachbasteln muss diese Umwandlung wäre zur Laufzeit nicht das Problem.


Meine Frage ist jetzt wie man sowas effektiv macht. Mein Idee wäre sich nochmal den IEEE 754 Standard anzuschauen und dann dann in etwas nachzubauen aber halt nur 8 Bit für Exponent und Mantisse zu nutzen. Aber gibt es da nicht vielleicht auch effektive Packing-Strategien oder gar irgendwas halbwegs fertiges?

Jemand ne Idee?

[del_4901]

4x 8bit wird in einem 32bit float wird wohl zu ungenau werden. Den Exponenten kann man nur schlecht wiederverwenden. Aber warum nimmst du kein ARGB8 Target? Was willst du ueberhaupt machen?

[Nasenbaer]

4x 8bit wird in einem 32bit float wird wohl zu ungenau werden. Den Exponenten kann man nur schlecht wiederverwenden. Aber warum nimmst du kein ARGB8 Target? Was willst du ueberhaupt machen?
Ich will die Koeefizienten einer Spline-Interpolation speichern - also 3 floats je Intervall. Ich will davon in etwa 24 dieser Koeffizienten je Vertex speichern. Das wären dann 96 Byte je Vertex. Da die Szene recht groß ist (>> 1 Mio. Vertices), wären locker mehrere hundert MB fällig und das ist zu happig.

EDIT: Mir fiel da gerade DXGI_FORMAT_R11G11B10_FLOAT als Format ein. Die ham ja nen gemeinsamen Expon. und können immerhin 3 floats je 32Bit speichern. Schonmal besser als fp16. Mit den komprimierten Formaten (BC*) kenn ich mich net aus. Brächte das was?

[del_4901]

Ich will die Koeefizienten einer Spline-Interpolation speichern - also 3 floats je Intervall. Ich will davon in etwa 24 dieser Koeffizienten je Vertex speichern. Das wären dann 96 Byte je Vertex. Da die Szene recht groß ist (>> 1 Mio. Vertices), wären locker mehrere hundert MB fällig und das ist zu happig.

EDIT: Mir fiel da gerade DXGI_FORMAT_R11G11B10_FLOAT als Format ein. Die ham ja nen gemeinsamen Expon. und können immerhin 3 floats je 32Bit speichern. Schonmal besser als fp16. Mit den komprimierten Formaten (BC*) kenn ich mich net aus. Brächte das was?
Na immerhin, aber muss es denn unbedingt float sein? Oder weisst du nicht wie gross deine Werte werden koennen? Du kannst dir doch die Standardabweichung ausrechnen und als Parameter mitgeben.

[Nasenbaer]

Ne hab dazu noch keine Erfahrungen gesammelt. Man müsste mal typische Fälle testen und schauen ob sich da ein Trend erkennen lässt. Bisher spielt sich aber alles im Kopf ab. Ich werd vielleicht erstmal die Brute-Force-Speicherfresse-Methode implementieren und später schauen ob RGBE oder halt deine Variante anwendbar sind.

[Trap]

Brauchst du den erweiterten Wertebereich durch die Mantisse*Exponent Darstellung oder einfach nur rationale Zahlen? Das zweite wär durch eine Festkommadarstellung auch sehr gut umsetzbar.

[Nasenbaer]

Brauchst du den erweiterten Wertebereich durch die Mantisse*Exponent Darstellung oder einfach nur rationale Zahlen? Das zweite wär durch eine Festkommadarstellung auch sehr gut umsetzbar.
Das weiß ich ja leider net. Muss das erstmal implementieren und schauen womit ichs so zu tun hab. Hatte gehofft, dass es da was fertiges gibt oder jemand en Paper kennt.
Ne Menge Float-Koeffizienten speichern ist ja nicht unüblich (-> Spherical harmonics).