Aspettando Fermi ......

[gianni1879]

c'è poco da commentare, mi sembra evidente che i risultati sono quantomeno di parte e falsati...

[dj883u2]

gianni1879 ha scritto:

c'è poco da commentare, mi sembra evidente che i risultati sono quantomeno di parte e falsati...

Gianni, io ottengo quei risultati.....resto sconcertato per l'enorme differenza di punteggi......

[M4r1k]

dj883u2 ha scritto:

Fa 76 Frame con processore Core i7 920 portato a 3.0Ghz.....non rispecchiano la reale situazione....

Allora.....

Singola HD5870:

Singola HD5970:

A voi i commenti....il processore è anche a 3.0Ghz.....

Il punto è che i risultati sono stati ricavati da un analogo sistema in redazione ad HW.... Imho o hanno ricevuto ordine di falsarli o c'è davvero qualcosa di strano (nn nei tuoi risultati ovviamente, cmq Nv30 in HW era una signor GPU quindi )

Cmq grafici di HW a parte sembra che con Tessellation ci sia un vero incremento delle prestazioni quello che mi chiedo e come possa essere possibile quando è stato inventato da ATI ed nelle architetture ATI è presente nn solo da R600 ma dalla 8500XT. Cioè che possa esser stato implementato meglio da Nvidia può essere plausibile ma quello che nn mi torna è come mai in AMD l'hanno implementato con il cavolo...

[gianni1879]

dj883u2 ha scritto:

Gianni, io ottengo quei risultati.....resto sconcertato per l'enorme differenza di punteggi......

beh diciamo che è una pubblicità bella e buona, per far un pò calmare o esaltare alcuni utenti che attendevano nei giorni scorsi i risultati.

Indubbiamente Fermi sarà più performante di rv870 ma non sicuramente con tutta quella percentuale (ci sono screen dove si vede pure un 50% circa avanti).

[Severnaya]

nVidia vanterà le prestazioni, quanto di più nn è dato sapere ma è plausibile che nn saranno eclatanti

sulle altre caratteristiche tutto tace...

[principino1984]

Come già stato in passato per altri articoli di quella redazione... anche questo è una gran presa per i fondelli per gli utenti finali. Lo dico e me ne assumo tutte le responsabilità del caso. Non è possibile una discrepanza di valori così elevati... è ridicola!

Io prima di riconferire parola su questa scheda aspetto test seri..magari fatti dalla nostra redazione! Vedremo...

Marco

[delly]

mamma mia...sono rientrato da poco dal lavoro e guarda qui che bordello...

solita ondata di test inaffidabili a quanto pare...

ormai mi sono rassegnato...fermi saprò davvero come sarà quando ce l'avrò fra le mani...

[yossarian]

due parole sul tessellator di nVIDIA

Faccio un copia incolla di quanto ho scritto su hwu

Il polymorph engine è un ibrido che prevede il tessellator vero e proprio in hardware e la sua parte programmabile eseguita dallo shader core. In pratica, nVIDIA ha scomposto la parte relativa alle operazioni geometriche della pipeline grafica, replicandone più volte gli elementi. Così, ogni gruppo di 128 alu ha un suo raster engine e ogni gruppo di 32 alu ha un suo tessellator dedicato.

Trova riscontro l'ipotesi che avevo fatto tempo fa sulla possiblità di avere un tessellator hardware. Come dicevo allora,s e qualcosa si può emulare questi sono hull e domain shader (ossia la parte programmabile), come avviene in RV770, mentre è del tutto controproducente farlo con il tessellator vero e proprio.

In pratica nVIDIA ha dotato ogni AP di un tessellator del tipo di quello visto per RV770 (ovviamente dimensionandolo al numero di alu che deve servire).

Vantaggi di questa soluzione sono la riduzione dell'ammontare di hardware dedicato e la possibilità di disattivare anche l'hw dedicato alle operazioni di tessellation quando si disabilitano SP.

Svantaggi: l'impatto sulle prestazioni è variabile e dipende da diversi fattori, ad iniziare dall'occuzione degli shader per finire con l'occupazione di banda tra shader core e polymorph engine. In questo caso, infatti, non si ha un flusso di dati che scorre in un solo verso, ma i vertici prelevati dallo stadio che fa vertex fetch passano allo shader core che svolge le funzioni tipiche degli hull shader, quindi tornano al polymorph engine per la tessellation, di nuovo alllo shader core per le operazioni di domain shading e, infine, al polymorph engine che prepara le operazioni di rasterizzazione. Questo complica ulteriormente la già complessa logica di controllo dei chip nVIDIA ma l'architettura con tessellator dedicato ad ogni SP dovrebbe ridurre l'impatto sulla banda passante tra polymorph engine e shader core (per essere più precisi si dovrebbero avere dati sulla capacità di trasferimento dati di quel canale).

