In che modo i giochi 3D sono così efficienti? [chiuso]

C'è qualcosa che non ho mai capito. Come può un grande gioco per PC come GTA IV utilizzare il 50% della mia CPU e funzionare a 60 fps mentre una demo DX di una teiera rotante a 60 fps utilizza un enorme 30%?

In generale, è perché

1. I giochi sono ottimali su ciò che devono rendere, e
2. Approfittano in modo particolare del tuo hardware.

Ad esempio, una semplice ottimizzazione che è possibile effettuare implica che in realtà non si cerca di disegnare cose che non si possono vedere. Prendi in considerazione una scena complessa come un paesaggio urbano di Grand Theft Auto IV . Il renderer in realtà non esegue il rendering di tutti gli edifici e le strutture. Invece, sta visualizzando solo ciò che la telecamera può vedere. Se potessi volare sul retro di quegli stessi edifici, di fronte alla telecamera originale, vedresti una struttura a conchiglia scavata a metà. Ogni punto che la telecamera non è in grado di vedere non viene visualizzato - poiché non puoi vederlo, non è necessario provare a mostrartelo.

Inoltre, esistono istruzioni ottimizzate e tecniche speciali quando si sviluppa su un determinato set di hardware, per consentire velocizzazioni ancora migliori.

L'altra parte della tua domanda è perché una demo usa così tanta CPU:

... mentre una demo DX di una teiera rotante a 60 fps utilizza un enorme 30%?

È comune che le demo di API grafiche (come dxdemo) ricadano su quello che viene chiamato un renderer software quando il tuo hardware non supporta tutte le funzionalità necessarie per mostrare un esempio grazioso. Queste caratteristiche potrebbero includere cose come ombre, riflesso, ray-tracing, fisica, eccetera.

Questo imita la funzione di un dispositivo hardware completamente completo che è improbabile che esista, al fine di mostrare tutte le funzionalità dell'API. Ma poiché l'hardware in realtà non esiste, funziona invece sulla tua CPU. È molto più inefficiente rispetto alla delega a una scheda grafica, da cui l'utilizzo elevato della CPU.

Pazienza, abilità tecnica e resistenza.

Il primo punto è che una demo DX è principalmente un supporto didattico, quindi è fatto per chiarezza e non per velocità di esecuzione.

È un argomento piuttosto grande da condensare, ma lo sviluppo di giochi riguarda principalmente la comprensione dei dati e dei percorsi di esecuzione in misura quasi patologica.

1. Il codice è progettato attorno a due elementi: i dati e l'hardware di destinazione.
2. Il codice più veloce è il codice che non viene mai eseguito: ordina i tuoi dati in batch e fai solo operazioni costose sui dati che ti servono
3. Il modo in cui archiviate i dati è fondamentale: l'obiettivo di un accesso contiguo consente di elaborare in batch ad alta velocità.
4. Parellizza tutto il possibile
5. Le CPU moderne sono veloci, la RAM moderna è molto lenta. I cache miss sono micidiali.
6. Spingete quanto più possibile alla GPU: ha una memoria locale veloce, quindi può divampare attraverso i dati ma è necessario aiutarli organizzando i dati correttamente.
7. Evita di fare molti switch renderstate (di nuovo raggruppa insieme simili dati di vertici simili) poiché ciò provoca lo stallo della GPU
8. Scorri le tue trame e assicurati che siano potenze di due: questo migliora le prestazioni della cache delle trame sulla GPU.
9. Usa il più possibile i livelli di dettaglio - versioni basse / medie / alte dei modelli 3D e passa in base alla distanza dal riproduttore della fotocamera - non ha senso eseguire il rendering di una versione ad alta risoluzione se ha solo 5 pixel sullo schermo.

