Aspettando Fermi ......

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

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

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

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

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

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

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

okorop

One1ros ha scritto:

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

quoto....

Rsdj

Antonio dai una letta qui:

Hardware Upgrade Forum - View Single Post - NVIDIA GeForce GF100 Fermi: preview dell'architettura

Ti chiedo a questo punto se per piacere puoi ripetere il test con il processore a 3,2 ghz ma alzando di più il moltiplicatore (sui 20x, 21x sarebbe ottimo) e meno possibile il bus, così da mettere a tacere una volta del tutte queste scuse banali.

Iantikas

io non riesco proprio a capire i post "alla achille" dove si parla di asfaltare, di certezze, di prestazioni alucinanti, etc etc...

...ma allo stesso tempo non capisco i post che vedono tutto buio e tenebroso che peggio non si può...

...cioè io dopo aver letto le varie preview di oggi e il documento di nvidia su GF100 ho un pensiero più positivo su fermi rispetto a prima ...

...rimangono i problemi di bench che non stanno nè in cielo nè in terra e di tante problematiche rimaste ancora insolute ma mi sembra che come architettura in sè è certamente interessante e, soprattutto in ottica sviluppi futuri (non dei driver eh ma proprio dell'architettura ), promettente...

...se paragoniamo i dati che abbiamo oggi a queli che si avevano una settimana fa c'è da essere molto più fiduciosi (ok che se uno è sprofondato nella melma e dopo ci sta solo fino al collo sempre nella melma sta....xò è sempre un miglioramento )...

...boh vabbeh cmq l'ora è tarda e non mi ricordo più cosa volevo dire :uglystupid2: ...ma qualcosa volevo dirla :cheazz: ed ora è meglio se vado a fare la nanna :briai:

gianni1879

Rsdj ha scritto:

Antonio dai una letta qui:
Hardware Upgrade Forum - View Single Post - NVIDIA GeForce GF100 Fermi: preview dell'architettura

Ti chiedo a questo punto se per piacere puoi ripetere il test con il processore a 3,2 ghz ma alzando di più il moltiplicatore (sui 20x, 21x sarebbe ottimo) e meno possibile il bus, così da mettere a tacere una volta del tutte queste scuse banali.

d'ora in poi basta aumentare il bclk, nemmeno la cpu, per avere prestazioni aumentate nei game, non serve più nemmeno cambiare vga....

Dimenticavo, presumo che il i965 abbia pure il turbo mode attivo... quindi altro che 3.2 GHz...

mi aspettavo una spiegazione migliore in verità.

gianni1879

ecco come agisce il turbo mode nella cpu i965EE

non penso assolutamente che durante il test sia rimasta sempre a 3.2 GHz