[Rsdj]

yossarian ha scritto:

due parole sul tessellator di nVIDIA

Faccio un copia incolla di quanto ho scritto su hwu

Il polymorph engine è un ibrido che prevede il tessellator vero e proprio in hardware e la sua parte programmabile eseguita dallo shader core. In pratica, nVIDIA ha scomposto la parte relativa alle operazioni geometriche della pipeline grafica, replicandone più volte gli elementi. Così, ogni gruppo di 128 alu ha un suo raster engine e ogni gruppo di 32 alu ha un suo tessellator dedicato.

Trova riscontro l'ipotesi che avevo fatto tempo fa sulla possiblità di avere un tessellator hardware. Come dicevo allora,s e qualcosa si può emulare questi sono hull e domain shader (ossia la parte programmabile), come avviene in RV770, mentre è del tutto controproducente farlo con il tessellator vero e proprio.

In pratica nVIDIA ha dotato ogni AP di un tessellator del tipo di quello visto per RV770 (ovviamente dimensionandolo al numero di alu che deve servire).

Vantaggi di questa soluzione sono la riduzione dell'ammontare di hardware dedicato e la possibilità di disattivare anche l'hw dedicato alle operazioni di tessellation quando si disabilitano SP.

Svantaggi: l'impatto sulle prestazioni è variabile e dipende da diversi fattori, ad iniziare dall'occuzione degli shader per finire con l'occupazione di banda tra shader core e polymorph engine. In questo caso, infatti, non si ha un flusso di dati che scorre in un solo verso, ma i vertici prelevati dallo stadio che fa vertex fetch passano allo shader core che svolge le funzioni tipiche degli hull shader, quindi tornano al polymorph engine per la tessellation, di nuovo alllo shader core per le operazioni di domain shading e, infine, al polymorph engine che prepara le operazioni di rasterizzazione. Questo complica ulteriormente la già complessa logica di controllo dei chip nVIDIA ma l'architettura con tessellator dedicato ad ogni SP dovrebbe ridurre l'impatto sulla banda passante tra polymorph engine e shader core (per essere più precisi si dovrebbero avere dati sulla capacità di trasferimento dati di quel canale).

E quindi ci dovrebbe stare tutto questo entusiasmo da gridare al "miracolo"??

[delly]

sempre chiarissimo Stefano...

quindi da quello che dici si potrebbe intuire che l'implementazione di nvidia potrebbe dare prestazioni "entusiasmanti" con un titolo e "deludenti" con un'altro...o addirittura entrambi i casi nello stesso titolo...

[One1ros]

quindi i test mostrati sono dei casi fortunati?

[yossarian]

Rsdj ha scritto:

E quindi ci dovrebbe stare tutto questo entusiasmo da gridare al "miracolo"??

non chiederlo a me

delly ha scritto:

sempre chiarissimo Stefano...

quindi da quello che dici si potrebbe intuire che l'implementazione di nvidia potrebbe dare prestazioni "entusiasmanti" con un titolo e "deludenti" con un'altro...o addirittura entrambi i casi nello stesso titolo...

facciamo un discorso un po' più ampio: fermi ha la possibilità di gestire 16 kernel (che non sono da intendersi come i kernel di un OS, ma come, più semplicemente, 16 gruppi di thread della stessa applicazione).

Il tessellator è frazionato in 16 unità. Mettendo a sistema queste due cose, è possibile che, in un'applicazione in cui serva il tessellator, alcuni SP svolgano funzioni di tessellation e altri si occupino della grafica. Questo significa che, sulla carta. è possibile avere un tessellator che ha una capacità di calcolo minima pari a quella del singolo SP e massima pari alla somma di quelli dei 16 SP. Quindi, possiamo definirlo "modulabile". Ovviamente, quello o quegli SP che stanno lavorando sulle operazioni di tessellation non possono essere impiegati per fare altro.

Questo significa che mentre quello di ATi può risultare a volte sottodimensionato e altre volte sovradimensionato ma lavora sempre con HW dedicato, quello di nVIDIA è in grado di dare potenza quando serve ma questa potenza la sottrae ad altri tipi di operazioni. Discorso analogo a quanto visto per physx, in parole povere.

[delly]

yossarian ha scritto:

facciamo un discorso un po' più ampio: fermi ha la possibilità di gestire 16 kernel (che non sono da intendersi come i kernel di un OS, ma come, più semplicemente, 16 gruppi di thread della stessa applicazione).

