[Thread Ufficiale] ATi Radeon HD 5850

[Joker80]

Originariamente inviato da Lino P

non capisco perchè non implementarlo nel pannello driver...
Considerate che la massa non si mette a tweakare, sa solo giocare; immaginate l'utente medio che potrebbe avere in un contesto 29 fps, e si ritrova ad averne 15 (attenzione si passa dal giocabile al non).

Hai perfettamente ragione basterebbe metterlo nel pannello dei drive

[Lino P]

Originariamente inviato da Joker80

Hai perfettamente ragione basterebbe metterlo nel pannello dei drive

eh si. il danno è notavole. Ripeto, l'utente medio non ne capisce una fava, e si ritrova col rate dimezzato dal nulla.

[Germano84Blaster]

Originariamente inviato da Lino P

eh si. il danno è notavole. Ripeto, l'utente medio non ne capisce una fava, e si ritrova col rate dimezzato dal nulla.

Cmq un motivo ci deve essere perchè mi sembra che neanche nvidia lo implementie nei driver(entrambe però per le opengl si) chissà qual'è la spiegazione...
Mandiamo una mail ad ati è chiediamoglielo chissà che non ci risponda...

[jok3r87]

Originariamente inviato da Germano84Blaster

Cmq un motivo ci deve essere perchè mi sembra che neanche nvidia lo implementie nei driver(entrambe però per le opengl si) chissà qual'è la spiegazione...
Mandiamo una mail ad ati è chiediamoglielo chissà che non ci risponda...

Perché i giochi per pc programmati con un minimo di criterio hanno l'opzione triple buffering integrata. Tanto per dirne uno recente Dragon Age Origins...

[Knighhell]

info per chi si ritrova con il mio stesso problema

Crysis sembra non partire utilizando exe a 64 bit , o peggio , non fa piu di 10 fps.

il problema si risolve mettendo in compatibilita vista sp2 crysis.exe che si trova nella cartella bin64

Ciao

[EnkiduZ]

Originariamente inviato da Knighhell

il pc non è un palla alpiede
se avvio exe a 32 bit funiona tutto, se avvio quelo a 64 ,, va a 10 fps
con crysys warhead nonsuccede.
Chiedo solo se qualcuno puo fae delel verifiche con crysis usando exe a 64 bit ,
driver 9.12 e patch crysis 1.2.1

io ho crysis 1.2.1 e 9.12 e lo faccio partire a 64 bit al massimo dei dettaggli a 1280x1024... la risoluzione è inferiore certo ma faccio quasi 40 fps fuori e nelle grotte o in posti chiudi 60 fissi.. se aumenti a 1680 non dovrebbe calare così tanto dino a 10 fps.. c'è qualcos'altro...

ps. non lo faccio partire in modalità compatibile...

[Knighhell]

in modalità compatibile funziona tutot bene

qui i test
1600x900 no AA

tutto al max

TimeDemo Play Started , (Total Frames: 2000, Recorded Time: 111.86s)
!TimeDemo Run 0 Finished.
Play Time: 63.81s, Average FPS: 31.34
Min FPS: 12.89 at frame 137, Max FPS: 46.58 at frame 1012
Average Tri/Sec: -10806786, Tri/Frame: -344798
Recorded/Played Tris ratio: -2.66
!TimeDemo Run 1 Finished.
Play Time: 56.06s, Average FPS: 35.68
Min FPS: 12.89 at frame 137, Max FPS: 53.52 at frame 61
Average Tri/Sec: -11768957, Tri/Frame: -329893
Recorded/Played Tris ratio: -2.78
!TimeDemo Run 2 Finished.
Play Time: 56.65s, Average FPS: 35.30
Min FPS: 12.89 at frame 137, Max FPS: 53.52 at frame 61
Average Tri/Sec: -11585422, Tri/Frame: -328179
Recorded/Played Tris ratio: -2.79
!TimeDemo Run 3 Finished.
Play Time: 55.90s, Average FPS: 35.78
Min FPS: 12.89 at frame 137, Max FPS: 53.52 at frame 61
Average Tri/Sec: -11844490, Tri/Frame: -331077
Recorded/Played Tris ratio: -2.77
TimeDemo Play Ended, (4 Runs Performed)

[Germano84Blaster]

Originariamente inviato da jok3r87

