alexcyber ha scritto:

Basta che usi quello del pannello Nvidia.

Non sere forzare il tiple buffering se non usi il Vsync.

grazie per aver condiviso tutte queste info! avrei due domande

- uso i forceware ver 186.18, per abilitare il triple buffering con il vsync su giochi directX serve ancora usare utility tipo d3doverrider? perche ho visto che nel pannello di controllo si può impostare, però forse non ha effetto, è corretto?

- forzare il tiple buffering senza vsync porta a miglioramento delle prestazioni dei giochi?

grazie

Se il problema è il momento in cui il contenuto di un buffer viene copiato nell'altro, la soluzione si profila semplice: aspettare il momento opportuno per effettuare tale operazione, vale a dire il momento in cui il monitor è arrivato a disegnare l'ultimo pixel di un frame ma non ha ancora iniziato a tracciare il frame successivo. Nei CRT, è quella frazione di secondo in cui il fascio di elettroni viene riportato in alto a sinistra per poter ricominciare; negli LCD, è semplicemente l'istante che separa un frame dall'altro.

L'eliminazione del Tearing si ottiene quindi abilitando il V-Sync, cioè sincronizzando i tempi della scheda video con quelli del monitor.

Con la sincronizzazione verticale abilitata, la scheda video aspetterà che il monitor finisca di disegnare un frame, prima di elaborare quello successivo. Questo eviterà che nel Frame Buffer vi sia parte di un frame e parte di un altro (cioè che si verifichi il fenomeno del Tearing). Tutto risolto, allora?

No, poiché assisteremo ad un paio di effetti collaterali:

• Gli fps generati dalla scheda non saranno mai più alti della frequenza di refresh, dato che la scheda aspetta letteralmente il monitor, e ne è in un certo senso schiava. Ciò non ha la minima importanza per il nostro occhio, come abbiamo appurato parlando di refresh, ma incide sui benchmark, che non rileveranno mai picchi di fps più alti del valore di refresh impostato: il V-sync è quindi da disabilitare in questi contesti.
  
• Nei casi in cui gli fps generati dalla scheda siano inferiori agli Hz del monitor, si assiste ad una sostanziale perdita di fps, che a volte si trasforma in un crollo vero e proprio. E tra poco ne vedremo il motivo.
  

Abbiamo visto che fps troppo elevati rispetto al refresh possono causare tearing, e che il problema è aggirabile non permettendo alla scheda di elaborare più fps di quelli che il monitor può visualizzare. Ma cosa succederebbe ora nel caso opposto, cioè in tutti quei momenti in cui gli fps potrebbero essere inferiori alla soglia del refresh del monitor?

Ecco un esempio pratico.

Poniamo di avere un refresh di 75 Hz e di trovarci in un particolare punto del gioco in cui la nostra scheda riesce ad elaborare soltanto 50 fps, cioè il 33% in meno del valore di refresh del monitor. Ciò equivale a dire che nell'arco di tempo in cui il monitor aggiorna lo schermo, la scheda è in grado di produrre solo 2/3 del frame successivo. Vediamo quindi come si traduce tutto ciò in real-time, vale a dire un frame dopo l'altro:

• Il monitor sta per iniziare un refresh, e il contenuto del Back Buffer – che chiameremo FRAME A – viene copiato nel Frame Buffer. Il monitor a questo punto si dedica alla visualizzazione del FRAME A.
  
• Quando il monitor termina l'operazione col FRAME A, la scheda nel Back Buffer avrà elaborato solo 2/3 del frame successivo – FRAME B – che quindi non sarà ancora pronto per essere copiato nel Frame Buffer. Il monitor, che non può attendere, visualizzerà quindi nuovamente il FRAME A, ancora contenuto nel Frame Buffer che non è stato aggiornato. Otteniamo perciò che il monitor starà visualizzando per la seconda volta consecutiva il FRAME A.
  
• La scheda video termina finalmente il FRAME B, ma per poterlo copiare nel Frame Buffer deve attendere che il monitor finisca di visualizzare (per la seconda volta, appunto) il FRAME A. Solo a quel punto copia il FRAME B nel Frame Buffer.
  
• Il monitor procede col suo terzo refresh, mostrando finalmente il FRAME B. La scheda nel frattempo inizia a generare il FRAME C nel Back Buffer, che però non sarà terminato ancora in tempo (sarà ancora elaborato solo per 2/3) entro il prossimo refresh.
  
• Il monitor si trova nella stessa condizione del punto 2, e quindi ripropone il FRAME B per la seconda volta. Solo al refresh successivo (il quinto in totale) potrà visualizzare il FRAME C. Siamo qui nella identica condizione del punto 1, che innesca quindi un loop in cui verranno visualizzati solamente la metà dei frames effettivamente elaborati dalla scheda.
  

