Analisi schede video: oltre gli FPS per entrare nel secondo

[illidan2000]

Originariamente inviato da qiplayer

Ho 3gtx titan... Ebbene nonostante i mostri di schede e tempi buoni nei benchmark dei videogames, giocando online ho rallentamenti.
Fin quando nei benchmark di videogames non inseriscono scene d'azione combinati con veloci cambi di visuale esplosioni e altri effetti, il tutto nell'arco di un paio di secondi, questi non riflettono la realtà dei giochi stessi.
Premetto che ho una risoluzione di 5800x1080

con vsynch o senza? su tutti i giochi?
sulla problematica "online", può influire la lentezza della rete? hai controllato l'utilizzo del processore?

[dobermann77]

Originariamente inviato da qiplayer

Ho 3gtx titan... Ebbene nonostante i mostri di schede e tempi buoni nei benchmark dei videogames, giocando online ho rallentamenti.
Fin quando nei benchmark di videogames non inseriscono scene d'azione combinati con veloci cambi di visuale esplosioni e altri effetti, il tutto nell'arco di un paio di secondi, questi non riflettono la realtà dei giochi stessi.
Premetto che ho una risoluzione di 5800x1080

Hai un processore AMD?

[calabar]

Anche io ho pensato che la ripetizione di questo articolo (anche se un po' semplificata rispetto alla sua prima versione) possa essere dovuta all'imminente pubblicazione di una nuova magarecensione sulle schede video.

A me rimangono i dubbi che avevo esposto nell'altro articolo su questo metodo, che è sicuramente un passo avanti ma non è perfetto, e rischia di cadere anche lui in qualche contraddizione.
Il motivo è che non è facile passare (valutandone correttamente le conseguenze) da una misura continua ad una discreta, ma soprattutto il fatto che si prenda in considerazione uno spartiacque netto per decidere cose sia buono e cosa no.

Ho notato alcuni piccoli errori nell'articolo:
- "flusso in compresso" al posto di "flusso non compresso " a pagina 3.
- "valori riferiti al gioco Dirt Showdown alla risoluzione di 2560x1600 pixel", la risoluzione è 2560x1440, a pagina 5.
- la scritta "grafici" estemporanea sotto il terzo grafico a pagina 5.

[calabar]

@dobermann77
Con quella configurazione di schede, mi sembra altamente improbabile abbia risparmiato sul processore. In ogni caso non so quanto a quelle risoluzioni avere il processore AMD possa essere limitante.
A mio parere è un problema di LAG dovuto alla rete, a meno che non abbia proprio esagerato con le impostazioni grafiche.

[7stars]

Paolo, molto esauriente come al solito...però una domanda sorge spontanea:
secondo te, in virtù dell'attuale collegamento PCIe e anche se mettiamo due gpu in modalità x16/x16 2.0 o 3.0, questo è sufficiente per supportare un'esperienza fluida priva di stuttering e cali di frames anomali, e quindi questo è fattibile tramite drivers appropriati, oppure è proprio una questione hardware insormontabile? Con la mia rig io trovo quasi perfetti soltanto Battlefield 3 e Metro Last Light e da quanto ho capito dipende anche dall'ottimizzazione multicore/multigpu dell'engine grafico... es. per AMD su tutti noto parecchi problemi con il vecchio Unreal Engine 3. Con l'UE4 sarà diverso (visto che molti lo usano l'UE, forse perché su Nvidia gira meglio?) ? Chissà... Grazie per eventuale risposta...

[hexaae]

Originariamente inviato da Malek86

A occhio, mi sembra che il problema del microstuttering sia notevolmente aumentato negli ultimi anni.