I giochi 3D sono grandi per ingannare i tuoi occhi. Ad esempio, esiste una tecnica chiamata occlusione ambientale dello spazio dello schermo (SSAO) che darà una sensazione più realistica ombreggiando quelle parti di una scena che sono vicine alle discontinuità superficiali. Se guardi gli angoli del tuo muro, vedrai che nella maggior parte dei casi appaiono leggermente più scuri dei centri.

Lo stesso effetto può essere ottenuto usando la radiosità, che si basa su una simulazione piuttosto accurata. La radio terrà conto anche di più effetti di luci che rimbalzano, ecc., Ma è computazionalmente costosa - è una tecnica di ray tracing.

Questo è solo un esempio. Esistono centinaia di algoritmi per la grafica computerizzata in tempo reale e si basano essenzialmente su buone approssimazioni e in genere fanno molte ipotesi. Ad esempio, l'ordinamento spaziale deve essere scelto con molta attenzione a seconda della velocità, della posizione tipica della telecamera e della quantità di modifiche alla geometria della scena.

Queste "ottimizzazioni" sono enormi : puoi implementare un algoritmo in modo efficiente e farlo funzionare 10 volte più veloce, ma la scelta di un algoritmo intelligente che produce un risultato simile ("barare") può farti passare da O (N ^ 4) a O ( log (N)).

L'ottimizzazione dell'implementazione effettiva è ciò che rende i giochi ancora più efficienti, ma è solo un'ottimizzazione lineare.

Eeeeek!

So che questa domanda è vecchia, ma è eccitante che nessuno abbia menzionato VSync !!! ???

Hai confrontato l'utilizzo della CPU del gioco a 60 fps con l'utilizzo della CPU della demo della teiera a 60 fps.

Non è evidente che entrambi funzionano (più o meno) esattamente a 60 fps? Questo porta alla risposta ...

Entrambe le app funzionano con vsync abilitato! Ciò significa (attenuato) che il framerate di rendering è bloccato sull'intervallo verticale vuoto del monitor. L'hardware grafico (e / o il driver) verranno visualizzati solo al massimo. 60fps. 60fps = 60Hz (Hz = al secondo) frequenza di aggiornamento. Quindi probabilmente usi un CRT piuttosto vecchio e sfarfallio o un display LCD comune. Su un CRT a 100Hz probabilmente vedrai framerate fino a 100Hz. VSync si applica anche in modo simile ai display LCD (di solito hanno una frequenza di aggiornamento di 60Hz).

Quindi, la demo della teiera potrebbe effettivamente funzionare in modo molto più efficiente! Se utilizza il 30% del tempo della CPU (rispetto al 50% del tempo della CPU per GTA IV), probabilmente utilizza meno tempo della CPU per ogni fotogramma e attende solo più tempo per il successivo intervallo vuoto verticale. Per confrontare entrambe le app, dovresti disabilitare vsync e misurare di nuovo (misurerai fps molto più alti per entrambe le app).

