ATI Radeon HD 5870: la prima scheda video per DirectX 11

[Pr|ckly]

Originariamente inviato da okorop

Physix è solo una mossa commerciale ben fatta, ma per il resto serve a poco.....

Pratica commerciale di sicuro ma quello che sta dietro al Physx è il futuro.

[okorop]

Originariamente inviato da Pr|ckly

Pratica commerciale di sicuro ma quello che sta dietro al Physx è il futuro.

Physx non è il futuro, la fisica che useranno le prossime console a mio avviso è il futuro sperando che adottino le dx11 e open cl.....

[Horizont]

Originariamente inviato da Futura12

La top di gamma a 320€ non è assolutamente costosa,anzi lo definirei ''prezzo-regalo''

io ancora non riesco ad entrare nel discorso "top di gamma" che top di gamma sarebbe la 5870??...top di gamma in una gamma fatta di 2 vga?

[ndrmcchtt491]

Originariamente inviato da Pr|ckly

La tessellation è una specifica introdotta con le Dx11, niente di privato/esclusivo, con G300 sarà supportato anche da nVidia.

Ps, usa il tasto quote quando rispondi, altrimenti diventa impossibile leggerti.

Scusa/te, ma rispondevo direttamente sui commenti della news

[yossarian]

Originariamente inviato da MiKeLezZ

standard de che? è solo l'implementazione corretta come definita dalle api dx 11 di microsoft

la parola giusta è "dx 11 complaint", ovvero aderisce alle specifiche definite dalle dx 11 di microsoft

il termine giusto è dx11 full compliant.

Originariamente inviato da MiKeLezZ