Perché i giochi per pc programmati con un minimo di criterio hanno l'opzione triple buffering integrata. Tanto per dirne uno recente Dragon Age Origins...

mmmm... non mi sembra una buona motivazione....
inoltre sono pochi i giochi che hanno questa opzione...
ok noi utenti "esperti" sappiamo come aggirare il problema, ma il 90% della gente che vuole giocare non vedo perchè debba avere queste limitazioni cosi consistenti quando basterebbe una casellina da spuntare nei driver....per questo non mi spiego quale sia il motivo che comunque deve esserci per forza...

[Lino P]

Originariamente inviato da jok3r87

Perché i giochi per pc programmati con un minimo di criterio hanno l'opzione triple buffering integrata. Tanto per dirne uno recente Dragon Age Origins...

non ne conosco altri...

[DrossBelly]

Originariamente inviato da Knighhell

info per chi si ritrova con il mio stesso problema

Crysis sembra non partire utilizando exe a 64 bit , o peggio , non fa piu di 10 fps.

il problema si risolve mettendo in compatibilita vista sp2 crysis.exe che si trova nella cartella bin64

Ciao

Ma quindi hai 7?

[Knighhell]

Originariamente inviato da DrossBelly

Ma quindi hai 7?

si ho seven a 64 bit

[Knighhell]

Introduzione



Eppure, a volte spendere molti soldi in una scheda e in un monitor nuovi non è diretta garanzia di un'esperienza videoludica appagante. Avere tanti FPS nominali non vi farà fare i salti di gioia, se contemporaneamente dovrete fare i conti con qualche difetto di visualizzazione.

E' in questi casi che le impostazioni grafiche possono fare la differenza tra i soldi spesi bene e un acquisto che non invece non soddisfa come avrebbe dovuto. Vediamo quindi la differenza che può fare un settaggio ottimale di parametri come il v-sync, il triple buffer, e il loro stretto rapporto con il refresh del monitor nel garantire una resa a video ottimale.

Agli appassionati di videogames questi termini non sono certo nuovi.

Gli Hertz del monitor e gli FPS che la scheda video è in grado di generare hanno sicuramente qualcosa in comune: the higher, the better. Più sono e meglio è.

Ma vediamo in dettaglio come questi due valori interagiscono tra loro nella pratica quotidiana.


Il Refresh

Ogni monitor CRT ha una frequenza di aggiornamento, espressa in Hertz, per ogni risoluzione da esso supportata. Il monitor disegna lo schermo partendo dall'angolo in alto a sinistra e spostandosi, pixel dopo pixel, fino a quello di destra. Poi "va a capo" alla riga sottostante, procedendo così, linea per linea, fino alla fine dello schermo. Quando l'ultima riga in basso a destra è stata disegnata, il flusso di elettroni viene riportato nell'angolo alto a sinistra, e un nuovo fotogramma (frame) viene disegnato. Il numero di volte che questa operazione viene effettuata in ogni secondo viene definito refresh rate, cioè la frequenza di aggiornamento del monitor.

Se ad esempio il nostro monitor è in grado di funzionare a 100Hz alla risoluzione di 1024x768, ciò significa che è in grado di visualizzare fino a 100 fotogrammi al secondo. "Fino a" significa che è certamente possibile impostarne meno, ma questa operazione non avrebbe senso. I refresh più lenti (ad esempio 60 Hz) provocano infatti maggiore stanchezza al nostro apparato visivo: lavorare su un monitor a 100Hz è sicuramente più riposante che utilizzarlo a 60Hz; ragion per cui è meglio impostare il refresh sempre al massimo consentito per la risoluzione a cui è impostato il monitor.


E gli LCD?

Tecnicamente, sarebbe improprio parlare di refresh negli LCD a matrice attiva, dato che l'immagine viene disegnata cambiando colore ai singoli pixel soltanto quando questi mutano, anziché tracciandoli sempre e comunque riga dopo riga.

Questa differenza fondamentale rispetto al CRT li rende riposanti per gli occhi anche a refresh bassi (tanto che molti LCD in commercio hanno frequenze fisse di 60Hz).

Se vi state chiedendo che senso abbia parlare di refresh per dispositivi che in realtà non effettuano nessun aggiornamento dell'immagine quando questa non cambia, eccovi subito ana risposta ragionevole: la frequenza di refresh funge anche da parametro di comunicazione tra il monitor e la scheda video.

