Logarithmischer Depth Buffer

[Krishty]

Das zeigt, dass es technisch möglich ist, die 24 ungenutzten Bits intern zu ignorieren. Dann würde es mich wundern, wenn Nvidia es nicht täte.

[Niki]

So... habe nun den Reversed Depth Buffer mit D32_FLOAT_S8X24_UINT richtig eingebaut. Klar, das ich in meinem ersten Versuch nichts gesehen habe, weil ich von LessEqual auf Greater, anstelle von Equal, gewechselt hatte. Das ist natürlich ein Problem wenn man einen Depth-Pre-Pass hat. Über den tatsächlichen Speicherverbrauch auf meiner nVidia GTX 590 kann ich nichts sagen. Performance-technisch merke ich jedoch keinen Unterschied. Ich denke ich lasse das jetzt einfach so.

[glassbear]

P.S.: Es ist eine Pest, dass diese Dokumente alle im PowerPoint-Format vorliegen. Echt mal, WTF?! Dass OpenOffice fürn Arsch ist weiß ich ja, aber zumindest PDF als de-facto-Standard könnte man benutzen …

Und OpenOffice kann die PPSX-Datei scheinbar nicht öffnen, weshalb ich das nicht lesen kann ohne erst einen PowerPoint-Viewer zu installieren. Werde ich wohl nachher tun.

Vielleicht mal ein Update davon machen. Hier oeffnet LibreOffice das alles problemlos :!:

[eXile]

Bevor ihr alle losrennt, und eure z-Buffer umstellt: Der konservative depth output reaktiviert nur die Hierarchical-Z-, nicht aber Early-Z-Optimierungen. [...] Um diesen Post noch etwas mit interessanten Sachen zu unterfuttern:[...]

Woher kommt das?

Dass der konservative depth output nicht die Early-Z-Optimierungen reaktiviert, liegt daran, dass man die Tiefenwerte im Pixelshader beliebig setzen kann, solange man die konservativen Bedingungen (beispielsweise SV_DEPTH_GREATER_EQUAL) einhält; ein Late-Z-Test ist somit immer notwendig, und ein Early-Z-Test könnte im Allgemeinen falsche Ergebnisse liefern.

Wo liegt der Unterschied zwischen Z-Cull und Early Depth?

Ich glaube, Z-Cull ist Nvidia-Slang (grün) für AMDs Hi-Z (rot). Ich hatte leider vergessen, die Quelle anzugeben. Siehe Krishtys Post. Auch noch einmal Dank dafür.

Wieso benutzen die bei UAVs und/oder konservativen Tiefen kein [earlydepthstencil]?

Kann man. Deswegen steht [earlydepthstencil] auch in einer anderen Zeile, nämlich über der Zeile, in welcher UAVs oder konservativer depth output angegeben sind. Wenn man [earlydepthstencil] angibt, landet man in jedem Falle ganz links.

Wieso nutzen die ausgerechnet im Standardfall [earlydepthstencil], wo ich eine Erkennung desselben vollautomatisch erwarten würde? Beziehen die sich ausgerechnet da auf Stenciloperationen?!

Nein, Zeilenumbrüche in den Zellen der Abbildung sind als logische Oder-Operation zu deuten. ;)

Die Frage ist eher, warum da ein „opaque primitves“ ganz links steht; das ergibt nun wirklich einfach keinen Sinn. :)

[CodingCat]

Dass der konservative depth output nicht die Early-Z-Optimierungen reaktiviert, liegt daran, dass man die Tiefenwerte im Pixelshader beliebig setzen kann, solange man die konservativen Bedingungen (beispielsweise SV_DEPTH_GREATER_EQUAL) einhält; ein Late-Z-Test ist somit immer notwendig, und ein Early-Z-Test könnte im Allgemeinen falsche Ergebnisse liefern.

Dass ein Late-Z-Test zusätzlich erforderlich ist, ist klar. Aber die konservative Bedingung wird doch genau dafür aufgestellt, dass durch die Bedingung definitiv verdeckte Geometrie bereits im Vorhinein ausgeschlossen werden kann. Eine Early-Z-Optimierung zusätzlich zum Late-Z-Test würde im Allgemeinen jedenfalls keine Fragmente fälschlicherweise ausschließen. Insofern erschließt sich mir der Aussagegehalt eines "deaktivierten Early-Z" nicht ganz - mir scheint eher, hier fliegen willkürlich gewählte Marketingbegriffe durcheinander, bei denen die Bedeutung überhaupt nicht mehr klar ist. Was sollten konservative Tiefen anderes bringen als ein vorzeitiges Ausschließen von Sichtbarkeit; unabhängig davon, ob es nun Hi-Z/Z-Cull oder Early-Z heißt?