Il tessellator è frazionato in 16 unità. Mettendo a sistema queste due cose, è possibile che, in un'applicazione in cui serva il tessellator, alcuni SP svolgano funzioni di tessellation e altri si occupino della grafica. Questo significa che, sulla carta. è possibile avere un tessellator che ha una capacità di calcolo minima pari a quella del singolo SP e massima pari alla somma di quelli dei 16 SP. Quindi, possiamo definirlo "modulabile". Ovviamente, quello o quegli SP che stanno lavorando sulle operazioni di tessellation non possono essere impiegati per fare altro.

Questo significa che mentre quello di ATi può risultare a volte sottodimensionato e altre volte sovradimensionato ma lavora sempre con HW dedicato, quello di nVIDIA è in grado di dare potenza quando serve ma questa potenza la sottrae ad altri tipi di operazioni. Discorso analogo a quanto visto per physx, in parole povere.

chiarissimo...mille grazie...

[M4r1k]

yossarian ha scritto:

non chiederlo a me

facciamo un discorso un po' più ampio: fermi ha la possibilità di gestire 16 kernel (che non sono da intendersi come i kernel di un OS, ma come, più semplicemente, 16 gruppi di thread della stessa applicazione).

Il tessellator è frazionato in 16 unità. Mettendo a sistema queste due cose, è possibile che, in un'applicazione in cui serva il tessellator, alcuni SP svolgano funzioni di tessellation e altri si occupino della grafica. Questo significa che, sulla carta. è possibile avere un tessellator che ha una capacità di calcolo minima pari a quella del singolo SP e massima pari alla somma di quelli dei 16 SP. Quindi, possiamo definirlo "modulabile". Ovviamente, quello o quegli SP che stanno lavorando sulle operazioni di tessellation non possono essere impiegati per fare altro.

Questo significa che mentre quello di ATi può risultare a volte sottodimensionato e altre volte sovradimensionato ma lavora sempre con HW dedicato, quello di nVIDIA è in grado di dare potenza quando serve ma questa potenza la sottrae ad altri tipi di operazioni. Discorso analogo a quanto visto per physx, in parole povere.

Ciao Stefano,

Grazie mille per la spiegazione! Cmq mi pare di capire che la tendenza sia quella di demandare il maggior numero possibile di operazioni agli SP esattamente come per l'AA su R600 che nn veniva calcolato dalle ROPs visto che questi essendo programmabili (nn che gli altri nn lo siano ma mi pare di capire che siano più flessibili) sono più adatti al general purpose. Così facendo vi sarebbe una diminuzione delle unità dedicate ed un maggior spazio per quelle generiche. Mi pare di capire quindi che la tendenza per i prossimi anni sia questa

[yossarian]

M4r1k ha scritto:

Ciao Stefano,

Grazie mille per la spiegazione! Cmq mi pare di capire che la tendenza sia quella di demandare il maggior numero possibile di operazioni agli SP esattamente come per l'AA su R600 che nn veniva calcolato dalle ROPs visto che questi essendo programmabili (nn che gli altri nn lo siano ma mi pare di capire che siano più flessibili) sono più adatti al general purpose. Così facendo vi sarebbe una diminuzione delle unità dedicate ed un maggior spazio per quelle generiche. Mi pare di capire quindi che la tendenza per i prossimi anni sia questa

non del tutto: nVIDIA ha dovuto implementare un hardware tessellator e delle tmu che fanno, comunque, texture sampling e addressing (anche se le operaizoni di blending le fa lo shader core).

ATi ha tmu analoghe e un hw tessellator. Intel, con larrabee, non ha diffuso informazioni su chi si occuperà delle operazioni di tessellation, ma ha comunque dovuto rinunciare all'idea di fara fare le operazioni di texturing per intero alle fpu (ha anche lei adottato delle tmu che fanno texture sampling).

Insomma, programmabile è bello ma non dove la programmabilità obbliga a tanti cicli di clock in più

[Rsdj]

Achille GForce ha scritto:

bè ma questo non giustifica il fatto che Nvidia è in grado di erogare oltre 8 volte la potenza sui calcoli geometrici rispetto a GT200.

possiamo solo dire che con il tessellator Nvidia ha proprio asfaltato ATI, avere un hardware ibrido che fa molte cose parallelamente è un vantaggio, anche perchè la potenza di elaborazione del chip Fermi sarà sicuramente ampissima.

i driver poi sono degli alpha test, perchè ce ne scordiamo ? Fra l'altro Nvidia non ha ancora un sample pre relase, in quanto non hanno ancora ufficializzato le freqeunze.