Vediamo come.


Frames nominali e frames effettivamente percepiti


Nel paragrafo precedente si è detto che il massimo numero di fotogrammi al secondo REALMENTE visualizzati dal monitor corrisponde alla frequenza di refresh impostata per la risoluzione che si sta utilizzando. Se il monitor è impostato a 85Hz, ai vostri occhi verranno sottoposte al massimo 85 "schermate" al secondo, e questo indipendentemente dal numero di fps generati in quel preciso momento dalla scheda video.

Vediamo qualche esempio.

Frames elaborati (FPS) Refresh ( Hz) Frames Percepiti
192 85 85
85 85 85
22 85 22




Senza perderci in discorsi di fotogrammi al secondo che l'occhio umano può percepire o distinguere, ciò che ci interessa qui è che la frequenza di refresh stabilisce la soglia massima oltre il quale tutta la "fatica" della vostra scheda video non avrà alcun riscontro visivo, fatti salvi ovviamente i punti ottenibili in qualche benchmark.

Per dirla con una frase di Tim Sweeney (Epic Games): "There is no visual benefit to having a game render more frames per second than your monitor is displaying" (trad.: "non vi è alcun beneficio visivo nel generare più fotogrammi al secondo di quelli che il vostro monitor sta mostrando").


Ovviamente le cose staranno diversamente a ruoli invertiti, e cioè quando in una determinata scena la scheda video starà producendo meno di 85 fps, sempre assumendo che questo sia il valore di refresh impostato per il monitor. In tale situazione, e soprattutto sotto i 60 fps, la percezione di fluidità inizierà a risentirne; sotto i 30, poi, faranno la loro comparsa i famigerati "scatti", e l'esperienza videoludica ne risulterà pesantemente compromessa.

Ora… lasciando da parte quello che è un limite puro della scheda video, e che cessa di esistere con l'acquisto di una scheda più potente, concentriamoci qui su ciò che di strano si verifica quando la scheda è così potente da creare problemi; quando cioè produce più fps di quelli che il monitor sia effettivamente in grado di visualizzare.



Frame Buffer, Back Buffer e Tearing Effect


Quando il monitor deve cominciare il suo "lavoro" di visualizzazione, abbiamo detto, lo fa partendo dall'angolo in alto a sinistra. Ma quali dati utilizza il monitor per stabilire cosa visualizzare?

I dati contenuti nel Frame Buffer.


Il Frame Buffer è quello spazio di memoria video riservato a contenere l'immagine che il monitor si farà poi carico di visualizzare. In tale spazio finirà quindi il frame generato dalla scheda video, che verrà così pescato dal monitor durante il suo lavoro di visualizzazione.

Se il Frame Buffer è quindi dedicato al monitor, il cosiddetto Back Buffer è il suo corrispondente dedicato alla scheda video: una porzione di memoria di cui la scheda si serve per scrivere l'immagine nell'istante stesso in cui la elabora, in modo da darla in pasto al Frame Buffer, e in sintesi al monitor, solo una volta che sarà completata, al termine quindi dell'elaborazione.

In sintesi, la scheda video elabora ogni singolo frame nel Back Buffer, spostandolo poi nel Frame Buffer per permettere al monitor di leggerlo.

Questo sistema prende il nome di Buffering Doppio.


Ma cosa succede se lo spostamento dell'immagine dal Back Buffer al Frame Buffer avviene nel momento sbagliato, e cioè mentre il monitor non ha ancora terminato la visualizzazione del contenuto del Frame Buffer, che sta quindi per essere – verrebbe da dire "ingiustamente" – sostituito?

Questo caso, tipico delle situazioni in cui la scheda video genera fps ad un ritmo molto più sostenuto di quello del refresh del monitor, dà luogo ad uno spiacevole artefatto conosciuto con il nome di Tearing Effect: il monitor visualizza la parte alta di un frame, e la parte bassa di quello successivo.

Nei casi peggiori, in cui il rapporto fps/refresh risulti molto elevato (es: 250 fps su un monitor a 75 Hz), addirittura le porzioni di 3 o 4 frames consecutivi potrebbero essere visualizzate contemporaneamente sullo schermo.