Ho letto che per le schede Crossfire/SLI il problema potrebbe essere dovuto al fatto che comunicano attraverso il PCI-E che è troppo lento e può causare questi problemi. Però il microstuttering è abbastanza comune in diversi giochi anche nelle schede singole. Con la mia HD7850 capita in un certo numero di giochi (in alcuni casi si può risolvere smanettando un po', per fortuna).

Quale può essere la causa più probabile? Drivers fatti male, oppure c'è dell'altro?

IMHO 2:
1. HW ha (aveva?) cicli più veloci del software. Ne consegue driver mal ottimizzati e aggiornati più che altro per supportare le nuove schede in uscita così rapida. Ottimizzare e migliorare i driver porta in realtà via più tempo di quanto non ci mettano a progettare e mettere in produzione una nuova scheda. Questo è un problema serio e porta anche a sottoutilizzare le potenzialità di nuove schede sulla carta molto più potenti delle precedenti, ma di fatto, per l'appunto, con miglioramenti di prestazioni poco consistenti se provate nei giochi.
2. Ormai il mercato delle vendite per i produttori è fatto dalle console (soprattutto in USA, che è anche quello maggiore) e per PC sono solo port non ottimizzati. La situazione, con le nuove console NG ad architettura AMD GCN forse potrebbe finalmente cambiare portando un vantaggio indiretto ai port PC (dotati di HW simile).

[7stars]

Originariamente inviato da calabar

@dobermann77
Con quella configurazione di schede, mi sembra altamente improbabile abbia risparmiato sul processore. In ogni caso non so quanto a quelle risoluzioni avere il processore AMD possa essere limitante.
A mio parere è un problema di LAG dovuto alla rete, a meno che non abbia proprio esagerato con le impostazioni grafiche.

a parte il processore AMD, la causa è l'engine grafico (obsoleto) che non distribuisce il carico uniformemente sui vari cores...soprattutto se ne hai + di 4 (fisici o virtuali), a volte gravano su uno o due al massimo. Quindi il problema non è Intel o AMD sui processori...al momento la fanno da padrone l'IPC e la potenza del singolo core (purtroppo) anche se questa non è risolutiva in tutti i casi ed è chiaro che i giochi con engines più efficienti e all'avanguardia vanno alla grande sul mio pc...molti si nascondono dietro lo scheduler di Windows e non è vero perché altrimenti qualsiasi applicazione ludica con grafica dettagliata e con qualsiasi engine non sarebbe efficiente...tutte scuse degli sviluppatori che non usano un motore che scala nel modo opportuno IMHO

Originariamente inviato da hexaae

...
2. Ormai il mercato delle vendite per i produttori è fatto dalle console (soprattutto in USA, che è anche quello maggiore) e per PC sono solo port non ottimizzati. La situazione, con le nuove console NG ad architettura AMD GCN forse potrebbe finalmente cambiare portando un vantaggio indiretto ai port PC (dotati di HW simile).

ecco...appunto mi sono stancato con questi port...ma speriamo bene per i titoli che verranno

[calcolatorez3z2z1]

Eppure,in tutto ciò,qualcosa mi sfugge.Non sarà che è proprio questo tipo di schede,questa nuova shader che aggiusta gli errori di quella vecchia la quale doveva essere un miglioramento della precedente, a giochi sviluppati troppo velocemente, bench poco rappresentativi della realtà,pur innovativi e ancora chi più ne ha ne metta.... non riescono a dare risultati soddisfacenti proprio per questo? Penso proprio di si.
Solo le console,per chi ci tiene davvero a divertirsi,permetteranno di soddisfare il cliente con prodotti degni di essere considerati tali e dimenticarsi pure dell'hardware.
Non ho citato i dispositivi mobili e le loro potenzialità.
La verità è che il trinomio Gioco --> Windos --> PC sta giungendo al termine.

[7stars]

Originariamente inviato da calcolatorez3z2z1

La verità è che il trinomio Gioco --> Windos --> PC sta giungendo al termine.

su questo credo (ma soprattutto spero) di no, forse avrebbero fatto altre scelte su console se volessero abbandonare in toto il pc...credo che l'idea invece sia un multipiattaforma meno complicato e con un livello di dettaglio ed un'esperienza percepita più simile...sembra che molti sviluppatori stiano andando in questa direzione, certo sarebbe meglio sviluppare a partire dal pc, ma il mercato va da un'altra parte

[Major Clock]

...........

[Cooperdale]

Veramente il mercato pc è in gran rifioritura. Non datelo per morto se volete evitare figure magre.

[Paolo Corsini]

Originariamente inviato da II ARROWS

Perché ripubblicare lo stesso articolo di qualche mese fa?

Per lo meno io non vedo niente di nuovo... (A parte il video, ma che appunto riporta le stesse cose).

Ciao
ci sono molte informazioni in più sulla metodologia di test; ho riutilizzato dei grafici che hai visto nel primo articolo su FCAT e forse questo ti ha tratto in inganno.

[II ARROWS]

Originariamente inviato da Paolo Corsini

Ciao
ci sono molte informazioni in più sulla metodologia di test; ho riutilizzato dei grafici che hai visto nel primo articolo su FCAT e forse questo ti ha tratto in inganno.

Boh, allora forse avrò capito benissimo come l'hai spiegato la prima volta, perché davvero non ho trovato niente di nuovo...

[Paolo Corsini]

Originariamente inviato da Bivvoz

Molto molto interessante.

Avrei una domanda banale: attivando il vsynch e supponendo di avere un hw che permetta di mantenersi costantemente al tempo del monitor, si visualizzano sempre tutti i frame per intero?
Immagino di si, ma in tal caso vengono comunque generati dei drop frame o l'hw è intelligente e "se la prende comoda"?

Ciao
con le ipotesi che hai indicato si, in teoria ad ogni frame generato dalla scheda fissato a 60 Hz la frequenza di refresh avresti una visualizzazione intera di frame sullo schermo.
All'atto pratico avresti però moltissimi frame che vengono scartati dalla pipeline di rendering, e molti casi nei quali i frame non vengono visualizzati a 60 Hz ma a 30 Hz in quanto nella pipeline si perde il sincronismo e quindi la frequenza di refresh viene temporaneamente dimezzata per recuperare il divario

In ogni caso si tratta di teoria pura, di quasi impossibile applicazione con giochi.

[Paolo Corsini]

Originariamente inviato da calabar

Anche io ho pensato che la ripetizione di questo articolo (anche se un po' semplificata rispetto alla sua prima versione) possa essere dovuta all'imminente pubblicazione di una nuova magarecensione sulle schede video.

C'è tempo per questo; non mi attenderei nulla prima di ottobre fossi al tuo posto.

Originariamente inviato da calabar

A me rimangono i dubbi che avevo esposto nell'altro articolo su questo metodo, che è sicuramente un passo avanti ma non è perfetto, e rischia di cadere anche lui in qualche contraddizione.
Il motivo è che non è facile passare (valutandone correttamente le conseguenze) da una misura continua ad una discreta, ma soprattutto il fatto che si prenda in considerazione uno spartiacque netto per decidere cose sia buono e cosa no.

Se non c'è microstuttering coinvolto le differenze tra Fraps, o software simili, e FCAT sono in genere molto ridotte. La seconda è più precisa e realistica, ma i dati della prima non sono mai molto discordanti. Con microstuttering, causato da tanti fattori (driver, engine, architettura GPU, sistema, OS, ecc..), fraps è a mio avviso sempre da scartare.

Grazie per le segnalazioni dei refusi, correggo

[Paolo Corsini]

Originariamente inviato da 7stars

Paolo, molto esauriente come al solito...però una domanda sorge spontanea:
secondo te, in virtù dell'attuale collegamento PCIe e anche se mettiamo due gpu in modalità x16/x16 2.0 o 3.0, questo è sufficiente per supportare un'esperienza fluida priva di stuttering e cali di frames anomali, e quindi questo è fattibile tramite drivers appropriati, oppure è proprio una questione hardware insormontabile? Con la mia rig io trovo quasi perfetti soltanto Battlefield 3 e Metro Last Light e da quanto ho capito dipende anche dall'ottimizzazione multicore/multigpu dell'engine grafico... es. per AMD su tutti noto parecchi problemi con il vecchio Unreal Engine 3. Con l'UE4 sarà diverso (visto che molti lo usano l'UE, forse perché su Nvidia gira meglio?) ? Chissà... Grazie per eventuale risposta...

Il microstuttering è funzione di diversi fattori, ma possiamo banalizzare il discorso dicendo che questo è molto più facile che si verifichi con configurazioni multi GPU rispetto a quelle a singola GPU.
Detto questo, le cause del microstuttering possono essere varie, riconducibili a GPU, driver video, engine del gioco, funzionamento sistema operativo, configurazione del proprio sistema. L'incidenza del tipo di connessione PCI Express sul microstuttering c'è sicuramente, ma tendo a credere sia così ridotta da poter essere tranquillamente trascurata.
Spero di aver risposto, viceversa chiedi

[Paolo Corsini]

Originariamente inviato da Bivvoz

Grazie.
Mi sono perso a metà però.

In sostanza crea i frame e li scarta prima del rendering e visto che il sincronismo non parte dalla creazione dei frame in realtà non è sincronizzato... una cosa così?

messa così ssembra un po' una
"antani alla prematurata supercazzola"
ma si, diciamo che ci siamo

[D69]

Avrei delle curiosità, a puro scopo personale.... ipotizzando anche di avere un sistema hardware perfettamente identico, siamo davvero sicuri che il risultato ottenuto con lo schermo utilizzato in redazione sia poi quello che può ottenere un qualsiasi utente a casa sua con un'altro schermo, con quella determinata scheda video?

tra le cose che mi vengono in mente, per esempio, i differenti sistemi di overdrive (quando presenti tra l'altro) utilizzati dai produttori di monitor, sto dicendo una bestemmia?

il refresh, questo sconosciuto... 60Hz è quello dichiarato dal produttore ma che non sempre è quello effettivo, in moltissimi schermi il refresh reale è di 59Hz, non è che magari questa variazione potrebbe essere in minima parte responsabile se non settata correttamente, di quei runt frame che guardacaso come pixel, cito quello scritto dalla redazione:

caratterizzati da sviluppo in verticale compreso tra 1 e 20 pixel

... o pura coincidenza? lo stesso dicasi per monitor con refresh 100 e 120 ecc..

per ultimo ma non per ultimo, come già chiesto da altro utente, supponendo di abilitare il vsynch, e quindi poi di andare ad intervenire su tutti gli altri parametri del driver per farlo funzionare a dovere, si risolve il problema dei drop frame? oppure resta una costante?
.... e se sì, resta in punti ben definiti oppure random?

scusate se chiedo troppe cose in un colpo solo, ma sono tutte cose che mi sono frullate in testa leggendo l'articolo e guardando l'intero filmato, come se l'istinto mi dicesse che in realtà questo sistema è sì un ottimo sistema per misurare le prestazioni che si hanno a schermo, ma solo per chi possiede quello schermo, con quell' hardware. Ma forse sto solo prendendo un granchio....

[II ARROWS]

Originariamente inviato da Paolo Corsini

All'atto pratico avresti però moltissimi frame che vengono scartati dalla pipeline di rendering, e molti casi nei quali i frame non vengono visualizzati a 60 Hz ma a 30 Hz in quanto nella pipeline si perde il sincronismo e quindi la frequenza di refresh viene temporaneamente dimezzata per recuperare il divario

Mi permetto di dissentire. Oramai sono ben più di 5 anni che questa teoria non funziona più.
Così come i frame al secondo medi sono su un periodo troppo lungo e quindi siete andati a controllare i singoli tempi di elaborazione, quando si perde un fotogramma non viene dimezzata la frequenza ma semplicemente si scarta quel ciclo...
Quindi se un fotogramma impiega il doppio del tempo, vedremo su schermo 59 frame, invece che 60. Ovvero 59 e uno ripetuto.
Il "passaggio" da 60 Hz a 30 Hz è "istantaneo", ovvero vale solo per quel frame anomalo.

[Paolo Corsini]

Originariamente inviato da II ARROWS

Mi permetto di dissentire. Oramai sono ben più di 5 anni che questa teoria non funziona più.
Così come i frame al secondo medi sono su un periodo troppo lungo e quindi siete andati a controllare i singoli tempi di elaborazione, quando si perde un fotogramma non viene dimezzata la frequenza ma semplicemente si scarta quel ciclo...
Quindi se un fotogramma impiega il doppio del tempo, vedremo su schermo 59 frame, invece che 60. Ovvero 59 e uno ripetuto.
Il "passaggio" da 60 Hz a 30 Hz è "istantaneo", ovvero vale solo per quel frame anomalo.

Mi sono spiegato male, ne deduco, ma intendevo dire proprio questo: il passaggio da 60 a 30 Hz si riferisce allo specifico frame, non all'intervallo di frames inseriti nel secondo. Questo però crea stuttering che è visibile all'occhio del videogiocatore.
Quando trovo tempo faccio qualche misura con Fcat e sicronismo verticale fisso, così da mostrare con dati quanto qui scritto