Wie viele Polygone in einer Szene kann moderne Hardware unter Beibehaltung der Echtzeit erreichen und wie kommt man dorthin?

Eine in gewisser Weise ziemlich einfache Frage, auf die viele Menschen, auch ich, die Antwort nicht wirklich wissen. GPU-Hersteller geben häufig extrem hohe Zahlen an, und die Streuung zwischen Polygonzahlen, die verschiedene Game-Engines angeblich unterstützen, erstreckt sich häufig über mehrere Größenordnungen und hängt dann immer noch stark von vielen Variablen ab.

Ich bin mir bewusst, dass dies eine breite, ziemlich offene Frage ist, und ich entschuldige mich dafür. Ich dachte nur, dass es eine wertvolle Frage wäre, die ich hier haben sollte.

Ich denke, es ist allgemein anerkannt, dass Echtzeit alles ist, was über interaktiv steht. Und interaktiv ist definiert als "reagiert auf Eingaben, ist aber nicht flüssig in der Tatsache, dass die Animation zackig erscheint".
Die Echtzeit hängt also von der Geschwindigkeit der Bewegungen ab, die dargestellt werden müssen. Kinoprojekte mit 24 FPS und für viele Fälle ausreichend Echtzeit.

Wie viele Polygone eine Maschine verarbeiten kann, lässt sich leicht überprüfen, indem Sie selbst überprüfen. Erstellen Sie einfach einen kleinen VBO-Patch als einfachen Test und einen FPS-Zähler. Viele DirectX- oder OpenGL-Beispiele bieten Ihnen den perfekten Prüfstand für diesen Benchmark.

Wenn Sie eine High-End-Grafikkarte haben, können Sie ungefähr 1 Million Polygone in Echtzeit anzeigen. Wie Sie bereits sagten, werden Engines nicht so einfach Unterstützung beanspruchen, da reale Szenendaten eine Reihe von Leistungsschwierigkeiten verursachen, die nicht mit der Anzahl der Polygone zusammenhängen.

Du hast:

• Füllrate
  • Texturabtastung
  • ROP-Ausgang
• Anrufe ziehen
• Zielschalter rendern
• Pufferaktualisierungen (einheitlich oder andere)
• überziehen
• Shader Komplexität
• Komplexität der Pipeline (Rückkopplung verwendet? iterative Geometrieschattierung? Okklusion?)
• Synchronisationspunkte mit CPU (Pixel Readback?)
• Polygonreichtum

Abhängig von den Schwachstellen und Stärken einer bestimmten Grafikkarte wird der eine oder andere dieser Punkte der Engpass sein. Es ist nicht so, dass man mit Sicherheit sagen kann: "Da, das ist der Eine."

BEARBEITEN:

Ich wollte hinzufügen, dass man die GFlops-Spezifikationszahl einer bestimmten Karte nicht verwenden und sie linear der Polygon-Push-Kapazität zuordnen kann. Aufgrund der Tatsache, dass die Polygonbehandlung einen sequentiellen Engpass in der Grafikpipeline durchlaufen muss, wie hier ausführlich erläutert: https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-part-3 /
TLDR: Die Scheitelpunkte müssen vor der primitiven Assemblierung in einen kleinen Cache passen, was nativ eine sequentielle Sache ist (die Reihenfolge der Scheitelpunktpuffer ist wichtig).

Wenn Sie die GeForce 7800 (9 Jahre alt?) Mit der diesjährigen 980 vergleichen, scheint sich die Anzahl der Operationen pro Sekunde, die sie ausführen kann, tausendfach erhöht zu haben. Aber Sie können darauf wetten, dass Polygone nicht tausendmal schneller geschoben werden (was nach dieser einfachen Metrik etwa 200 Milliarden pro Sekunde wäre).

EDIT2:

Beantwortung der Frage "Was kann man tun, um einen Motor zu optimieren?", Wie in "Nicht zu viel Effizienz bei Zustandsschaltern und anderen Gemeinkosten verlieren".
Das ist eine Frage, die so alt ist wie die Motoren selbst. Und wird mit fortschreitender Geschichte immer komplexer.

In der Tat enthalten typische Szenendaten in der realen Welt viele Materialien, viele Texturen, viele verschiedene Shader, viele Renderziele und Durchgänge sowie viele Scheitelpunktpuffer und so weiter. Eine Engine, mit der ich gearbeitet habe, arbeitete mit dem Begriff der Pakete:

Ein Paket kann mit einem Draw-Aufruf gerendert werden.
Es enthält Bezeichner für:

• Scheitelpunktpuffer
• Indexpuffer
• Kamera (gibt den Pass und Renderziel)
• Material-ID (gibt Shader, Texturen und UBO an)
• Abstand zum Auge
• ist sichtbar

Der erste Schritt jedes Frames besteht also darin, eine schnelle Sortierung der Paketliste mithilfe einer Sortierfunktion mit einem Operator durchzuführen, der der Sichtbarkeit Vorrang einräumt, dann bestanden, dann Material, dann Geometrie und schließlich Abstand.

Das Zeichnen von nahen Objekten erhält die Priorität, um das frühe Z-Keulen zu maximieren.
Pässe sind feste Schritte, daher haben wir keine andere Wahl, als sie zu respektieren.
Material ist die teuerste Sache, um nach dem Rendern von Zielen den Status zu wechseln.

Selbst zwischen verschiedenen Material-IDs kann eine Unterordnung unter Verwendung eines heuristischen Kriteriums vorgenommen werden, um die Anzahl der Shader-Änderungen (am teuersten bei Materialzustandswechseloperationen) und zweitens Änderungen der Texturbindung zu verringern.

Nach all dieser Bestellung kann man bei Bedarf Megatexturierung, virtuelle Texturierung und attributloses Rendering ( Link ) anwenden .

Über die Engine-API ist es auch üblich, die Ausgabe der vom Client benötigten Statuseinstellungsbefehle zu verschieben. Wenn ein Client "Kamera 0 einstellen" anfordert, ist es am besten, diese Anforderung einfach zu speichern. Wenn der Client später "Kamera 1 einstellen" aufruft, jedoch keine anderen Befehle dazwischen, kann die Engine die Nutzlosigkeit des ersten Befehls erkennen und löschen . Dies ist eine Redundanzeliminierung, die durch Verwendung eines "vollständig beibehaltenen" Paradigmas möglich ist. Im Gegensatz zum "unmittelbaren" Paradigma, das nur ein Wrapper über der nativen API wäre und die Befehle richtig ausgibt, wie vom Client-Code geordnet. ( Beispiel: virtrev )

Und schließlich ist es bei moderner Hardware ein sehr teurer (zu entwickelnder), aber möglicherweise sehr lohnender Schritt, die API auf Metall / Mantel / Vulkan / DX12-Stil umzustellen und die Rendering-Befehle von Hand vorzubereiten.

Eine Engine, die Rendering-Befehle vorbereitet, erstellt einen Puffer, der eine "Befehlsliste" enthält, die bei jedem Frame überschrieben wird.

Normalerweise gibt es einen Begriff von "Budget", den sich ein Spiel leisten kann. Sie müssen alles in 16 Millisekunden erledigen, damit Sie die GPU-Zeit "2 ms für Lichtvorlauf", "4 ms für Materialdurchlauf", "6 ms für indirekte Beleuchtung", "4 ms für Nachprozesse" klar aufteilen können ...