Tirando ora le somme: ogni 4 cicli di refresh il monitor visualizzerà solo 2 frames diversi (nel senso di frames elaborati singolarmente dalla scheda video), cioè la metà esatta. Per quantificare la perdita di fps che il V-Sync ha causato, dobbiamo ricordarci che ogni secondo questo monitor aggiorna 75 volte: abbiamo quindi che 75/2 = 37.5 frames effettivamente visualizzati, contro i 50 che la scheda sarebbe stata in grado di generare col V-Sync disabilitato.

Il V-Sync ci costa in questo caso ben il 25% del potenziale della scheda.

La perdita è certamente variabile, secondo il refresh e il carico della scheda video in ogni determinato momento (anche nell'arco di un secondo le condizioni possono variare sensibilmente). Se in alcuni istanti può essere accettabile e trattarsi di una manciata irrilevante di frames, in altri può portare a scattare anche schede video che altrimenti garantirebbero framerates mediamente alti.

Pensate ad esempio di veder crollare una 6800 GT davanti a un Sony Trinitron da 120Hz! Uno stipendio intero dilapidato per due oggetti che non riescono a garantirvi una resa decente, sia col V-Sync disabilitato (quando la scheda supera i 120 fps assistete al Tearing), sia col V-Sync abilitato (appena la scheda scende sotto ai 120 fps, vi capita che gli fps si dimezzino inspiegabilmente)!

Il Triple Buffer

Sappiamo ora quali dinamiche possano instaurarsi tra il Back Buffer, dedicato alla scheda video, e il Frame Buffer, destinato al monitor. E sappiamo anche che, sincronizzati o meno, questo sistema a due buffer porta con sè degli effetti indesiderati. Questi effetti però possono essere radicalmente eliminati affiancando loro un terzo buffer, sempre dedicato alla scheda video, che verrà utilizzato da quest'ultima nei tempi di attesa in cui monitor e scheda non viaggiano con lo stesso passo, evitando così alla scheda di fermare l'elaborazione per aspettare il monitor quando la sincronizzazione verticale è attiva.

Vediamolo meglio riprendendo l'esempio del paragrafo precedente, dove il monitor era impostato a 75 Hz con la scheda video in grado di elaborare 50 fps al secondo. Ora avremo che:

• Il monitor sta per iniziare un refresh, e il contenuto del Back Buffer – che chiameremo FRAME A – viene copiato nel Frame Buffer. Il monitor a questo punto si dedica alla visualizzazione del FRAME A.
  
• Quando il monitor termina l'operazione col FRAME A, la scheda nel Back Buffer avrà elaborato solo 2/3 del frame successivo – FRAME B – che quindi non sarà ancora pronto ad essere copiato nel Frame Buffer. Il monitor, che non può attendere, visualizzerà quindi nuovamente il FRAME A, ancora contenuto nel Frame Buffer che non è stato aggiornato. Otteniamo perciò che il monitor starà visualizzando per la seconda volta consecutiva il FRAME A.
  
• La scheda termina il FRAME B nel Back Buffer, ma invece di attendere "a braccia conserte" che il monitor termini il refresh, comincia ad elaborare il nuovo frame – FRAME C – nel Terzo Buffer. Sapendo che la scheda disegna 2/3 di ogni frame al secondo, in questo intervallo di tempo riesce sia a completare il FRAME B nel Back Buffer, sia a disegnare 1/3 del FRAME C nel buffer supplementare.
  
• Il monitor termina la (doppia) visualizzazione del FRAME A. Il contenuto del Back Buffer, cioè il FRAME B, viene copiato nel Frame Buffer, pronto per essere visualizzato dal monitor al prossimo refresh. Il contenuto del Terzo Buffer, cioè 1/3 del FRAME C, prende il suo posto nel Back Buffer.
  
• Quando il monitor termina la visualizzazione del FRAME B, la scheda ha elaborato i 2/3 mancanti del FRAME C, che ora è perfettamente in sincronia col monitor e può essere spostato nel Frame Buffer.
  
• Mentre il FRAME C viene visualizzato, la scheda elaborerà 2/3 del FRAME D, ristabilendo la situazione al punto 2: inizia qui il loop.
  

Partendo dalla constatazione che il punto 1 non si verificherà mai più, e la sequenza ciclica sarà quella tra il punto 2 e il punto 6, abbiamo quindi che il monitor visualizzerà 2 frames ogni 3 refresh: in altre parole, 50 fps esatti ogni 75 Hz: la stessa condizione su cui abbiamo costruito l'esempio.

Al contrario della configurazione a buffering doppio, abbiamo quindi che la scheda video venga qui sfruttata al 100% delle sue potenzialità.

E se abilitassimo il Triple Buffer disattivando il V-Sync?

In quel caso, bentornato Tearing!

La scheda infatti, non dovendo obbedire a nessuna regola che le impone quando copiare il Back Buffer nel Frame Buffer, effettuerà l'operazione appena possibile, cioè ogni volta che un frame nel Back Buffer sarà pronto. Il Terzo Buffer, insomma, non sarà mai utilizzato, poiché appena svuotato il Back Buffer la scheda ricomincerà a scrivere ancora lì dentro il prossimo frame.

L'abilitazione del Buffering Triplo senza il contemporaneo utilizzo del V-Sync sarebbe perciò, a conti fatti, praticamente inutile.

Anche il Triple Buffer si paga.

Sapendo che ogni buffer è in pratica uno spazio di memoria dedicato, avere un buffer supplementare comporta l'utilizzo di maggiore memoria video per l'elaborazione, spazio che va quindi a non essere più disponibile per i programmi (giochi) in esecuzione. L'effetto collaterale è che se la memoria video si esaurisse del tutto, la scheda inizierebbe a swappare tra questa e la memoria di sistema, perdendo così del tempo che potrebbe invece dedicare all'elaborazione, causando quindi una nuova perdita di performance.

Facendo i conti, però, ci accorgiamo che la situazione potrebbe diventare effettivamente critica solo con schede che al giorno d'oggi risultano già essere particolarmente inadatte al gaming.

Ad una risoluzione di 1024x768, con una profondità di colore di 32 bit, sarebbero infatti 3.145.728 i bytes in più che verrebbero richiesti da un buffer supplementare (3 mega circa).

Conoscendo gli enormi quantitativi di memoria montati sulle schede odierne , potremmo tranquillamente definire irrisorio il costo di un terzo buffer, e l'opportunità di disabilitarlo per guadagnare un po' di ram video resta quindi limitata a schede con quantitativi ormai davvero bassi di memoria onboard (meno di 32 mega), generalmente già superate dai requisiti stessi dei giochi attuali.

Resta un ultimo quesito da affrontare: è così semplice abilitare il Triple Buffer?

Si, in OpenGL.

No, in Direct3D.

Questo perché le api Microsoft non permettono all'utente un settaggio manuale dell'opzione, che di default è disabilitata, ed è quindi necessario intervenire sulle tali api con un tweaker.

Per abilitarlo in OpenGL è invece sufficiente checkare la relativa opzione dal pannello dei drivers della vostra scheda video, Es: Pannello scheda video ATI o Nvidia.

Il Tweaker che al momento permette l'hack dei parametri è D3D Overrider presente nell'ultima versione di Rivatuner 2.24.

Download:

http://downloads.guru3d.com/downloadget.php?id=163&file=4&evp=bf816a7ebeb8be5756bc7742a4d915cb

La mia configurazione è questa: Cpu Intel Core Duo E6750, Ram 2gb da 800 Mhz, Scheda Video Geforce 8800 gtx, Hard disk Raptor 10000 Rpm, Windows xp 32 bit.

Sto giocando a un vecchio gioco di guerra ( Call of Duty 1) con tutti i filtri attivati e con tutte le patch e i driver aggiornati. Sono a metà dell'avventura ed ho riscontrato un calo di frame in una particolare zona del livello. Misurando con fraps, ho visto che i frame, disattivando il v-sync, mi vanno da 250 a 90 (non appena arrivo in quel punto) mentre con v-sync attivato e triple buffer mi arrivano da 60 a 50 (sempre in quel punto). La mia domanda è questa: se è vero che il v-sync limita i fps a 60, perchè scendono a 50 sapendo che la scheda nella condizione peggiore è arrivata a 90 (senza v-sync). Cioè si il v-sync attivato la porta a 60 però non doveva scendere al di sotto di questo valore visto chè è in teoria è in grado di farne 90. So che mi sto intrippando un pò ma è giusto per capire il funzionamento. Grazie

samonosuke ha scritto:

Figurati.

Se hai altri problemi, "speriamo di no per te":asd:...siamo qui.

samonosuke ha scritto:

Si esattamente. Devi abilitare il triple buffering per andare a 50 fps.

dj883u2 ha scritto:

Grazie, ma questo (cioè che riesco ad andare a 50fps) avviene solo se imposto il triple buffering,giusto? perchè ho sentito dire che se i frame generati dalla scheda video sono inferiori agli hertz del monitor (quindi 50 fps inferiori ai 75 hertz del monitor) e non vi è l'opzione triple buffering si crea un dimezzamento dei frame di 1/2 1/3 ecc, cioè (non appena i frame vanno al di sotto dei 75 hertz) si passa ad esempio da 75 a 35 a 25 ecc (e quindi non riesco andare più a 50fps). Volevo giusto una conferma se è giusto tutto ciò o se ho capito male.

Grazie

Se invece il gioco ti fa 50 fps anche se hai abilitato il V-Sync ed impostando gli Hz del monitor Crt a 75hz farai 50 fps.

Quello che mi chiedevo io è questo: Se abilito il V-sync e il triple buffering (impostando gli Hz del monitor Crt a 75hz) e metto un gioco pesantuccio che mi fa andare a 50fps, in questo caso si creerà un ulteriore dimezzamento dei frame (dovuto al fatto che gli fps generati dalla scheda a causa del gioco pesante siano inferiori agli Hz del monitor , comeme abbiamo detto 75), oppure visto che è attivo il triple buffering il gioco mi andrà a 50 fps senza un'ulteriore dimezzamento dei fps?

Vi prego rispondetemi. Grazie