double in shader und texture

[Mirror]

Hallo,


ich wollte mal fragen, ob es irgendwie möglich ist in Shadern und Texturen den Datentype double zu verwenden ? Ich bräuchte es für ein zukünftiges Projekt. Möglichst für DirectX 11 oder 12. CUDA wäre aber auch im Rahmen des Möglichen...

[Krishty]

In HLSL (Shader Model 5) kannst du double als Datentyp nutzen. Geh sicher, bei Konstanten das Suffix L einzusetzen. Division ist leider ein optionales Feature.

Doubles in Texturen kenne ich nicht. In D3D 11 musst du wahrscheinlich zwei uint32-Texturen lesen, um daraus 64-Bit-Werte zusammenzubauen. D3D 12 kA.

Auch das Schreiben von double in Render Targets ist nicht möglich. Notfalls die Bits extrahieren und in zwei uint32-Render-Targets schreiben. Blending ist dann natürlich unmöglich.

Letztlich musst du noch prüfen, ob deine GPU double unterstützt, da es eine optionale Erweiterung ist. D3D 11 hat eine Funktion dafür: https://learn.microsoft.com/en-us/windo ... r-programs

[Mirror]

Wie immer eine kompetente Antwort. Danke das hilft mir schon weiter. Ich werde wohl per Bit-Artithemtic mir die Datentypen zusammen basteln müssen. Da die Grafikkarten heutzutage übe eine Menge an Shadern-Einheiten verfügen, wäre der Performance-Gewinn schon auf meiner Seite.

[Matthias Gubisch]

In Vulkan/GLSL hab ich das so geloest:
VK_FORMAT_R32G32_UINT als Textureformat und dann im shader

(un)packDouble2x32

Funktioniert im ComputeShader einwandfrei.

Bin mir sicher fuer DX12/HLSL gibt es da entsprechende Formate/Methoden. Manuelle Bitarithmetik sollte also nicht notwendig sein.

[Mirror]

Du hast Recht. Es gibt die asuint-Funktion und sicherlich auch eine entsprechende Gegenfunktion. Danke für den Hinweis, damit erspare ich mir die Bitarithmetik wie Du schon schreibst. Das wird aber erst nächstes Jahr wichtig.

https://learn.microsoft.com/de-de/windo ... lsl/asuint

Danke für den Hinweis.

[dot]

ich wollte mal fragen, ob es irgendwie möglich ist in Shadern und Texturen den Datentype double zu verwenden ? Ich bräuchte es für ein zukünftiges Projekt. Möglichst für DirectX 11 oder 12. CUDA wäre aber auch im Rahmen des Möglichen...

Können? Unter Umständen ja. Aber das willst du nicht. Außer du programmierst für eine Datacenter oder Workstation GPU. Bei Consumer GPUs werden in der Regel wenn überhaupt dann nur der Vollständigkeit halber ein paar einsame FP64 ALUs so drübergestreut. Eine RTX 4090 macht dir beispielsweise pro Clockcycle entweder 65536 float multiply-adds oder 1024 double multiply-adds… 73 TFLOPS für float vs 1 TFLOP für double… (siehe auch https://docs.nvidia.com/cuda/cuda-c-pro ... structions)

In CUDA C++ willst du z.B. bei floating-point Literalen sehr aufpassen, dass du nicht das f vergisst und den Compiler dadurch versehentlich zwingst, alle Zwischenergebnisse in double zu berechnen. Ich hatte schon Beispiele wo man aus einer 42.0 eine 42.0f macht und dann läuft auf einmal alles um ca. Faktor 100 schneller (kein Scherz)…

[Mirror]

Ich will nicht, aber ich brauche für den Algorithmus diese Genauigkeit. Ist natürlich sehr schade das die Leistung dann derart in die Kniee geht.

Edit: Naja, ich kann ja auch erst mal mit float probieren. Viellicht reicht es ja doch. Aber klassischer Weise wird der Algo mit double berechnet.

[TomasRiker]

Magst du vielleicht verraten, was für ein Algorithmus das ist?

PS: Es gibt etwas namens "Double Double arithmetic" - ein "Trick", um die Genauigkeit von Floating Point-Berechnungen zu verdoppeln. Das Prinzip müsste eigentlich auch mit 2x float32 funktionieren.

[Alexander Kornrumpf]

Ich habe in den Anfangszeiten von CUDA mal gute Erfahrung mit https://en.wikipedia.org/wiki/Kahan_summation_algorithm gemacht, falls es um Addition geht.

[dot]

Ich will nicht, aber ich brauche für den Algorithmus diese Genauigkeit. Ist natürlich sehr schade das die Leistung dann derart in die Kniee geht.

Beachte, dass die FP64 performance da in etwa gleichauf mit einer modernen CPU ist. Die GPU zu verwenden ist in der Regel mit etwas Overhead verbunden und macht den Code um einiges komplexer, ist also in der Regel erst sinnvoll, wenn ein ausreichend hoher Speedup zu erwarten ist. Sofern du also nicht mit Workstation oder Datacenter GPUs arbeitest und FP64 wirklich benötigst, bist du vermutlich besser beraten, das Ganze einfach auf der CPU zu machen…

[Mirror]

Beachte, dass die FP64 performance da in etwa gleichauf mit einer modernen CPU ist. Die GPU zu verwenden ist in der Regel mit etwas Overhead verbunden und macht den Code um einiges komplexer, ist also in der Regel erst sinnvoll wenn ein ausreichend hoher Speedup zu erwarten ist. Sofern du also nicht mit Workstation oder Datacenter GPUs arbeitest, bist du vermutlich besser beraten, das Ganze einfach auf der CPU zu machen…

Vielleicht hast Du Recht. Normalerweise wird das was ich da machen will auf besonderen GPU's gemacht. Mein Bruder ist in der Bildberechnung von CT's und dort haben Sie andere Grafikkarten als sie normalerweise im PC sind. Ich schreibe sowieso erst eine CPU Version. Ich weis auch gar nicht ob die Idee zielführend ist. Mein Bruder verrät nicht wie das funktioniert.


@Alexander Kornrumpf:

Leider habe ich alle möglichen Berechnungen drin. Summation reicht leider nicht. Aber trotzdem Danke. Man weis ja nie ob man das mal braucht.

@TomasRiker:

Es ist ein Gradientenabstiegsverfahren mit dem ich tausende und deutlich mehr an Daten habe. Deshalb brauche ich diese Genauigkeit.