Quanti poligoni in una scena può raggiungere l'hardware moderno mantenendo in tempo reale e come arrivarci?

Una domanda abbastanza semplice, per certi versi, ma a cui molte persone, me compreso, non conoscono davvero la risposta. I produttori di GPU citano spesso numeri estremamente elevati e la diffusione tra i poligoni conta che vari motori di gioco sostengono di supportare spesso su più ordini di grandezza, e quindi dipende ancora pesantemente da molte variabili.

Sono consapevole che questa è una domanda ampia, praticamente aperta, e mi scuso per questo, ho solo pensato che sarebbe stata una domanda preziosa avere qui comunque.

Penso che sia comunemente accettato che il tempo reale sia tutto ciò che è sopra interattivo. E interattivo è definito come "risponde all'input ma non è fluido nel fatto che l'animazione sembra irregolare".
Quindi il tempo reale dipenderà dalla velocità dei movimenti che uno deve rappresentare. Il cinema proietta a 24 FPS ed è in tempo reale sufficiente per molti casi.

Quindi quanti poligoni possono gestire una macchina è facilmente verificabile controllando da soli. Basta creare una piccola patch VBO come un semplice test e un contatore FPS, molti campioni DirectX o OpenGL ti daranno il banco di prova perfetto per questo benchmark.

Troverai se hai una scheda grafica di fascia alta che puoi visualizzare circa 1 milione di poligoni in tempo reale. Tuttavia, come hai detto, i motori non richiederanno il supporto così facilmente perché i dati della scena del mondo reale causeranno un numero di maiali delle prestazioni non correlati al conteggio dei poligoni.

Hai:

• tasso di riempimento
  • campionamento delle trame
  • Uscita ROP
• disegnare chiamate
• rendere gli interruttori di destinazione
• aggiornamenti buffer (uniforme o altro)
• overdraw
• complessità dello shader
• complessità della pipeline (qualsiasi feedback utilizzato? ombreggiatura della geometria iterativa? occlusione?)
• sincronizzare i punti con la CPU (pixel readback?)
• ricchezza poligonale

A seconda dei punti deboli e forti di una particolare scheda grafica, uno o l'altro di questi punti sarà il collo di bottiglia. Non è come puoi dire con certezza "lì, quello è quello".

MODIFICARE:

Volevo aggiungere che non si può usare la figura delle specifiche GFlops di una carta specifica e mapparla linearmente sulla capacità di spinta del poligono. A causa del fatto che il trattamento poligonale deve attraversare un collo di bottiglia sequenziale nella pipeline grafica, come spiegato in dettaglio qui: https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-parte-3 /
TLDR: i vertici devono inserirsi in una piccola cache prima dell'assemblaggio primitivo che è nativamente una cosa sequenziale (l'ordine del buffer dei vertici è importante).

Se si confronta la GeForce 7800 (9 anni?) Con la 980 di quest'anno, sembra che il numero di operazioni al secondo di cui è capace sia aumentato di mille volte. Ma puoi scommettere che non spingerà i poligoni mille volte più velocemente (che sarebbe di circa 200 miliardi al secondo con questa semplice metrica).

EDIT2:

Per rispondere alla domanda "cosa si può fare per ottimizzare un motore", come in "per non perdere troppa efficienza negli switch di stato e in altre spese generali".
Questa è una domanda vecchia quanto i motori stessi. E sta diventando più complesso con il progredire della storia.

In effetti, nella situazione del mondo reale, i dati tipici della scena conterranno molti materiali, molte trame, molti shader diversi, molti target di rendering e passaggi, molti buffer di vertici e così via. Un motore con cui ho lavorato ha funzionato con la nozione di pacchetti:

Un pacchetto è ciò che può essere reso con una chiamata di disegno.
Contiene identificatori per:

• buffer dei vertici
• buffer di indice
• camera (dà il passaggio e il rendering target)
• ID materiale (fornisce shader, texture e UBO)
• distanza dall'occhio
• è visibile

Quindi il primo passo di ogni fotogramma è eseguire un ordinamento rapido nell'elenco dei pacchetti utilizzando una funzione di ordinamento con un operatore che dia priorità alla visibilità, quindi passa, quindi materiale, quindi geometria e infine distanza.

Disegnare oggetti vicini ottiene la prororità per massimizzare l'abbattimento iniziale di Z.
I passaggi sono passaggi fissi, quindi non abbiamo altra scelta che rispettarli.
Il materiale è la cosa più costosa da cambiare stato dopo il rendering delle destinazioni.

Anche tra ID materiali diversi, è possibile effettuare un ordine secondario utilizzando un criterio euristico per ridurre il numero di cambi di shader (i più costosi nelle operazioni di cambio di stato del materiale) e, in secondo luogo, i cambiamenti di associazione delle trame.

Dopo tutto questo ordinamento, è possibile applicare mega texturing, texturing virtuale e rendering senza attributi ( link ) se ritenuto necessario.

Informazioni sull'API del motore anche una cosa comune è rinviare l'emissione dei comandi di impostazione dello stato richiesti dal client. Se un client richiede "imposta telecamera 0", è preferibile archiviare questa richiesta e se in seguito il client chiama "imposta telecamera 1" ma senza altri comandi in mezzo, il motore può rilevare l'inutilità del primo comando e rilasciarlo . Questa è l'eliminazione della ridondanza, che è possibile utilizzando un paradigma "completamente mantenuto". In opposizione al paradigma "immediato", che sarebbe solo un wrapper sopra l'API nativa ed emetterebbe i comandi come ordinato dal codice client. ( esempio: virtrev )

E infine, con l'hardware moderno, un passo molto costoso (da sviluppare), ma potenzialmente altamente gratificante da compiere è quello di passare l'API allo stile metal / mantle / vulkan / DX12 e preparare manualmente i comandi di rendering.

Un motore che prepara i comandi di rendering crea un buffer che contiene un "elenco di comandi" che viene sovrascritto su ciascun frame.

Di solito c'è una nozione di "budget" frame, un gioco può permettersi. Devi fare tutto in 16 millisecondi, quindi dividi chiaramente il tempo della GPU "2 ms per il passaggio della luce", "4 ms per il passaggio dei materiali", "6 ms per l'illuminazione indiretta", "4 ms per i postprocessi" ...