physx invece è un middleware, cioè il confronto va fatto con le dx 11 al limite (al limite, visto che una svolge un ruolo, l'altra un altro)

stiamo confrontando fagiolini di campo con bistecche di manzo

peccato che gli "standard", di fatto, li definisca microsoft e non nVidia

Originariamente inviato da MiKeLezZ

fra l'altro tutti i simpatici acquirenti delle generazioni passate di ati, in cui c'era il tesselation (es. 2900, 3870 4870), possono farci il brodino visto che ha una implementazione non corretta

così come fecero quelli con truform

è un'implementazione non dx11 full compliant, non un'impplementazione non corretta. C'è una differenza notevole tra le due cose, anche in virtù del fatto che il tessellator della serie 4xx0 differisce da quello della serie 5xx0 solo per l'assenza di stadi programmabili dedicati. Per il resto è perfettamente identico e ugualmente programmabile

Originariamente inviato da MiKeLezZ

al contrario di chi invece si è comprato una nvidia g80 ben 3 anni fa, senza che physx esistesse ancora, e tutt'ora ci gioca con le ultime implementazioni del motore physx

e addirittura un surrogato delle dx 10.1 ... vedi far cry 2

ma anche no

[DjLode]

Originariamente inviato da yossarian

il termine giusto è dx11 full compliant.

Ma ha ancora senso parlare di compliant e full compliant? Microsoft con le DX10 non aveva annunciato di voler dare un taglio a queste "diciture" e quindi di accettare solo gpu che ricoprono tutte le caratteristiche necessarie alle DX10 e 11?
Perchè per le 8 e le 9 c'era stato un gran bel casino con caratteristiche necessarie e non. Esistono (o meglio potrebbero esistere) gpu compliant (set minimo di funzioni supportate) e full compliant (tutte supportate)? O parlavi solo della tasselation? Oppure sono io che ho frainteso la differenza tra full e solo compliant?

[ReDeX]

Originariamente inviato da Horizont

io ancora non riesco ad entrare nel discorso "top di gamma" che top di gamma sarebbe la 5870??...top di gamma in una gamma fatta di 2 vga?

Dai tempo al tempo, fra un anno ci saranno n-mila schede HD5xxx.

[yossarian]

Originariamente inviato da DjLode

Ma ha ancora senso parlare di compliant e full compliant? Microsoft con le DX10 non aveva annunciato di voler dare un taglio a queste "diciture" e quindi di accettare solo gpu che ricoprono tutte le caratteristiche necessarie alle DX10 e 11?
Perchè per le 8 e le 9 c'era stato un gran bel casino con caratteristiche necessarie e non. Esistono (o meglio potrebbero esistere) gpu compliant (set minimo di funzioni supportate) e full compliant (tutte supportate)? O parlavi solo della tasselation? Oppure sono io che ho frainteso la differenza tra full e solo compliant?

in questo caso specifico è riferito al tessellator, in quanto la serie 4xx0 eccede le specifiche dx10.1 sia per quello che per altre feature tipiche delle dx11; in particolare, il tessellator di RV770 differisce da quello di RV870 solo per l'assenza di hull shader e domain shader, il cui compito è svolta rispettivamente dai vertex shader e dai geometry shader (è la parte programmabile); per il resto, ovvero per la componente ficed function, i due chip hanno le stesse identiche unità; quindi la differenza sta solo nel tipo di chiamata utilizzata non nelle funzionalità del tessellator.
Più in generale, ha ancora senso parlarne, in quanto le dx11 sono un superset delle 10.1 che dovevano essere le dx10 originali. Anche in quel caso, la confusione c'è stata, tanto che ci sono chip dx10 e chip dx10.1. In pratica, per risolvere il problema (di termini), la dicitura full compliant è stata sosituita da una nuova versione delle api. E' un po' quello che è successo ripetutamente negli ultimi anni, con le dx8 e le dx8.1, le dx9 sm2.0 e 3.0, ecc.

[DukeIT]

Originariamente inviato da Horizont

io ancora non riesco ad entrare nel discorso "top di gamma" che top di gamma sarebbe la 5870??...top di gamma in una gamma fatta di 2 vga?

Guarda che le VGA della serie HD4xx0 non sono uscite di produzione e sono tutt'ora in vendita... mi sembra anche siano più di due...

[appleroof]

Ho letto al volo la rece di hwupgrade e queste sono le mie considerazioni: per le prestazioni, mi aspettavo qualcosa in più ma insomma non ho avuto vere sorprese rispetto alle mie aspettative nè in peggio nè in meglio, sarà bello vederla all'opera con i giochi dx11, magari con tassellation...ma temo che per quel momento avremo la seconda gen di vga dx11

considero eccellente il lavoro sui consumi (i 40nm pagano ) finalmente vedo consumi in idle come si deve, una delle pecche più grosse di rv770...insieme all'altra che è la rumorosità: già la 5870 reference mostra un dissi da questo punto di vista finalmente all'altezza di quelli reference Nvidia, finora secondo me i migliori tra quelli reference

sempre dal punto di vista della dissipazione, non vedo però nella rece di hwupgrade alcun riferimento alle temp, non vorrei che silenziosità faccia rima con fornetto, cercherò in altre rece

[appleroof]

Originariamente inviato da michelgaetano

cut


I drivers sono acerbi ed è normale che vi debbano lavorare, cosa che significa ulteriori prestazioni

cut

visto che è la stessa architettura di rv770, e che Vista ormai è tre anni che è fuori, non credo proprio sarà rilevante come in altre occasioni, questo fattore...

[DukeIT]

Se i consumi sono più bassi è molto probabile lo sia anche la produzione di calore (e quindi più facile riuscire a dissiparlo con minor produzione di rumore)

[kliffoth]

Originariamente inviato da yossarian

i...E' un po' quello che è successo ripetutamente negli ultimi anni, con le dx8 e le dx8.1, le dx9 sm2.0 e 3.0, ecc.

non c'entra molto, ma visto che sei ferrato...

Che sono questi problemi di sincronia in configurazioni CF o SLI???

http://forum.beyond3d.com/archive/in...p/t-47683.html

un esempio tra molti

e ancora pià chiaro qui:
http://forums.anandtech.com/messagev...readid=2178762

WHAT 30 FPS SHOULD LOOK LIKE (single GPU)

Frame, Time (ms)
1, 0.000
2, 33.3
3, 66.6
4, 99.9
5, 133.2

WHAT 30 FPS DO LOOK LIKE WITH SLI/CROSSFIRE
Frame, Time (ms)
1, 0.000
2, 12.1
3, 68.3
4, 80.5
5, 136.8

Every odd frame number takes much less than the expected 33.3 ms to update and every even frame takes much longer to update.
In this example, every even frame takes around 56.5 ms to update, which is almost 70% longer than expected!
The frame rate says ~30 FPS, but in reality every second frame is updated with a rate of only ~17.8 FPS!

e ancora qui http://www.pcgameshardware.de/?article_id=631668 (tecnico. c'è anche un bel video con fraps che mostra il crollo frames)
e qui http://www.forum-3dcenter.org/vbulle...d.php?t=371844

[yossarian]

Originariamente inviato da kliffoth

non c'entra molto, ma visto che sei ferrato...

Che sono questi problemi di sincronia in configurazioni CF o SLI???

http://forum.beyond3d.com/archive/in...p/t-47683.html

un esempio tra molti

e ancora pià chiaro qui:
http://forums.anandtech.com/messagev...readid=2178762

WHAT 30 FPS SHOULD LOOK LIKE (single GPU)

Frame, Time (ms)
1, 0.000
2, 33.3
3, 66.6
4, 99.9
5, 133.2

WHAT 30 FPS DO LOOK LIKE WITH SLI/CROSSFIRE
Frame, Time (ms)
1, 0.000
2, 12.1
3, 68.3
4, 80.5
5, 136.8

Every odd frame number takes much less than the expected 33.3 ms to update and every even frame takes much longer to update.
In this example, every even frame takes around 56.5 ms to update, which is almost 70% longer than expected!
The frame rate says ~30 FPS, but in reality every second frame is updated with a rate of only ~17.8 FPS!

e ancora qui http://www.pcgameshardware.de/?article_id=631668 (tecnico. c'è anche un bel video con fraps che mostra il crollo frames)
e qui http://www.forum-3dcenter.org/vbulle...d.php?t=371844

è stato usato il double buffering?

Se ci fai caso, non c'è alcuna differenza tra frame pari e dispari.
Leggi i dati in questo modo:
inizio elaborazione (start)
frame dispari (tempo 0 perchè già contenuto nel frame buffer)
frame pari (tempo molto inferiore a quello della singola gpu perchè mentre la prima ha riempito il suo fb con la prima immagine dispari, la seconda ha fatto altrettanto con la prima pari, quindi il tempo è solo quello necessario a trasferire l'immagine dal fb al monitor).
fine elaborazione (stop) per i primi due frame

start
frame dispari
frame pari
stop

in quest'ottica, la differenza tra due frame successivi è pari a circa 68, 5 ms sia che si tratti di frame pari che dispari), che è, all'incirca, il tempo che intercorre tra due immagini successive (pari o dispari) anche in single gpu.
Quindi, il problema è il tempo impiegato a eseguire la operazioni di stop e start, ovvero a inizializzare le successive elaborazioni.
In questo modo, il vantaggio dello sli o del cf si ha solo sul totale delle due operazioni (ovvero la pari arriva un po' prima) ma non sul delay time tra due operazioni successive sulla singola gpu che, anzi, si allunga.
Se non è stato usato il double o il triple buffering, la risposta è presto data, latrimenti è un problema intrinseco a questo modo di gestire il multigpu.

[killer978]

Originariamente inviato da DarkVampire

mmm..che dire...la nuova scheda certo e' buona, il netto vantaggio sulla 285 e' netto...sarebbe stato un disastro se nn lo fosse stato..il dual gpu della stessa ati e' superiore (e quindi nn si e' superata)il confronto e' con una 295..che sono 2 gpu della 260...immagino quanto uno sli di 285 stracci la singola 5xxx, ma fare questi paragoni e' inutile..del resto e' una nuova scheda...che attualmente si pone nella fascia top di gamma di tutte le vga a singola scheda

ma aspettiamo la nuova nvidia e poi ne riparliamo...se segue sempre la solita filosofia vga nuova=potenza superiore a uno sli delle piu' potenti precedenti...allora continuera' stracciarla (parlando sempre di singola gpu ovviamente)...e ati tornera' cmq e sempre a far parte di un mercato di fascia media medio/alta e a raggiungere/superare nvidia solo con un crossfire.

l'idea di farla uscire gia' da adesso e' una buona trovata..visto che si accaparrera' una buona fetta di mercato, finche' nvidia nn si decide a far debuttare il gt300...ottimi i consumi in idle cmq..ma le temp?

tra l'altro e' orrenda da vedere XD

Bisognerebbe fare un plauso ad ATI xche in un chippettino di 330mm2 è riuscita a farci entrare tutto quel popò di roba, il GT200 con i sui 1,4mil di transistor è grande + di 490mm2 , credo che GT300 di Nvidia sarà all'incira 600mm2 (come due 5870 ) e costerà uno sproposito e Nvidia continuerà a dover vendere le sue VGA sottocosto con pochissimi introiti

GT200 a 55nm è grosso il doppio rispetto ad Rv790 eppure guardando i test è poco + veloce di una 4890 se poi guardiamo Crysis è sempre dietro questo è quello che fa la differenza tra una azienda inteliggente e l'altra!!!

Aggiungo questa frase presa da "Tom's Hw" (recensione 5870) che fa il sunto di cosa è Nvidia x me :

"Quando Nvidia presentò i modelli GeForce GTX 260 e GTX 280, più di un anno fa, l'azienda sapeva di aver per le mani le schede più veloci del mercato e non era dispiaciuta di farle pagare care; 550 euro, per essere esatti.Quando, qualche settimana dopo, venne presentata la Radeon HD 4870, Nvidia fu costretta a un taglio netto dei prezzi. Gli appassionati si sentirono come truffati, vedendo la loro scheda perdere in poco tempo molto valore. La tattica di Nvidia è sicuramente buona per aumentare il margine di guadagno su una GPU, ma non è forse la tattica migliore per fidelizzare gli acquirenti."

Meditate gente meditate (ATI avrebbe potuto farlo ma non è Nvidia)

[kliffoth]

Originariamente inviato da yossarian

è stato usato il double buffering?

Se ci fai caso, non c'è alcuna differenza tra frame pari e dispari.
Leggi i dati in questo modo:
inizio elaborazione (start)
frame dispari (tempo 0 perchè già contenuto nel frame buffer)
frame pari (tempo molto inferiore a quello della singola gpu perchè mentre la prima ha riempito il suo fb con la prima immagine dispari, la seconda ha fatto altrettanto con la prima pari, quindi il tempo è solo quello necessario a trasferire l'immagine dal fb al monitor).
fine elaborazione (stop) per i primi due frame

start
frame dispari
frame pari
stop

in quest'ottica, la differenza tra due frame successivi è pari a circa 68, 5 ms sia che si tratti di frame pari che dispari), che è, all'incirca, il tempo che intercorre tra due immagini successive (pari o dispari) anche in single gpu.
Quindi, il problema è il tempo impiegato a eseguire la operazioni di stop e start, ovvero a inizializzare le successive elaborazioni.
In questo modo, il vantaggio dello sli o del cf si ha solo sul totale delle due operazioni (ovvero la pari arriva un po' prima) ma non sul delay time tra due operazioni successive sulla singola gpu che, anzi, si allunga.
Se non è stato usato il double o il triple buffering, la risposta è presto data, latrimenti è un problema intrinseco a questo modo di gestire il multigpu.

mmm nel primo forum che ti ho postato si parla di triple buffering...poi il video presente in uno dei link è eloquente.
Qualcuno dice riguardi solo framerate bassi.
Insomma io non so. ho solo sollevato il problema

[Benna80]

Originariamente inviato da yossarian

è stato usato il double buffering?

Se ci fai caso, non c'è alcuna differenza tra frame pari e dispari.
Leggi i dati in questo modo:
inizio elaborazione (start)
frame dispari (tempo 0 perchè già contenuto nel frame buffer)
frame pari (tempo molto inferiore a quello della singola gpu perchè mentre la prima ha riempito il suo fb con la prima immagine dispari, la seconda ha fatto altrettanto con la prima pari, quindi il tempo è solo quello necessario a trasferire l'immagine dal fb al monitor).
fine elaborazione (stop) per i primi due frame

start
frame dispari
frame pari
stop

in quest'ottica, la differenza tra due frame successivi è pari a circa 68, 5 ms sia che si tratti di frame pari che dispari), che è, all'incirca, il tempo che intercorre tra due immagini successive (pari o dispari) anche in single gpu.
Quindi, il problema è il tempo impiegato a eseguire la operazioni di stop e start, ovvero a inizializzare le successive elaborazioni.
In questo modo, il vantaggio dello sli o del cf si ha solo sul totale delle due operazioni (ovvero la pari arriva un po' prima) ma non sul delay time tra due operazioni successive sulla singola gpu che, anzi, si allunga.
Se non è stato usato il double o il triple buffering, la risposta è presto data, latrimenti è un problema intrinseco a questo modo di gestire il multigpu.

Premetto che sono molto ignorante per quanto riguarda la parte delle elaborazioni video su di un Pc per cui non ho afferrato in pieno la tua analisi, ma mi chiedevo fondamentalmente da dove venissero quelle differenze in termini di ms tra un frame a l'altro. Dagli articoli letti è proprio questa differenza che porta a dei leggeri scattini anche a frame rate alti (o comunque accettabili).

Tieni presente che con me si parla di abc, quindi nessuna cognizione su double o triple buffer

PS: non mi offendo se mi rispondi "lasciamo perdere, ci vorrebbe troppo tempo", è che vorrei capire se ci stanno vendendo una ferrari (SLI/Crossfire/multi GPU) con le prestazioni di una BMW

[ReDeX]

Originariamente inviato da Ratatosk

Veramente ci saranno entro 5-6 mesi in tutte le fasce di mercato. Già fra meno di un mese ci saranno le 57xx

Mi sono tenuto largo con i tempi, era solo per sottolineare che al lancio di una nuova generazione di schede video è sempre stata prassi presentare prima le top di gamma, e poi man mano gli altri modelli.

[Blackbox11]

Azz questa 5870 sembra velocissima....ma secondo me non conviene assolutamente comprarla prima di marzo 2009...avrà un prezzo cmq elevato e i giochi dx11 scarseggeranno prima di quella data

[yossarian]

Originariamente inviato da kliffoth

mmm nel primo forum che ti ho postato si parla di triple buffering...poi il video presente in uno dei link è eloquente.
Qualcuno dice riguardi solo framerate bassi.
Insomma io non so. ho solo sollevato il problema

ovviamente per frame rate bassi la cosa è più evidente e da luogo allo stuttering. Per frame rate elevati succede allo stesso modo ma è meno visibile perchè il sistema occhio-cervello ha più difficoltà a rilevare la differente velocità di elaborazione tra due frame successivi.
Se si fa uso di triple buffering, allora il porblema sta nella sincronizzazione tra le operazioni di fine renderizzazione di due frame (disperi e pari) e l'inizio della renderizzazione dei due frame successivi. E' in quel caso che passa troppo tempo (tra due even ci sono 68,5 msec contro i 66,6 della configurazione in single: praticamente lo stesso tempo, il che vanifica il vantaggio del multigpu).
La soluzione sarebbe quella di cercare di sincronizare le due fasi, ovvero la transizione tra due immagini e le due successive, in modo tale che quando uno dei due chip sta elaborando il frame odd della prima serie, il secondo inizia ad elaborare quello even della successiva. Se ciò non è possibile via SW, allora si deve ricorrere ad un controller che bilanci in HW il carico di lavoro tra le due gpu. Il controller potrebbe essere integrato nel northbridge oppure all'interno di una delle due gpu sfruttando, magari, un canale dedicato per la sincronizzazione (in tal caso non potresti fare sli o cf con due gpu qualsiasi ma dovresti prendere una master e una slave, ma risolveresti il problema dello stuttering ).
La cosa che mi lasci perplesso, però, è che se c'è il triple buffering abilitato non si dovrebbe verificare un delay time tra even della prima serie e even della seconda pari al tempo che intercorre per elaborare tre frame e tra odd ed even di poco inferiore a quello che intercorre tra due frame successivi in single. A meno che il ritardo non sia dovuto a problemi nella sincronizzazione dell'invio al monitor dei frame facenti parte di due coppie successive

Originariamente inviato da Benna80

Premetto che sono molto ignorante per quanto riguarda la parte delle elaborazioni video su di un Pc per cui non ho afferrato in pieno la tua analisi, ma mi chiedevo fondamentalmente da dove venissero quelle differenze in termini di ms tra un frame a l'altro. Dagli articoli letti è proprio questa differenza che porta a dei leggeri scattini anche a frame rate alti (o comunque accettabili).

Tieni presente che con me si parla di abc, quindi nessuna cognizione su double o triple buffer

PS: non mi offendo se mi rispondi "lasciamo perdere, ci vorrebbe troppo tempo", è che vorrei capire se ci stanno vendendo una ferrari (SLI/Crossfire/multi GPU) con le prestazioni di una BMW

con il multigpu in modalità afr (alternate frame rendering) uno dei due chip elabora i frame dispari e l'altro i pari. Per non avere ritardi, si dovrebbe fare in modo che nel momento in cui il primo dei due chip sta elaborando l'immagine n, l'altro inizi ad elaborare l'immagine n+1, in un ciclo continuo. Ovvero, se il primo chip elabora il frame 1 e il secondo il frame 2, mentre il secondo sta lavorando sul due il primo dovrebbe iniziare a lavorare sul 3. Invece, sembra accadere che dopo che sono stati elaborati i primi due frame (1 e 2) ci sia una pausa e quindi vengano elaborati il 3 e il 4 o, quanto meno, inviati al monitor (nel caso di abilitazione e corretto funzionamento del double o del triple buffering). Questo provoca un ritardo tra l'invio del frame 2 e l'invio del frame 3 che da luogo ad un microscatto oltre che ad un ritado nell'elaborazione. Se guardi i dato postati da jliffoth, tra i frame dispari delle modalità single e multi, non c'è praticamente alcuna differenza e si riguadagna qualcosa solo con i frame pari.
Quando si elabgora un'immagine, prima che la stessa sia inviata al monitor viene creato il frame nella ram video, all'interno di uno spazio adibito a frame buffer. Se si utilizza il double buffering, prima che parta la visualizzazione, si riempiono due frame uno detto front buffer e l'altro back buffer. Quando l'immagine del front buffer è inviata al monitor, il back buffer, tramite un puntatore, diventa front buffer e si procede al riempimento dell'ex front buffer, ora back buffer. In tal modo si ha sempre un'immagine pronta ad essere inviata al monitor e questo evita cali di frame rate. Con il triple buffering si fa la stessa cosa, ma con un front buffer e due back buffer.