Anche prendendo far cry 2 come paragone con una VGA non definitiva quindi con freqeunze e caratteristiche fantasma 84 frames fra l'altro cpu limited ha detto Nvidia con dei driver maturi dovrebbe andare ben più forte. Dalla strategia di mercato di Nvidia mi pare di aver capito che oramai l'obbiettivo è quello di avere il 20% in più sulla 5870, quindi lavoreranno per avere freqeunze tali per avere quella performance. Da hardware canunch si è detto che potrebbe essere una versione con step precedente a quello che verrà commercializzato quindi downcloccato o comunque castrato.

Io però sono curioso di vedere i prossimi titoli con tessellation quanto influirà sta cosa

Ecco cosa intendo quando dico che il fanboy vede una realtà distorta, tutta sua, contraria a quanto detto fin'ora...

E poi sta insistenza con i driver... ma se è stata nVidia a dire che avrebbe sviluppato dei driver che facevano andare GF100 al massimo già da subito?? Inoltre ha anche detto che il ritardo accumulato era dovuto anche a questo...

Scusa un'ultima cosa: il fatto che ancora non ci siano in giro sample nemmeno per le release ti rende ottimista??

[delly]

Achille GForce ha scritto:

Ricorda che comunque vadano le cose Nvidia sarà superiore come prestazioni con entrambi i modelli

azz...veggenza o supposizione??? :cheazz:

io abbasserei le "alucce" cmq...meglio rimanere con i piedi per terra e valutare in base ai fatti che volare con la fantasia...non per nulla...ma si rischia di rimanere molto delusi se poi qualcosa va storto...

[dj883u2]

Achille GForce ha scritto:

sample in giro no, perchè si vede che stan lavorando per aggiustare le cose, hanno tempo fino alla 3° settimana di febbraio, ancora si può fare qualcosa.

Nvidia ha detto che ha avuto più tempo per lavorare sui driver ma risultano comunque in versione "alpha test".

ma io fanboy o no, mica solo l'unico quì, ti vedo cosa scrivi su hwupgrade Ricorda che comunque vadano le cose Nvidia sarà superiore come prestazioni con entrambi i modelli. Il vantaggio di Nvidia con il tessellator indipendentemente dai ritocchi sembrano veramente enormi, 60/80% solo nel Ungine Heaven

Test molto seri, dove la stessa Nvidia rilascia i valori....attendibilità prossima al 100!

Questo è il test fatto vedere da hwupgrade:

Non mi voglio soffermare sul discorso dei Frame fatti dalla HD5870....che come ho detto sono palesemente sballati.....ma mi soffermo solo su questa frase scritta sempre dai redattori di hwupgrade:

I valori, per quanto eseguiti con un test ufficiale sono comunque da prendere con il beneficio di inventario: non sappiamo quali driver siano stati utilizzati o se siano state applicate particolari patch al gioco. Nel caso specifico, abbiamo provato ad eseguire il test sulla nostra piattaforma, utilizzando GeForce GTX 285; rispetto ai dati forniti da NVIDIA le prestazioni scendono a 44 - 66,51 e 33,20 rispettivamente per avg framerate, max e min framerate.

Con queste affermazioni, per me il discorso è veramente chiuso....personalmente sono molto ma molto deluso....qui stiamo parlando che Nvidia da risultati "sballatii", chiaramente a loro favore, che non rispecchiano la realtà!...allucinante!:AAAAH:....ripeto...ALLUCINANTE!...e non voglio dire altro....dimmi, che attendibilità avrà quel 84 al test di FarCray 2?.....

[delly]

dj883u2 ha scritto:

Test molto seri, dove la stessa Nvidia rilascia lei stessa i valori....attendibilità prossima al 100!

CCon queste affermazioni, per me il discorso è veramente chiuso....personalmente sono molto ma molto deluso....qui stiamo parlando che Nvidia da risultati "sballatii", chiaramente a loro favore, che non rispecchiano la realtà!...allucinante!:AAAAH:....ripeto...ALLUCINANTE!...e non voglio dire altro....dimmi, che attendibilità avrà quel 84 al test di FarCray 2?.....

mamma mia... :boh:

effettivamente per prendere per buoni quei valori non basta essere di "parte"...bisogna essere proprio

p.s. concordo..delusione totale anche per me...

attendibilità??? io direi prossima allo ZERO...

[One1ros]

dj883u2 ha scritto:

I valori, per quanto eseguiti con un test ufficiale sono comunque da prendere con il beneficio di inventario: non sappiamo quali driver siano stati utilizzati o se siano state applicate particolari patch al gioco. Nel caso specifico, abbiamo provato ad eseguire il test sulla nostra piattaforma, utilizzando GeForce GTX 285; rispetto ai dati forniti da NVIDIA le prestazioni scendono a 44 - 66,51 e 33,20 rispettivamente per avg framerate, max e min framerate.

Non ho parole, sarebbe da denuncia per pubblicità ingannevole, peccato che la definizione stessa di benchmark li protegga...