A volte va bene disabilitare vsync (la maggior parte dei giochi ha un'opzione nelle sue impostazioni). A volte vedrai "strappare artefatti" quando vsync è disabilitato.

Puoi trovarne i dettagli e perché è usato su Wikipedia: http://it.wikipedia.org/wiki/Vsync

Mentre molte risposte qui forniscono eccellenti indicazioni su come risponderò invece alla domanda più semplice sul perché

• GTA4 ha richiesto $ 400 milioni di dollari nella sua prima settimana
• Crytech ha scritto una demo grafica estremamente impressionante per consentire a nVidia di "sfoggiare" durante una fiera. Le impressioni risultanti li hanno aiutati a creare quello che sarebbe diventato FarCry.
• I ricavi e l'utile operativo del 2005 di Valve sono stati dichiarati rispettivamente a 70 e 55 milioni di dollari.

Forse il miglior esempio (sicuramente uno dei più noti) è il software Id. Si resero conto molto presto, ai tempi del comandante Keen (ben prima del 3D) che si inventava un modo intelligente per ottenere qualcosa di ¹ , anche se si basava su hardware moderno (in questo caso una scheda grafica EGA!) Che era graficamente superiore a la competizione per far risaltare il tuo gioco. Questo era vero, ma si resero inoltre conto che, invece di dover inventare nuovi giochi e contenuti stessi, avrebbero potuto ottenere la licenza per la tecnologia, ottenendo così entrate dagli altri e potendo sviluppare la prossima generazione di motori e quindi saltare di nuovo la concorrenza .

Le capacità di questi programmatori (insieme a esperti di business) sono ciò che li ha resi ricchi.

Detto questo, non sono necessariamente i soldi a motivare queste persone. Probabilmente è altrettanto il desiderio di realizzare, di realizzare. I soldi guadagnati nei primi tempi significano semplicemente che ora hanno il tempo di dedicarsi a ciò di cui godono. E mentre molti hanno interessi esterni, quasi tutti ancora programmano e cercano di trovare modi per fare meglio dell'ultima iterazione.

In parole povere, la persona che ha scritto la demo della teiera probabilmente ha avuto uno o più dei seguenti problemi:

• meno tempo
• meno risorse
• meno incentivo alla ricompensa
• meno concorrenza interna ed esterna
• obiettivi minori
• meno talento

L'ultimo può sembrare duro ² ma chiaramente ci sono alcuni che sono migliori di altri, le curve a campana a volte hanno estremità estreme e tendono ad essere attratte dalle corrispondenti estremità estreme di ciò che viene fatto con quell'abilità.

Gli obiettivi minori uno in realtà è probabilmente il motivo principale. L'obiettivo della demo della teiera era proprio questo, una demo. Ma non una demo dell'abilità dei programmatori ³ . Sarebbe una demo di una piccola sfaccettatura di un (grande) sistema operativo, in questo caso il rendering DX.

Per coloro che guardano la demo non importa che usasse molta più CPU del necessario purché fosse abbastanza buona. Non vi sarebbe alcun incentivo per eliminare gli sprechi quando non vi sarebbe alcun beneficiario. In confronto a un gioco piacerebbe avere cicli di riserva per una migliore intelligenza artificiale, un suono migliore, più poligoni, più effetti.

1. in tal caso scorrimento regolare sull'hardware del PC
2. Probabilmente più di me, quindi ne siamo chiari
3. a rigor di termini sarebbe stata anche una demo per il suo manager, ma ancora una volta l'unità sarebbe stata il tempo e / o la qualità visiva.

Per alcuni motivi

• I motori di gioco 3D sono altamente ottimizzati
• la maggior parte del lavoro viene svolto dalla scheda grafica
• 50% Hm, lasciami indovinare che hai un dual core e ne viene utilizzato solo un core ;-)

EDIT: per dare pochi numeri

Athlon-64 da 2,8 Ghz con GPU NV-6800. I risultati sono:

• CPU: 72,78 Mflop
• GPU: 2440.32 Mflop

A volte una scena può avere più di quello che sembra. Ad esempio, una teiera rotante con migliaia di vertici, mappatura ambientale, mappatura di rilievo e altri shader di pixel complessi che vengono rappresentati contemporaneamente equivale a un sacco di elaborazione. Molte volte queste dimostrazioni di teiere hanno semplicemente lo scopo di mostrare una sorta di effetto speciale. Inoltre, potrebbero non sempre sfruttare al meglio la GPU quando le prestazioni assolute non sono l'obiettivo.

In un gioco potresti vedere effetti simili ma di solito sono fatti in modo compromesso nel tentativo di massimizzare il frame rate. Queste ottimizzazioni si estendono a tutto ciò che vedi nel gioco. Il problema diventa: "Come possiamo creare la scena più spettacolare e realistica con la minima quantità di potenza di elaborazione?" È ciò che rende i programmatori di giochi alcuni dei migliori ottimizzatori in circolazione.