Nachtrag: Dieses ATI-Papier kontrastiert Hi-Z und Early-Z als Low-Resolution-Tiled-Early-Z-Culling (hierarchischer Min-/Max-Buffer) und pixelgenauen Early-Z-Test, respektive. Verknüpft mit der von eXile exzerpierten Grafik heißt das wohl, dass ein pixelgenauer Early-Z-Test bei konservativen Tiefen nicht der Mühe wert war und in diesem Fall nur grobes tile-basiertes Early-Z-Culling durchgeführt wird.

Nachtrag 2: Jetzt habe ich auch endlich die entsprechende Quell-Powerpoint-Präsentation gesehen, die dies bestätigt. Mein Hauptproblem mit derlei Präsentationen ist übrigens nicht das Dateiformat, sondern die unglaubliche Streueung derselben sowie die oftmals extrem knappen und nichtssagenden Stichworte, nicht selten ohne jede weitere Erläuterung in den Notizen.

[CodingCat]

Ich benutze zwar Direct3D, aber es sieht wohl so aus, dass ein Vertauschen der Planes in OpenGL nix bringt, da -w < z < +w. Also ist die logarithmische Variante für OpenGL-User wohl die einzige Wahl, sofern man denn eine solche Wahl überhaupt treffen muss.

Die Clip Spaces sehen je nach API zwar leicht unterschiedlich aus, dennoch funktionieren beide analog. Bei OpenGl folgt nach der Projektion eben noch ein typisches Bias der Tiefenwerte von [-1, 1] auf [0, 1]. Tatsächlich erlaubt glDepthRange in der aktuellen OpenGl-API wie es aussieht sogar ein direktes Umkehren des Tiefenpuffers per State, ohne sonstige Eingriffe in den Render-Ablauf.

[eXile]

Eine Early-Z-Optimierung zusätzlich zum Late-Z-Test würde im Allgemeinen jedenfalls keine Fragmente fälschlicherweise ausschließen.

Ich glaube dann reden wir über unterschiedliche Dinge. So wie ich es verstanden habe, gibt es die ganzen drei Optimierungen (aus erstens Hi-Z/ZCull, zweitens early z-test und drittens late z-test) einmal als Test mit dem bestehenden Depth-Buffer, und einmal die letzten beiden (early z-test und late z-test) als Test mit anderen Fragmente "in flight" eines Pixels, der gerade berechnet wird. Beim ersten (dem Test mit dem Depth-Buffer) gibt es keine Probleme, da stimme ich dir voll und ganz zu. Beim zweiten (Test der in flight fragments) kann es sehr wohl Probleme geben. Wenn wir beispielsweise einen Pixel haben, auf dem zwei Fragmente gerade berechnet werden, und SV_DEPTH_GREATER_EQUAL annehmen, sieht die Situation ungefähr so aus:



A-priori kennen wir nur die iDepths und nicht die oDepths. Wir können keine der beiden Fragmente, die sich in-flight befinden, ausschließen, bevor wir nicht ihre oDepths kennen. D.h. der early z-test ist tatsächlich für die in-flight Fragments trotz konservativen depth output nicht zu gebrauchen, was sich mit der gleich folgenden Aussage „Because it relies on knowing actual fragment depth“ decken würde.

Nachtrag 2: Jetzt habe ich auch endlich die entsprechende Quell-Powerpoint-Präsentation gesehen, die dies bestätigt. Mein Hauptproblem mit derlei Präsentationen ist übrigens nicht das Dateiformat, sondern die unglaubliche Streueung derselben sowie die oftmals extrem knappen und nichtssagenden Stichworte, nicht selten ohne jede weitere Erläuterung in den Notizen.

Ja, diese Probleme habe ich auch. Aber wo deutet die Präsentation deren Faulheit Weglassen von Transistor-verschwendenden Tests an?

Ich habe nur gefunden:

• DX11 supports conservative depth output
• Allows programmer to specify that depth output will only be GREATEREQUAL or LESSEQUAL than current depth buffer depth
  • E.g. geometric decals, depth conversion etc.
• In this case EarlyZ is still disabled
  • Because it relies on knowing actual fragment depth
• But Hi-Z/ZCull can be leveraged for early acceptance or rejection

zusammen mit dem echt Bände sprechenden Kommentar „Conservative oDepth not well documented in DX11 API.“

So wie fast alles in der Computergraphik: Sobald man ins Metall schauen muss, ist alles ein rumstochern im Nebel. :?

Nachtrag: Erbitte Abtrennung der Posts durch Moderator. :3

Nachtrag: Für jeden, der hier tatsächlich PowerPoint benutzt: Man kann diese komischen PPSX-Dateien anständig anzeigen, indem man PowerPoint manuell startet, und dann Datei→Öffnen… wählt.

[Schrompf]

