it-swarm.com.de

Es war einmal, als> schneller war als <... Warten Sie, was?

Ich lese ein tolles OpenGL-Tutorial . Es ist wirklich toll, vertrau mir. Mein aktuelles Thema ist Z-Buffer. Abgesehen von der Erklärung, worum es geht, erwähnt der Autor, dass wir benutzerdefinierte Tiefenprüfungen durchführen können, wie z. B. GL_LESS, GL_ALWAYS usw. Er erklärt auch, dass die tatsächliche Bedeutung von Tiefenwerten (die oberste sind und nicht) angepasst. Verstehe ich soweit. Und dann sagt der Autor etwas Unglaubliches:

Der Bereich zNear kann größer sein als der Bereich zFar; Wenn ja, dann Fensterbereichswerte werden in Bezug auf das, was sie ausmacht, umgekehrt am nächsten oder am weitesten vom Betrachter entfernt.

Früher wurde gesagt, dass der Z-Wert des Fensterraums von 0 am nächsten ist und 1 ist am weitesten entfernt. Wenn jedoch unsere Z-Werte im Clip-Space negiert wurden, wird der Tiefe von 1 wäre der Ansicht am nächsten und die Tiefe von 0 wäre am weitesten. Wenn wir jedoch die Richtung des Tiefentests (GL_LESS zu GL_GREATER usw.) umkehren, erhalten wir exakt dasselbe Ergebnis. Es ist also wirklich nur eine Konvention. In der Tat war das Umdrehen des Vorzeichens von Z und des Tiefentests einmal ein Eine entscheidende Leistungsoptimierung für viele Spiele.

Wenn ich das richtig verstehe, ist das Umkehren des Vorzeichens von Z und des Tiefentests nichts anderes als das Ändern eines <-Vergleichs in einen >-Vergleich. Wenn ich also richtig verstehe und der Autor nicht lügt oder Dinge erfunden hat, wurde < in > geändert, um eine entscheidende Optimierung für viele Spiele zu sein.

Findet der Autor die Dinge, missverstehe ich etwas oder ist es tatsächlich so, dass < einmal langsamer war (vital, wie der Autor sagt) als >?

Vielen Dank, dass Sie diese recht merkwürdige Angelegenheit geklärt haben!

Haftungsausschluss: Ich bin mir bewusst, dass die Algorithmuskomplexität die Hauptquelle für Optimierungen ist. Ich vermute außerdem, dass es heutzutage definitiv keinen Unterschied macht und ich bitte nicht darum, irgendetwas zu optimieren. Ich bin nur extrem schmerzhaft, vielleicht unerbittlich neugierig.

270
Armen Tsirunyan

Wenn ich das richtig verstehe, ist das Umkehren des Vorzeichens von Z und des Tiefentests nichts anderes, als einen Vergleich mit einem Vergleich zu ändern. Wenn ich also richtig verstehe und der Autor nicht lügt oder Dinge erfunden hat, war der Wechsel von <to> für viele Spiele eine entscheidende Optimierung.

Ich habe das nicht besonders gut erklärt, weil es nicht wichtig war. Ich hatte einfach das Gefühl, es wäre eine interessante Kleinigkeit. Ich hatte nicht vor, den Algorithmus speziell zu untersuchen.

Der Kontext ist jedoch der Schlüssel. Ich habe nie gesagt, dass ein Vergleich schneller ist als ein Vergleich. Denken Sie daran: Wir sprechen über Grafik-Hardware-Tiefe-Tests, nicht über Ihre CPU. Nicht operator<.

Ich bezog mich auf eine spezielle alte Optimierung, bei der ein Frame GL_LESS mit einem Bereich von [0, 0,5] verwendet wurde. Nächstes Bild rendern Sie mit GL_GREATER mit einem Bereich von [1.0, 0.5]. Sie gehen hin und her und "wippen" buchstäblich das Vorzeichen von Z und die Tiefenprüfung bei jedem Bild.

Dies verliert ein bisschen Tiefenpräzision, aber Sie mussten den Tiefenpuffer nicht löschen, was früher eine eher langsame Operation war. Da die Tiefenräumung heutzutage nicht nur kostenlos ist, sondern sogar schneller als diese Technik ist, wird dies nicht mehr gemacht.

337
Nicol Bolas

Die Antwort ist fast sicher, dass das Hierarchical Z für jede Inkarnation von Chip + Treiber nur in die eine Richtung arbeitete - dies war früher ein ziemlich häufiges Problem. Low-Level-Assemblierung/Verzweigung hat nichts damit zu tun - Z-Pufferung erfolgt in fester Funktionshardware und wird über Pipelines ausgeführt - es gibt keine Spekulation und somit keine Verzweigungsvorhersage.

3
Crowley9

Eine solche Optimierung beeinträchtigt die Leistung vieler eingebetteter Grafiklösungen, da die Auflösung von Framebuffer weniger effizient ist. Das Löschen eines Puffers ist ein eindeutiges Signal an den Treiber, dass er den Puffer beim Binning nicht speichern und wiederherstellen muss. 

Kleine Hintergrundinformationen: Ein Tiling/Binning-Rasterizer verarbeitet den Bildschirm in einer Anzahl sehr kleiner Kacheln, die in den On-Chip-Speicher passen. Dies reduziert das Schreiben und Lesen in einen externen Speicher, wodurch der Verkehr auf dem Speicherbus reduziert wird. Wenn ein Frame abgeschlossen ist (Swap wird aufgerufen oder FIFOs werden gelöscht, weil sie voll sind, ändern sich Framebuffer-Bindungen usw.), muss der Framebuffer aufgelöst werden. Dies bedeutet, dass jedes Fach nacheinander bearbeitet wird. 

Der Treiber muss davon ausgehen, dass der vorherige Inhalt erhalten bleiben muss. Die Aufbewahrung bedeutet, dass die Ablage in den externen Speicher geschrieben und später aus dem externen Speicher wiederhergestellt werden muss, wenn die Ablage erneut verarbeitet wird. Der Löschvorgang weist den Treiber an, dass der Inhalt der Ablage gut definiert ist: die klare Farbe. Diese Situation ist trivial zu optimieren. Es gibt auch Erweiterungen, um den Pufferinhalt zu "verwerfen". 

0
t0rakka