1. Gestione della scena. kd-alberi, abbattimento frustrato, bsps, scatole di delirio gerarchiche, set di visibilità parziale.
2. LOD. Commutazione di versioni con dettagli inferiori per sostituire oggetti lontani.
3. Impostori. Come LOD ma nemmeno un oggetto, solo una foto o un "cartellone".
4. SIMD.
5. Gestione della memoria personalizzata. Memoria allineata, meno frammentazione.
6. Strutture di dati personalizzate (ovvero nessuna STL, modello relativamente minimo).
7. Montaggio in luoghi, principalmente per SIMD.

Con tutte le risposte valide e qualificate fornite, manca ancora quella che conta: il contatore di utilizzo della CPU di Windows non è molto affidabile. Immagino che questa semplice demo di teiera chiami semplicemente la funzione di rendering nel suo ciclo inattivo, bloccando allo swap del buffer.

Ora il contatore di utilizzo della CPU di Windows esamina solo la quantità di tempo di CPU trascorso in ciascun processo, ma non il modo in cui viene utilizzato questo tempo di CPU. Prova ad aggiungere a

Sleep(0);

subito dopo il ritorno dalla funzione di rendering e confronto.

Inoltre, ci sono molti trucchi dal punto di vista artistico per salvare il potere computazionale. In molti giochi, in particolare quelli più vecchi, le ombre sono precalcolate e "cotte" direttamente nelle trame della mappa. Molte volte, gli artisti hanno cercato di usare gli aerei (due triangoli) per rappresentare cose come alberi ed effetti speciali quando sarebbero stati quasi uguali. La nebbia nei giochi è un modo semplice per evitare il rendering di oggetti lontani e, spesso, i giochi avrebbero risoluzioni multiple di ogni oggetto per viste lontane, medie e vicine.

Il nucleo di ogni risposta dovrebbe essere questo: le trasformazioni che eseguono i motori 3D sono per lo più specificate in aggiunte e moltiplicazioni (algebra lineare) (senza rami o salti), le operazioni di un disegno di un singolo fotogramma sono spesso specificate in modo tale che i lavori di tale add-mul possono essere eseguiti in parallelo. I core GPU sono ottimi per aggiungere add-mul e hanno dozzine o centinaia di core add-mull.

Alla CPU resta il compito di fare cose semplici, come l'intelligenza artificiale e altre logiche di gioco.

Come può un grande gioco per PC come GTA IV utilizzare il 50% della mia CPU e funzionare a 60 fps mentre una demo DX di una teiera rotante a 60 fps utilizza un enorme 30%?

Mentre GTA è molto probabilmente più efficiente della demo DX, misurare l'efficienza della CPU in questo modo è sostanzialmente rotto. L'efficienza potrebbe essere definita, ad esempio, da quanto lavoro svolgi per un determinato periodo di tempo. Un semplice controesempio: genera un thread per una CPU logica e lascia che un semplice ciclo infinito venga eseguito su di esso. Otterrai un utilizzo della CPU del 100%, ma non è efficiente, poiché non viene eseguito alcun lavoro utile.

Questo porta anche a una risposta: come può un gioco essere efficiente? Quando si programmano "grandi giochi", uno sforzo enorme è dedicato all'ottimizzazione del gioco in tutti gli aspetti (che oggigiorno di solito include anche ottimizzazioni multi-core). Per quanto riguarda la demo DX, il suo punto non sta correndo veloce, ma piuttosto dimostrando concetti.

Penso che dovresti dare un'occhiata all'utilizzo della GPU piuttosto che alla CPU ... Scommetto che la scheda grafica è molto più occupata in GTA IV che nell'esempio Teapot (dovrebbe essere praticamente inattivo).

Forse potresti usare qualcosa come questo monitor per verificare che:

http://downloads.guru3d.com/Rivatuner-GPU-Monitor-Vista-Sidebar-Gadget-download-2185.html

Anche il framerate è qualcosa da considerare, forse il campione di teiera funziona a piena velocità (forse 1000 fps) e la maggior parte dei giochi è limitata alla frequenza di aggiornamento del monitor (circa 60 fps).

