Depth Buffer mit 64 Bit

[Mirror]

Hallo,

kennt jemand eine Möglichkeit einen Depth Buffer mit 64 Bit unter DirectX 11 oder DirectX 12 anzulegen ?

Geht das überhaupt ?

[gombolo]

ohne jetzt in die Doku zu schauen, aber weil ich mich seit ein paar Wochen mit DirectX11 beschäftige und viel experimentiert habe muss ich sagen ich kenne ich bis jetzt 24Bit und 32Bit Puffer. Wobei ich mich Frage was macht man mit einem 64Bit Puffer?

Weil vielleicht kann man das auch anders Lösen, wenn du eine solche Genauigkeit benötigst.

[TomasRiker]

Ich glaube nicht. Wäre wahrscheinlich auch nutzlos, wenn die GPUs intern mit 32-Bit-Floats rechnen. Dann hättest du nichts von der höheren Genauigkeit.

[Mirror]

Ich kenne auch nur 32 und 24 Bit. Zumindest als DXGI-Format. Deswegen frage ich ja.

Soweit ich weis wird der Depth-Wert in einen 32 oder 24 Bit Integerwert umgerechnet. Ich denke das dadurch viel an Informationen verloren geht. Da der höchste Wert gleich eins gesetzt wird. Hundertprozentig sicher bin ich aber nicht. Hier würde also auch bei 32 Bit-Float auf 64Bit Integer was bringen.

[Krishty]

Ich glaube nicht. Wäre wahrscheinlich auch nutzlos, wenn die GPUs intern mit 32-Bit-Floats rechnen. Dann hättest du nichts von der höheren Genauigkeit.

Genau. Intern wird mit 32-Bit-Gleitkommazahlen gerechnet. Beim Schreiben in DXGI_FORMAT_D32_FLOAT findet im Grunde keine Umrechnung und kein Genauigkeitsverlust statt.

Die meisten Genauigkeitsprobleme entstehen bereits bei der Berechnung – bei der Transformation der Vertex-Koordinaten durch die Projektionsmatrix. Es gibt einige Empfehlungen, wie man die verringern oder sogar zum Vorteil nutzen kann – prominentes Beispiel ist Outerra, die ja quasi die ganze Welt mit 32-Bit-Tiefenpuffer rendern.

Da der höchste Wert gleich eins gesetzt wird. Hundertprozentig sicher bin ich aber nicht.

AFAIK musst du die Far Clipping Plane nicht auf 1 setzen; Unendlich geht bspw. auch.

Ein Bit wird auch durch das Vorzeichen „verschwendet“. OpenGL optimiert das berüchtigterweise dadurch, dass der Clip Space von -1 bis +1 geht. Ich habe noch nie jemand getroffen, der das gut findet – zumal Tricks wie Outerras dann nicht mehr funktionieren. Alle hassen es und nehmen lieber den Verlust des Sign Bits in Kauf.

[Mirror]

Danke Krishty. Wie zauberst Du nur sowas aus dem Ärmel ? Das könnte gehen. Aber auch an die anderen ein Danke.

[Mirror]

Leider hat das nicht die Auswirkungen auf mein Rasterproblem gehabt, wie ich es mir vorgestellt habe. Ich habe deshalb einen neuen Thread aufgemacht.

[Mirror]

Ich glaube nicht. Wäre wahrscheinlich auch nutzlos, wenn die GPUs intern mit 32-Bit-Floats rechnen. Dann hättest du nichts von der höheren Genauigkeit.

Bei CUDA gibt es auch die Möglichkeit 64 Bit ( double ) zu verwenden. Krishty hatte es auch schon mal geschrieben.

[Matthias Gubisch]

Klar können GPUs auch mit 64-Bit Doubles rechnen, sind dann aber entsprechend langsamer.

Native kann DX12 keinen 64Bit Depth buffer, da müsstest du vermutlich schon selber anfangen und die rasterization im compute shader machst.
Dann fällst du aber wieder auf das Problem das 64bit atomics nur sehr sporadisch unterstüzt werden (AFIAK nur für integer)

[Schrompf]

64bit-Atomics gibt's nur für Integer, hab ich auch gehört. Aber das Schöne an IEEE 754 floats ist, dass Gleich, Ungleich und sogar Größer/Kleiner-Tests auch funktionieren, wenn man die Floats bitweise als Integer betrachtet. Min/Max-64-Atomics gehen also auch für Floats :-)

[Krishty]

64bit-Atomics gibt's nur für Integer, hab ich auch gehört. Aber das Schöne an IEEE 754 floats ist, dass Gleich, Ungleich und sogar Größer/Kleiner-Tests auch funktionieren, wenn man die Floats bitweise als Integer betrachtet. Min/Max-64-Atomics gehen also auch für Floats :-)

Das geht aber nur, wenn man nicht 0 überschreitet, denn sonst müsstest du von Sign-Magnitude in Zweierkomplement umrechnen. Damit sind OpenGL-Style-Depth-Buffers (Tiefe -1…+1) raus. Kein Showstopper, sollte man aber von vornherein wissen.

[Schrompf]

Oh stimmt, floats haben ja ein explizites Vorzeichenbit und kein Zweierkomplement. Guter Hinweis!

Öhm... fällt mir gerade so auf: der Unreal-Rasterizer benutzt 64er-Atomics ja, um Tiefe und Farbe race-condition-frei schreiben zu können. Das heißt ja aber auch, dass die nur 32Bit für den Farbwert haben? Wie machen die dann HDR? Irgendsonen Fancy Shared-Exponent-Trick wie HL2 damals?

[Matthias Gubisch]

Öhm... fällt mir gerade so auf: der Unreal-Rasterizer benutzt 64er-Atomics ja, um Tiefe und Farbe race-condition-frei schreiben zu können. Das heißt ja aber auch, dass die nur 32Bit für den Farbwert haben? Wie machen die dann HDR? Irgendsonen Fancy Shared-Exponent-Trick wie HL2 damals?

Hier kann ich helfen
Der Trick ist dass der Unreal Rasterizer gar keine Farbe schreibt sondern eine Triangle ID

Das Ergebnis ist dann ein soganannter VisibilityBuffer mit 32 bit Tiefe in den oberen Bits und 32 Bit Triangle ID in den unteren Bits
Aus der TriangleID lässt sich dann später das tatsächliche Dreieck + Material ableiten welches dann in einem ComputeShader berechnet wird.

Das macht die Szene unabhängiger von der Geometriemenge da im Rasterizerpass der PixelShader minimal ist und nur ein 64Bit wert schreibt (ich weis Unreal hat auch einen ComputeShader Rasterizer aber das Prinzip ist das gleiche)

Später führt man dann einfach für jeden Pixel einen Compute Shader aus.

Ich mache das in meiner Engine zum Beispiel so dass ich einen Radix Sort auf die Materialen mache und mir die PixelCoordinaten speichere und dann jeden Shader entsprechend der Anzahl Pixel starte.

Unreal Started ihre ComputeShader Fullscreen und checkt dann als erstes ob in dem Tile das die aktuelle Gruppe bearbeiten soll das Material überhaupt vorkommt. Wenn nicht wird die Gruppe sofort beendet.

Soweit in kürze, ich kann das gerne mal ausführlicher erklären wenn ich es mal wieder zum Stammtisch schaffe ;)