Aspettando Fermi ......

Rsdj

Veramente la rivale della 5870 è la 380...

Cmq è stato pubblicato il WhitePaper di GF100:

http://www.nvidia.com/object/IO_86775.html

gianni1879

dj883u2 ha scritto:

A che cosa si riferisce?

dovrebbero essere le presunte impostazioni fatte nel test nvdia dette da hwupgrade...

Volevo capire quanto faceva una hd5870 con quelle impostazioni con farcry2

dj883u2

gianni1879 ha scritto:

dovrebbero essere le presunte impostazioni fatte nel test nvdia dette da hwupgrade...
Volevo capire quanto faceva una hd5870 con quelle impostazioni con farcry2

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.....

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 :fiufiu: )

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... :asd:

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

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 :asd:

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ù :asd:

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...