Guarda la risposta su vsync; ecco perché stanno funzionando alla stessa frequenza dei fotogrammi.

In secondo luogo, in una partita manca la CPU. Una spiegazione semplificata è che il loop di gioco principale è solo un loop infinito:

while(1) { 
  update();
  render();
}

Anche se il tuo gioco (o in questo caso teiera) non sta facendo molto, stai ancora consumando CPU nel tuo ciclo.

Il 50% della CPU in GTA è "più produttivo" rispetto al 30% nella demo, poiché molto probabilmente non sta facendo molto; ma GTA sta aggiornando tonnellate di dettagli. Anche l'aggiunta di un "Sleep (10)" alla demo farà cadere la CPU di una tonnellata.

Infine, osserva l'utilizzo della GPU. La demo sta probabilmente prendendo <1% su una moderna scheda video mentre il GTA avrà probabilmente la maggioranza durante il gioco.

In breve, i parametri di riferimento e le misurazioni non sono accurati.

La demo della teiera DX non utilizza il 30% della CPU per svolgere un lavoro utile. È in attesa perché non ha nient'altro da fare.

Da quello che so della serie Unreal alcune convenzioni sono spezzate come l'incapsulamento. Il codice viene compilato in bytecode o direttamente nel codice macchina a seconda del gioco. Inoltre, gli oggetti vengono renderizzati e impacchettati sotto forma di maglie e cose come trame, luci e ombre sono precalcolate mentre come una pura animazione 3d richiede questo in questo momento reale. Quando il gioco è effettivamente in esecuzione, ci sono anche alcune ottimizzazioni come il rendering solo delle parti visibili di un oggetto e la visualizzazione dei dettagli della trama solo da vicino. Infine, è probabile che i videogiochi siano progettati per ottenere il meglio da una piattaforma in un determinato momento (ad esempio: Intelx86 MMX / SSE, DirectX, ...).

Penso che manchi una parte importante della risposta. La maggior parte delle risposte ti dice "Conosci i tuoi dati". Il fatto è che devi, allo stesso modo e con lo stesso grado di importanza, conoscere anche il tuo:

• CPU (orologio e cache)
• Memoria (frequenza e latenza)
• Disco rigido (in termini di velocità e tempi di ricerca)
• GPU (#cores, clock e relativa memoria / cache)
• Interfacce: controller Sata, revisioni PCI, ecc.

MA , per di più, con gli attuali computer moderni, non saresti mai in grado di riprodurre un vero video 1080p a >> 30ftp (una singola immagine 1080p a 64 bit richiederebbe 15000 Ko / 14,9 MB). Il motivo è dovuto al campionamento / precisione. Un videogioco non userebbe mai una doppia precisione (64 bit) per pixel, immagini, dati, ecc ..., ma piuttosto userebbe una precisione personalizzata inferiore (~ 4-8 bit) e talvolta meno precisione riscalata con tecniche di interpolazione per consentire un calcolo ragionevole tempo.

Esistono anche altre tecniche come il ritaglio dei dati (sia con lo standard OpenGL che con l'implementazione del software), la compressione dei dati, ecc. Tieni anche presente che le GPU attuali possono essere> 300 volte più veloci delle attuali CPU in termini di capacità hardware. Tuttavia, un buon programmatore può ottenere un fattore 10-20x, a meno che il problema non sia completamente ottimizzato e completamente parallelizzabile (in particolare attività parallelizzabile).

Per esperienza, posso dirti che l'ottimizzazione è come una curva esponenziale. Per raggiungere prestazioni ottimali, il tempo richiesto può essere incredibilmente importante.

Quindi, per tornare alla teiera, dovresti vedere come viene rappresentata, campionata la geometria e con quale precisione Vs vede in GTA 5, in termini di geometria / trame e, soprattutto, i dettagli (precisione, campionamento, ecc.)