Ist abgetrennt ab Nikis initialem Freudenausruf. Den und den Folgebeitrag kopiere ich jetzt aber irgendwie nochmal in den Anti-Jammer-Thread rüber, sobald ich raushabe, ob und wie das geht.

[CodingCat]

So wie ich es verstanden habe, gibt es die ganzen drei Optimierungen (aus erstens Hi-Z/ZCull, zweitens early z-test und drittens late z-test) einmal als Test mit dem bestehenden Depth-Buffer, und einmal die letzten beiden (early z-test und late z-test) als Test mit anderen Fragmente "in flight" eines Pixels, der gerade berechnet wird.

Gibt es denn Anlass zur Vermutung, dass Pixel in-flight gegeneinander getestet werden? Von sowas habe ich bisher nirgends gelesen, habe mich allerdings auch nicht im Detail damit beschäftigt. Bisher ging ich davon aus, dass alle Tiefentests immer "atomar" gegen den bestehenden Z-Buffer stattfänden (atomar in dem Sinne, dass derlei Operationen pro Pixel sequenzialisiert würden).

Beim ersten (dem Test mit dem Depth-Buffer) gibt es keine Probleme, da stimme ich dir voll und ganz zu. Beim zweiten (Test der in flight fragments) kann es sehr wohl Probleme geben. Wenn wir beispielsweise einen Pixel haben, auf dem zwei Fragmente gerade berechnet werden, und SV_DEPTH_GREATER_EQUAL annehmen, sieht die Situation ungefähr so aus: [...]

Gegen vorläufige Tiefen in-flight zu testen ist ohne Frage unsinnig. Rein theoretisch weniger unsinnig wäre hingegen, konservative Eingabetiefen auch pixelweise gegen den bestehenden Tiefenpuffer zu testen ...

Ja, diese Probleme habe ich auch. Aber wo deutet die Präsentation deren Faulheit Weglassen von Transistor-verschwendenden Tests an?

... sofern es die Hardware zuließe und dies auch in der Praxis Gewinn brächte. Momentan wird nach Präsentation auf diese Weise nur das grobe Z-Culling vorgeschaltet, mehr findet sich dort dazu auch nicht.

[eXile]

Gibt es denn Anlass zur Vermutung, dass Pixel in-flight gegeneinander getestet werden? Von sowas habe ich bisher nirgends gelesen, habe mich allerdings auch nicht im Detail damit beschäftigt. Bisher ging ich davon aus, dass alle Tiefentests immer "atomar" gegen den bestehenden Z-Buffer stattfänden (atomar in dem Sinne, dass derlei Operationen pro Pixel sequenzialisiert würden).

Tja, da kann ich auch mit keiner Quelle antworten.

Moral von der Geschicht: Der Hierarchical-Z-Test Early-Z-Test ist bei konservativen Depth-Output deaktiviert (sagen die Slides), die Begründungen, warum das so ist, ergeben keinen Sinn, und es sind keine Gründe ersichtlich, warum man ihn nicht aktivieren könnte. ¯\_(ツ)_/¯

[CodingCat]

Moral von der Geschicht: Der Hierarchical-Z-Test ist bei konservativen Depth-Output deaktiviert (sagen die Slides), die Begründungen, warum das so ist, ergeben keinen Sinn, und es sind keine Gründe ersichtlich, warum man ihn nicht aktivieren könnte. ¯\_(ツ)_/¯

WAAS? Soweit gehen doch nicht mal die Slides, Hi-Z/Z-Cull ist laut Slides bei konservativem Depth-Output nach wie vor aktiviert. ;) Ganz sicher deaktiviert ist hingegen offensichtlich der pixelweise Early-Z-Test, d.h. Early-Z-Rejection passiert mit konservativem Depth-Output nur grob auf Tile-Basis.

[eXile]

Öhm, ja, genau das meinte ich. Sorry. Bin mal wieder durch den Wind und habs korrigiert. :oops:

[Krishty]

Die Erklärung wird ganz einfach sein:

Optimiert wird nur, was jeder macht.

Es gibt ganz ganz viele ganz ganz kluge Techniken mit denen sich Sachen klüger lösen lassen als bisher. Aber die sind trotzdem langsamer. Weil die Hersteller nur DIE Sachen optimieren, die OFT benutzt werden. Weil man begrenzte Ressourcen hat und nicht aus jeder Pipeline-Nische in jeder Situation alles rausholen kann sondern für häufige Situationen optimiert.

Conservative Z wird nicht oft benutzt. Es ist nicht einmal offiziell dokumentiert. Darum ist es langsam. So einfach ist das.

Egal, welche Gründe ihr dagegen findet. Weil die Welt ein Haufen Scheiße ist in dem gute Absichten und noch bessere Gründe einen Dreck bedeuten.