Lo sblocco del framerate in XNA / MonoGame mi dirà quanto è efficiente il mio codice?

12

Ho sbloccato il framerate in MonoGame tramite:

this.graphics.SynchronizeWithVerticalRetrace = false;
base.IsFixedTimeStep = false;

E usandolo come base per l'efficienza che sto aggiornando e disegnando nel gioco.

Con una risoluzione di 240 x 160 senza che sia stato disegnato o aggiornato nulla tranne un contatore di frame, ottengo un valore FPS compreso tra 9.000 e 11.000 FPS.

Se aggiungo nuovamente tutto il mio codice, si riduce a circa 1.100 FPS.

È una buona indicazione che il mio codice sta rallentando significativamente la GPU (10 volte) e dovrei preoccuparmi? Il gioco funzionerà a 60 FPS, quindi sono ancora abbastanza lontano da quello, ma a che punto dovrei preoccuparmi della frequenza dei fotogrammi sbloccata?

GPU: AMD FirePro W5000 (FireGL V)

monogame frame-rate

— test
fonte

1

Come nota a margine: nel tuo percorso di sviluppo, suggerirei di mantenere il tuo FPS di destinazione sia in debug che in versione; qualcosa potrebbe funzionare bene in uscita ma potrebbe essere lento come l'inferno nel debug, il che non è davvero utile :)

— Vaillancourt

Non proprio. Altre risposte rispondono bene, ma il punto principale è che la maggior parte del sollevamento pesante verrà effettuato dalla scheda grafica usando l'accelerazione hardware. A meno che tu non stia lavorando nello stesso thread della grafica (non dovresti esserlo), allora non c'è motivo per cui FPS sia influenzato dal tuo codice - entro limiti ragionevoli - affatto.

— Dan Pantry,

30

Solo rozzamente.

Innanzitutto, l' FPS non è una misura lineare . La differenza tra 11k FPS e 9k è estremamente ridotta (0,0000201 secondi per frame). Ma la differenza tra 60 e 2060 FPS (un delta FPS 2k, lo stesso che esiste tra 11k e 9k) è di 0,0161 secondi ... molto più grande. Può quindi essere pericoloso come metrica delle prestazioni semplicemente perché grandi differenze possono o meno essere così negative.

L'uso del tempo per fotogramma invece è un po 'più facile da ragionare, ma anche in questo caso è ancora una visione molto ampia della situazione. Ti dice solo quanti secondi impiega un fotogramma del gioco. Non ti dice perché , a meno che non si osservi un grande aumento del frame time immediatamente dopo aver aggiunto o abilitato una particolare funzionalità.

Può essere un barometro di base per decidere che è tempo di fare una profilazione più approfondita. È particolarmente negativo utilizzare FPS per determinare se si è collegati alla CPU o alla GPU; La profilazione della GPU non è così semplice come misurare il tempo sulla CPU (che è probabilmente il tuo codice di calcolo del tempo e del calcolo FPS).

Per quanto riguarda quando dovresti essere preoccupato ... beh, ti sei detto che il gioco aveva come obiettivo 60 FPS. Se inizi a immergerti vicino o al di sotto di quello, probabilmente dovrai iniziare a pensare più attentamente ai tuoi problemi di prestazioni. Fino ad allora, mi concentrerei sul far funzionare tutto e poi mi preoccuperei di farlo velocemente .

6

+1 per l'ultima frase. A mio avviso, l'ottimizzazione precoce delle prestazioni è una pratica piuttosto negativa (parlando per esperienza).

— sirdank,

1

c2.com/cgi/wiki?PrematureOptimization - Letture consigliate sull'argomento

— Machinarius

Non sempre, se hai una macchina di fascia alta e ottiene circa 80 FPS, sarebbe abbastanza buono sulla tua macchina, ma se volessi scegliere come target computer di fascia bassa, potrebbero ottenere solo 15 FPS, idealmente, sarebbe meglio per eseguire i test su una macchina con le specifiche minime che si desidera targetizzare, ma in caso contrario, l'ottimizzazione per la propria macchina potrebbe ottimizzarla anche per la propria. Naturalmente, se funziona abbastanza velocemente sulle tue macchine di fascia bassa, allora non c'è motivo di spendere di più per ottimizzare ulteriormente, soprattutto a rischio di aumento dei bug.

— Programmdude,

5

Non vedo perché non potresti usarlo! Tieni presente che potrebbe essere necessario codificare in modo diverso per tenere conto delle differenze tra i timestep fissi / variabili, quindi se stai pianificando di risolverlo quando rilasci, dovrai apportare modifiche. Vedi questo articolo: http://rbwhitaker.wikidot.com/time-steps

È una buona indicazione che il mio codice sta rallentando significativamente la GPU

Potrebbe essere anche la CPU. Ti consiglio di eseguire periodicamente il profiler incorporato di Visual Studio (o ogni volta che vedi un calo di framerate di grandi dimensioni) per trovare punti attivi nel tuo codice.

dovrei essere preoccupato?

Questo ovviamente dipende dall'hardware che stai prendendo di mira. Dovrai testare il tuo codice con le macchine con i requisiti minimi più bassi che sei disposto a supportare. Se funziona almeno 60 lì, allora non sarei troppo preoccupato.

— tandersen
fonte