Il risultato è che l'immagine a video appare "strappata" orizzontalmente, e nel caso l'azione sia particolarmente frenetica o vi siano frequenti spostamenti orizzontali di visuale (tipico dei giochi in soggettiva), questo spiacevole effetto può diventare letteralmente insopportabile, in particolare quando la scena ne è afflitta in modo cronico, su più frames consecutivi, con fastidiosa continuità.


Ci sarà mai una soluzione? Ovviamente si.



V-Sync: la sincronizzazione verticale


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 5900 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)!


Bene.

Ora che sapete quanto crudele possa essere il mondo della computer grafica, siete pronti per un sistema a Buffering Triplo.



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.

[Danziga88]

Originariamente inviato da Knighhell

Introduzione
...cut...

non era meglio mettere il link?

[Drakogian]

Originariamente inviato da Ellyk0

Ciao a tutti.
A breve mi arriverà anche me qusta schedina dopo aver trovato un buon affare. Volevo sapere se il k7 ybris è compatibile. Attualmente lo sto usando su una hd 4850. I fori per il wb non sono uguali?

I fori al 90% dovrebbero essere uguali. Catan ha montato un ybris acs-g senza problemi.
Puoi leggere il suo test qui: http://www.pctuner.net/forum/tuner-w...ml#post1722228

[lbatman]

Originariamente inviato da Drakogian

I fori al 90% dovrebbero essere uguali. Catan ha montato un ybris acs-g senza problemi.
Puoi leggere il suo test qui: http://www.pctuner.net/forum/tuner-w...ml#post1722228

Confermo!

Arrivo proprio da quella recensione di Catan... splendido dissy, anche e soprattutto per chi, come me, sarebbe moooolto tentato di metterla subito a liquido con lo stesso WB OcLabs che ora raffredda la 4850!!!!!

[Ellyk0]

Si quel test l'avevo letto... adesso non mi rimane che sperare che i fori del ybris acs-g siano uguali al k7...
Vedremo. Anche se poi vista la silensiosità di cui tutti parlano aspetterò almeno qualche giorno prima di metterla a liquido.

[lbatman]

Originariamente inviato da Ellyk0

Si quel test l'avevo letto... adesso non mi rimane che sperare che i fori del ybris acs-g siano uguali al k7...
Vedremo. Anche se poi vista la silensiosità di cui tutti parlano aspetterò almeno qualche giorno prima di metterla a liquido.

Si, infatti...pare sia un OTTIMO dissipatore con una ventola silenziosissima.... però, avendo l'impianto a liquido....aspetteremo proprio SOLO qualche giorno!!!

PS: io mi sono autocostruito una staffa per l'OcLabs Monoblock, che ho già passato dalla 8800 GTS 640 alla 4850, facendo solo due fori (o quattro?! ) in più.... e alla peggio (sempre che il core non sia più grande dei due citati (ora controllo...) devo ricostruire una nuova staffa!

[Drakogian]

Originariamente inviato da lbatman

Confermo!

Arrivo proprio da quella recensione di Catan... splendido dissy, anche e soprattutto per chi, come me, sarebbe moooolto tentato di metterla subito a liquido con lo stesso WB OcLabs che ora raffredda la 4850!!!!!

La cosa buona è che è riuscito a mantenere la piastra originale per il raffreddamento delle memorie e della sezione alimentatrice:

[Knighhell]

ritornando al triple buffering

credo che i driver dell ati o windows 7 lo attivano in automatico,
non sto usando nessun tool di 3 party

metto il v-sync nei giochi utilizzo fraps per monitorar egli fps

crysis, ghost recon 2, e splinter cell

a volte gli fps scendono sotto 60 ( il mio monitor ha 60 Hertz) ,
ma si mantenogono su valori che sono sopra 30 , tipo 55 , 48 .

Ne deduco che il Tb funziona , perche altriemnti dovrei andare a 30

Giusto ??

[Ellyk0]

Originariamente inviato da Drakogian

La cosa buona è che è riuscito a mantenere la piastra originale per il raffreddamento delle memorie e della sezione alimentatrice:

Infatti è proprio quello il bello... pensa che quasi un hanno fa per andare a raffreddare i mosfet con piccoli dissi in rame, 2 mi hanno fatto contatto e puff... fumata bianca.