Link alla notizia: http://www.hwupgrade.it/news/skvideo/nuove-indiscrezioni-sulla-gpu-gk104-di-nvidia_40691.html

Dettagli precisi, e a prima analisi sufficientemente accurati, sulle specifiche delle prossime generazioni di GPU NVIDIA di fascia medio alta, appartenenti alla famiglia Kepler

Click sul link per visualizzare la notizia.

Il conteggio totale vede quindi 1.536 CUDA Cores integrati in GK104, con una frequenza di clock che ha i 950 MHz quale obiettivo massimo. A differenza delle precedenti generazioni di architetture video NVIDIA in GK104 la frequenza di clock dei CUDA cores è identica a quella della GPU: anche grazie a questo elemento è stato possibile integrarne un numero ben più elevato.

semmai è il contrario. Se così fosse, significherebbe che, poichè sono riusciti ad integrare più alu nel chip, non hanno più la necessità di farle lavorare a frequenze più elevate rispetto al resto :p

Considerando il raddoppio dei CUDA e il dimezzamento delle frequenze e il miglioramento architetturale di un 15% dovrebbe andare come una 580-7950 se fossero confermate queste specifiche. Tutto come previsto, e siccome il price target dovrebbe essere di 399$ significa che le 7XXX caleranno di prezzo.
Ottima notizia se confermata.
Come previsto GK110 andrà come la 7970 nell'incarnazione base e un 15% in più nella configurazione TOP. Con 6-7 mesi di ritardo pero. Aspettiamo i consumi perché si parla di quasi 6Mld di transistor per GK110.

semmai è il contrario. Se così fosse, significherebbe che, poichè sono riusciti ad integrare più alu nel chip, non hanno più la necessità di farle lavorare a frequenze più elevate rispetto al resto :p

Considera anche che hanno un die size per la fascia medio-alta quasi alla pari con la fascia alta di AMD..... se le freq fossero di 1.7Ghz consumerebbe uno sproposito. Mi pare che anche nVidia come AMD abbia scelto la strada di semplificare le processing unit in favore del numero delle stesse. Ma questo sicuramente tu potrai spiegarlo meglio;)

Spero che Nvidia riesca nel suo intento di tirar fuori qualcosa di veramente eccezionale non solo per rimanere al di sopra di Amd ma sopratutto per proporre qualcosa che possa rimpiazzare la serie 5xx che rimane comunque ottima specialmente nelle versione 580/570/560.

Considerando il raddoppio dei CUDA e il dimezzamento delle frequenze e il miglioramento architetturale di un 15% dovrebbe andare come una 580-7950 se fossero confermate queste specifiche. Tutto come previsto, e siccome il price target dovrebbe essere di 399$ significa che le 7XXX caleranno di prezzo.
Ottima notizia se confermata.
Come previsto GK110 andrà come la 7970 nell'incarnazione base e un 15% in più nella configurazione TOP. Con 6-7 mesi di ritardo pero. Aspettiamo i consumi perché si parla di quasi 6Mld di transistor per GK110.

Si ma i cuda sono quadruplicati....

Si ma i cuda sono quadruplicati....

Ups:muro: Hai ragione!

Gli shader sono 3x quelli della GTX580 e quindi un dimezzamento della frequenza (in verità molto meno, dato che il GF110 lavora a 820MHz, non 950) e un miglioramento dell'architettura (ancora da valutare) pone questo chip ben al di sopra delle prestazioni della GTX580. Probabilmente al pari della 7970 già al day one.
L'unica diversità vera è la banda passante che nella 7970 è maggiore e quindi è probabile che ad altissime risoluzioni con AA attivo quest'ultima vada meglio. Ma bisogna vedere se nvidia non si è inventata qualcosa per applicare gli effetti di AA in maniera più efficiente (e quindi richiedendo meno banda).
E comunque questo è il chip di metà fascia per nvidia. Difficile presupporre che il GK100/GK110 sarà solo di poco più veloce di questo. Credo che, seppur in ritardo, il chippone avrà prestazioni veramente elevate, soprattutto là dove nvidia vuole venderlo per trarre il massimo guadagno: il segmento professionale.

@CrapaDiLegno: Non vorrei dire fesserie ma di default il clock di GF110 in versione GTX580 è 775 MHZ

considerando che questa è la fascia media, lascia ben sperare per le schede top. Vedremo se Nvidia porterà qualcosa che realmente giustifichi i 28nm, per ora il gap coi 40nm che hanno mostrato le schede AMD è ampiamente deludente.

Mi auto correggo. Di default il clock del GF110 è di "soli" 772MHz, per cui il rapporto di frequenza tra gli shader è il 60% in più in favore della vecchia architettura. Bisogna vedere se questi shader hanno la stessa capacità computazionale di quelli vecchi o richiedono più cicli per fare le stesse cose.
Se sono uguali, si può fare un facile confronto:
potenza GF110: 772*2*512 = 790528
potenza GK104: 950 *1536 = 1459200
Non è il doppio ma quasi ci siamo... il che significa che no, non avranno la stessa potenza computazionale. Sarebbe un salto prestazionale enorme.

Quello che non quadra sono il numero di ROPs e TMUs. Mentre queste ultime sono aumentate da 64 a 128, indicando un aumento prestazionale del 200% rispetto al GF110(!!), le ROPs sono invece diminuite, da 64 a 32. Il che non mi sembra realistico, anche avendo apportato miglioramenti alle stesse. O nvidia ha ritenuto il GF110 sbilanciato per il numero di ROPs o qualcosa nei numeri pubblicati non torna.

Considera anche che hanno un die size per la fascia medio-alta quasi alla pari con la fascia alta di AMD..... se le freq fossero di 1.7Ghz consumerebbe uno sproposito. Mi pare che anche nVidia come AMD abbia scelto la strada di semplificare le processing unit in favore del numero delle stesse. Ma questo sicuramente tu potrai spiegarlo meglio;)

Gli shader sono 3x quelli della GTX580 e quindi un dimezzamento della frequenza (in verità molto meno, dato che il GF110 lavora a 820MHz, non 950) e un miglioramento dell'architettura (ancora da valutare) pone questo chip ben al di sopra delle prestazioni della GTX580. Probabilmente al pari della 7970 già al day one.
L'unica diversità vera è la banda passante che nella 7970 è maggiore e quindi è probabile che ad altissime risoluzioni con AA attivo quest'ultima vada meglio. Ma bisogna vedere se nvidia non si è inventata qualcosa per applicare gli effetti di AA in maniera più efficiente (e quindi richiedendo meno banda).
E comunque questo è il chip di metà fascia per nvidia. Difficile presupporre che il GK100/GK110 sarà solo di poco più veloce di questo. Credo che, seppur in ritardo, il chippone avrà prestazioni veramente elevate, soprattutto là dove nvidia vuole venderlo per trarre il massimo guadagno: il segmento professionale.

il numero di alu, stando a queste voci, è 3 volte quello di fermi, ma non credo proprio che l'architettura sia la stessa. Quelle di fermi sono alu superscalari, queste credo siano di tipo vettoriale (ovvero sul tipo di quelle di tahiti). Se così fosse, l'efficienza non sarebbe la stessa di fermi e, di conseguenza, non sarebbe possibile fare calcoli del tipo: prendo x, moltiplico, divido e ottengo y.

Il pensiero più ricorrente sarà autoconvincermi a cambiare architettura per aver il pci-ex 3.0 con x79 e le nuove 28nm.. considerando che con un i7 920 a 4ghz, 12gb di ram, gtx480 a 900mhz , ma anche tranquillamente a 830, ci gioco a bf3 in 1920 tutto ultra registrando con fraps senza avere alcun problema di sorta, il cambio a che pro? per benchmark? ...
A sto giro passo, se passerò alla nuova architecture sarà perchè ogni gioco che installo non supererà MAI i 30frame,e credo che passerà almeno un'altro anno...
(cosa che da quando ho la 480 occata con l'accelero, non mi è mai capitata con qualsiasi gioco sempre con fraps attivo, ovviamente con il full option).
Non capisco l'esigenza di queste nuove VGA. Non c'e niente che metta in difficoltà le vecchie generazioni. Mbah, a sto giro se non sviluppano qualcosa di veramente peso per PC, ste vga venderanno la metà di quelle precedenti. imho.

Mi auto correggo. Di default il clock del GF110 è di "soli" 772MHz, per cui il rapporto di frequenza tra gli shader è il 60% in più in favore della vecchia architettura. Bisogna vedere se questi shader hanno la stessa capacità computazionale di quelli vecchi o richiedono più cicli per fare le stesse cose.
Se sono uguali, si può fare un facile confronto:
potenza GF110: 772*2*512 = 790528
potenza GK104: 950 *1536 = 1459200
Non è il doppio ma quasi ci siamo... il che significa che no, non avranno la stessa potenza computazionale. Sarebbe un salto prestazionale enorme.

Quello che non quadra sono il numero di ROPs e TMUs. Mentre queste ultime sono aumentate da 64 a 128, indicando un aumento prestazionale del 200% rispetto al GF110(!!), le ROPs sono invece diminuite, da 64 a 32. Il che non mi sembra realistico, anche avendo apportato miglioramenti alle stesse. O nvidia ha ritenuto il GF110 sbilanciato per il numero di ROPs o qualcosa nei numeri pubblicati non torna.

Le ROPs sono collegate al bus essendo di 256 bit è inferiore e tieni da conto che stai paragonando il top di allora con la media prossima ventura pensa che il GK110 di GPC ne dovrebbe avere 6.

Quelle di fermi sono alu superscalari, queste credo siano di tipo vettoriali (ovvero sul tipo di quelle di tahiti)
Le ALU super scalari ho presente come sono fatte. Quelle vettoriali in questo caso no. Cioè, ho presente quelli di AMD nella vecchia architettura che sono raggruppate a pacchi da 4 o 5, ma non quelle nuove. Ho presente come sono fatte le unità vettoriali per il calcolo in virgola mobile (NEON per esempio), ma in quel caso sono i dati ad essere vettoriali e non mi sembrano uguali a quelli in Tahiti.
Queste ALU non prendono una istruzione e la applicano su un singolo dato ad ogni ciclo e sono indipendenti una dall'altra usando la stessa istruzione per ogni SM?
Cioè, non mi è chiaro cosa cambia tra le unità di esecuzione di Tahiti rispetto a quelle di Fermi.
E quindi cosa cambia tra le vecchie del Fermi e queste nuove di Kepler.

Ogni chiarimento sarebbe gradito. Thanks

Le ROPs sono collegate al bus essendo di 256 bit è inferiore e tieni da conto che stai paragonando il top di allora con la media prossima ventura pensa che il GK110 di GPC ne dovrebbe avere 6.
Devo aver sbagliato a guardare: mi sembrava che GF110 e GF114 avessero lo stesso numero di ROPs pari a 64. Invece no. Quindi in effetti il numero torna con quell'ampiezza di bus.
E quindi risulta che anke GK100/110 avrà lo stesso numero di ROPs del GF110 (48) e un bus a 384 bit se lo scaling tra le risorse dedicate ai GPC rimane costante (anche se credo il numero di shader per ogni SM cambierà).

Devo aver sbagliato a guardare: mi sembrava che GF110 e GF114 avessero lo stesso numero di ROPs pari a 64. Invece no. Quindi in effetti il numero torna con quell'ampiezza di bus.
E quindi risulta che anke GK100/110 avrà lo stesso numero di ROPs del GF110 (48) e un bus a 384 bit se lo scaling tra le risorse dedicate ai GPC rimane costante (anche se credo il numero di shader per ogni SM cambierà).

Se l'architettura è una il numero di shader per ogni SM sarà uguale. Altrimenti sono 2 architetture.;)

Le ALU super scalari ho presente come sono fatte. Quelle vettoriali in questo caso no. Cioè, ho presente quelli di AMD nella vecchia architettura che sono raggruppate a pacchi da 4 o 5, ma non quelle nuove. Ho presente come sono fatte le unità vettoriali per il calcolo in virgola mobile (NEON per esempio), ma in quel caso sono i dati ad essere vettoriali e non mi sembrano uguali a quelli in Tahiti.
Queste ALU non prendono una istruzione e la applicano su un singolo dato ad ogni ciclo e sono indipendenti una dall'altra usando la stessa istruzione per ogni SM?
Cioè, non mi è chiaro cosa cambia tra le unità di esecuzione di Tahiti rispetto a quelle di Fermi.
E quindi cosa cambia tra le vecchie del Fermi e queste nuove di Kepler.

Ogni chiarimento sarebbe gradito. Thanks

una alu è vista dalle istruzioni in ingresso come una unica unità funzionale. La differenza sta nel modo in cui queste alu sono organizzate ed eseguono i calcoli. Una alu scalare può eseguire una istruzione scalare per ciclo; questo significa, nel caso specifico, una mul, una add o una madd, ad esempio, di tipo fp32. Una alu vettoriale si comporta allo stesso modo quando si trova ad operare su un dato scalare ma è in grado di eseguire lo stesso lavoro, sempre in un ciclo, anche su un'istruzione add, mul o madd di tipo vettoriale e, quindi, con più componenti; per fare la stessa cosa, un'alu scalare ha bisogno di eseguire tanti cicli quante sono le componenti del dato vettoriale in ingresso. Le alu delle gpu ati fino a cayman sono di tipo vliw 4-way o 5-way. Ogni alu è composta da 4 o 5 minialu ciascuna in grado di eseguire un'istruzione di tipo scalare indipendente dalle altre eseguite dalla stessa alu, con la sola condizione che facciano parte dello stesso thread. Quindi, di fatto, un'alu vliw può eseguire più istruzioni differenti indipendenti per ciclo, un'alu scalare o una vettoriale possono eseguire una sola istruzione per ciclo e quello che cambia è che la seconda può eseguire in un unico ciclo istruzioni scalari o vettoriali. Ora, un'architettura scalare o vliw hanno un'efficienza superiore rispetto ad una vettoriale; il contro è che un'architettura scalare comporta una complessità enorme nei circuiti dedicati alle operazioni di trasmissione, controllo, clock, ecc, che tolgono spazio alle unità funzionali. Un'architettura vliw è molto semplice a livello di logica di controllo ma è molto dipendente dalle ottimizzazioni del codice e sposta tutta la complessità a livello di compilatore. Un'architettura vettoriale è una sorta di via di mezzo: molto meno complessa di una scalare a livello di hardware e molto meno dipendente della vliw dal codice. La cosa curiosa è che, se anche kepler avesse alu di tipo vettoriale, si ritornerebbe alle origini, visto che, prima dell'avvento delle architetture unificate, sia ati che nvidia facevano uso di alu vettoriali :D

Ok, ho capito più o meno. Tranne il fatto che una unità vettoriale sia meno complessa di una scalare.
Però a questo punto uno si aspetta che una ALU vettoriale faccia più lavoro di una scalare nello stesso lasso di tempo se può operare sui dati vettoriali invece che scalare. Che è il principio che sta alla base delle istruzioni SSE/AVX se non ho capito male. Ovvero se devono operare su una quantità di dati vettoriali 4 volte più grande di una scalare fare una add/mul/fp32 etc.. dovrà richiedere meno tempo di 4 cicli svolti dall'unità scalare.
Quindi in teoria sia le unità Tahiti che quelle Kepler dovrebbero avere maggiore IPC rispetto a quelle scalari di Fermi.
Però Tahiti non ha dimostrato questo, e suggerisci che anche le unità di Kepler, pur in numero 3 volte maggiore, non andranno 3 volte tanto.
Allora, la mia domanda è... perché usarle al posto delle scalari che hanno il vantaggio di essere sempre usate al 100% (dato che il dato è sempre uno solo e quello è sempre disponibile, banda permettendo)?
O mi sfugge qualcosa? (sono Crapa di Legno mica per niente :) )

Allora è vero che Nvidia si AMDizzerà...:sofico: con queste caratteristiche ogni previsione prestazionale basata sulle vecchie architetture diventa impossibile.

Comunque non mi aspettavo una rivoluzione così radicale...:fagiano:

Ah, dalla notizia pare proprio che non sarà la fascia media ma la TOP (GTX 680)...ed è anche logico che sia così: come sempre è stato uscirà prima la Top di gamma (esclusa la solita Dual GPU ovviamente).

Allora è vero che Nvidia si AMDizzerà...:sofico: con queste caratteristiche ogni previsione prestazionale basata sulle vecchie architetture diventa impossibile.

Comunque non mi aspettavo una rivoluzione così radicale...:fagiano:

Ah, dalla notizia pare proprio che non sarà la fascia media ma la TOP (GTX 680)...ed è anche logico che sia così: come sempre è stato uscirà prima la Top di gamma (esclusa la solita Dual GPU ovviamente).

in realtà, diciamo che farebbero entrambe un passo verso "il centro" da posizioni più estreme. Si tratta di una questione "politica" :sofico:

Allora è vero che Nvidia si AMDizzerà...:sofico: con queste caratteristiche ogni previsione prestazionale basata sulle vecchie architetture diventa impossibile.

Comunque non mi aspettavo una rivoluzione così radicale...:fagiano:

Ah, dalla notizia pare proprio che non sarà la fascia media ma la TOP (GTX 680)...ed è anche logico che sia così: come sempre è stato uscirà prima la Top di gamma (esclusa la solita Dual GPU ovviamente).

Non farti ingannare dal nome non è la top che sarà costituita dalle GTX685/690 con il GK110.
dallo stesso sito...

http://www.3dcenter.org/news/nvidia-eigene-gk104-benchmarks-schneller-als-die-radeon-hd-7970

in realtà, diciamo che farebbero entrambe un passo verso "il centro" da posizioni più estreme. Si tratta di una questione "politica" :sofico:

un altro utente mi rispondeva così altrove http://www.hwupgrade.it/forum/showpost.php?p=36892781&postcount=7384

non potrebbe dunque essere "solo" una riorganizzazione, ma sempre superscalare rimarrebbe l'architettura?

un altro utente mi rispondeva così altrove http://www.hwupgrade.it/forum/showpost.php?p=36892781&postcount=7384

non potrebbe dunque essere "solo" una riorganizzazione, ma sempre superscalare rimarrebbe l'architettura?

no, il double clock si ottiene con semplici moltiplicatori di frequenza e non è necessaria la duplicazione delle linee di trasmissione, controlo, clock,.......

Per chi non sapesse, il GK104 è di FASCIA MEDIA, il sostituto della attuale GTX560.

Ha semplicemente cambiato nomenclatura :
GTX 680 = fascia media
GTX / GTR 685 = fascia alta
GTX 690 = dual GPU

Il GK110 uscirà più in là, quindi tutti i rumor che parlavano di una GTX 680 inferiore del 15% alla 7970 sono un ottima cosa, vuol dire che quando usciranno i modelli di punta sarà un altra storia.

Ok, ho capito più o meno. Tranne il fatto che una unità vettoriale sia meno complessa di una scalare.
Però a questo punto uno si aspetta che una ALU vettoriale faccia più lavoro di una scalare nello stesso lasso di tempo se può operare sui dati vettoriali invece che scalare. Che è il principio che sta alla base delle istruzioni SSE/AVX se non ho capito male. Ovvero se devono operare su una quantità di dati vettoriali 4 volte più grande di una scalare fare una add/mul/fp32 etc.. dovrà richiedere meno tempo di 4 cicli svolti dall'unità scalare.
Quindi in teoria sia le unità Tahiti che quelle Kepler dovrebbero avere maggiore IPC rispetto a quelle scalari di Fermi.
Però Tahiti non ha dimostrato questo, e suggerisci che anche le unità di Kepler, pur in numero 3 volte maggiore, non andranno 3 volte tanto.
Allora, la mia domanda è... perché usarle al posto delle scalari che hanno il vantaggio di essere sempre usate al 100% (dato che il dato è sempre uno solo e quello è sempre disponibile, banda permettendo)?
O mi sfugge qualcosa? (sono Crapa di Legno mica per niente :) )

Ti sono sfuggite 5 lettere GPGPU;)

Per chi non sapesse, il GK104 è di FASCIA MEDIA, il sostituto della attuale GTX560.

Ha semplicemente cambiato nomenclatura :
GTX 680 = fascia media
GTX / GTR 685 = fascia alta
GTX 690 = dual GPU

Il GK110 uscirà più in là, quindi tutti i rumor che parlavano di una GTX 680 inferiore del 15% alla 7970 sono un ottima cosa, vuol dire che quando usciranno i modelli di punta sarà un altra storia.

Si saranno 7 mesi di ritardo per un 20% Max di prestazioni in più con un chip da 6Mld di transistor che non si sa ancora quanto consumerà. Si dessero una mossa con sto GK104 così forse calano un po' le VGA della concorrenza. Sempre che non decidano di fare cartello...

Ok, ho capito più o meno. Tranne il fatto che una unità vettoriale sia meno complessa di una scalare.


una alu vettoriale è molto più complessa di una scalare a livello di numero di transistor per le unità funzionali e i relativi registri ma e di poco più complessa per quanto riguarda tutti i circuiti che servono a far funzionare quella alu. Questo significa che una alu vettoriale di tipo, ad esempio 4-way, quindi fp128, ha una complessità a livello di logica di controllo, clock, ecc, comparabile con quella di una alu scalare fp32. Per avere la stessa potenza di calcolo con un'architettura scalare devo moltiplicare per 4 quel livello di complessità. Quindi, non è la singola alu scalare più complessa della singola alu vettoriale ma l'intera architettura vettoriale ad essere molto meno complessa, a parità di potenza di calcolo teorica, rispetto ad un'architettura scalare.


Però a questo punto uno si aspetta che una ALU vettoriale faccia più lavoro di una scalare nello stesso lasso di tempo se può operare sui dati vettoriali invece che scalare. Che è il principio che sta alla base delle istruzioni SSE/AVX se non ho capito male. Ovvero se devono operare su una quantità di dati vettoriali 4 volte più grande di una scalare fare una add/mul/fp32 etc.. dovrà richiedere meno tempo di 4 cicli svolti dall'unità scalare.

ok, tutto corretto, fin qui



Quindi in teoria sia le unità Tahiti che quelle Kepler dovrebbero avere maggiore IPC rispetto a quelle scalari di Fermi.

no, perchè sempre di una istruzione si tratta. Un'unità di fermi esegue una madd su un dato scalare in un ciclo (in realtà sono di più ma assumiamo che sia 1 ciclo). Una unità vettoriale eseguirà la stessa istruzione fp32 in un ciclo (e se è di tipo 4-way avrà 3 alu inattive); in compenso, potrà eseguire una istruzione fp128 in un ciclo, mentre una unità scalare ne impiegherà 4. Quella che permette di aumentare l'IPC riunendo microistruzioni scalari indipendenti di uno stesso thread, in una singola istruzione, è la vliw.



Però Tahiti non ha dimostrato questo, e suggerisci che anche le unità di Kepler, pur in numero 3 volte maggiore, non andranno 3 volte tanto.


esattamente


Allora, la mia domanda è... perché usarle al posto delle scalari che hanno il vantaggio di essere sempre usate al 100% (dato che il dato è sempre uno solo e quello è sempre disponibile, banda permettendo)?
O mi sfugge qualcosa? (sono Crapa di Legno mica per niente :) )

a parte il fatto che anche le scalari non sono mai usate al 100% perchè le architetture hanno diversi vincoli, ad iniziare dalla dipendenza delle istruzioni di un thread passando per il fatto che le alu sono impaccate in unità di tipo SIMD che sono obbligate ad eseguire lo stesso tipo di istruzione nel medesimo ciclo, ecc (altrimenti, se le si volesse rendere tutte realmente indipendenti ed efficienti al 100%, i vari thread processor e le linee di trasmissione, controllo, feedback, i circuiti di clock, diventerebbero di una complicazione assurda), c'è un altro motivo. Che le architetture scalari o superscalari impongono un elevato livello di complessità per tutti quei circuiti di tipo "non funzionale", il che lascia poco "spazio" per le unità di calcolo. Per questo motivo, nVidia ha fatto ricorso al "trucco" delle frequenze differenziate tra alu e resto del chip, in modo da recuperare con l'aumento delle frequenze quello che perdeva con il numero di unità di calcolo.
Cerco di prevenire una tua ulteriore domanda: perchè ATi non ha insistito con la vliw. Perchè stava diventando troppo complessa a livello di codice e perchè un'architettura vettoriale si integra meglio all'interno di un SoC asimmetrico in cui la cpu faccia da processore e la gpu, all'occorrenza, da "coprocessore matematico"

Allora è vero che Nvidia si AMDizzerà...:sofico: con queste caratteristiche ogni previsione prestazionale basata sulle vecchie architetture diventa impossibile.

Comunque non mi aspettavo una rivoluzione così radicale...:fagiano:

Ah, dalla notizia pare proprio che non sarà la fascia media ma la TOP (GTX 680)...ed è anche logico che sia così: come sempre è stato uscirà prima la Top di gamma (esclusa la solita Dual GPU ovviamente).
Cioè ora uscirà prima la fascia alta e poi la media ?
Io attendevo aprile per la fascia media nvidia (per una spesa di 200-300 euro), ora verrà tutto posticipato ?

Quindi a differenza delle ultime 2 serie ci sarà una 680 e una 685. In pratica la 680 equivarrà alla vecchio 570 mentre la 685 alla 580. Io punto a due 685 o a due 690.:D

Si saranno 7 mesi di ritardo per un 20% Max di prestazioni in più con un chip da 6Mld di transistor che non si sa ancora quanto consumerà. Si dessero una mossa con sto GK104 così forse calano un po' le VGA della concorrenza. Sempre che non decidano di fare cartello...

se fosse un +20% anche se uscisse a giugno di sicuro ci sarebbe poco da fare per amd.

no, il double clock si ottiene con semplici moltiplicatori di frequenza e non è necessaria la duplicazione delle linee di trasmissione, controlo, clock,.......

Ok grazie

Quindi a differenza delle ultime 2 serie ci sarà una 680 e una 685. In pratica la 680 equivarrà alla vecchio 570 mentre la 685 alla 580. Io punto a due 685 o a due 690.:D
No la 680 equivarrà la GTX 560

La 570 e la 580 saranno rimpiazzate dalla GTR 685 e GTX 685. :rolleyes:

Grazie mille per le spiegazioni date fino a qui.
Quindi la complessità è uguale ma la dimensione della unità di elaborazione è più grande... però allora a questo punto non ho capito come sono passati da 384 unità scalari a 1536 unità vettoriali più grandi!
no, perchè sempre di una istruzione si tratta. Un'unità di fermi esegue una madd su un dato scalare in un ciclo (in realtà sono di più ma assumiamo che sia 1 ciclo). Una unità vettoriale eseguirà la stessa istruzione fp32 in un ciclo (e se è di tipo 4-way avrà 3 alu inattive); in compenso, potrà eseguire una istruzione fp128 in un ciclo, mentre una unità scalare ne impiegherà 4. Quella che permette di aumentare l'IPC riunendo microistruzioni scalari indipendenti di uno stesso thread, in una singola istruzione, è la vliw.
Quindi vuol dire che se devo fare 4 operazioni fp32 non le posso impacchettare in una singola ALU ed eseguirle contemporaneamente? Ok, ma ci sarà l'istruzione singola della ALU che permetterà di fare questo, no?
Altrimenti non è che si guadagni molto rispetto alla VLIW di AMD quando le istruzioni non sono indipendenti.

Però a questo punto dal quel che ho capito le unità vettoriali male che vada eseguono lo stesso numero di istruzioni delle scalari nello stesso numero di cicli. Mettiamo che tutte le istruzioni siano fp32, il numero di cicli per completare il wavefront dovrebbe essere lo stesso su scalare o vettoriale, giusto?
Quindi se le unità vettoriali vanno il 60% in meno in frequenza, ma il loro numero è triplicato rispetto al GF110 e quadruplicato rispetto a GF114 uno si aspetta che comunque la differenza di potenza rispetto ad un GF110 sia quella che ho calcolato prima, ovvero 1459200/790528 = 1.8 oppure rispetto ad un GF114 con 384 shader e 820MHz di frequenza di core 1459200/629760 = 2,3.

Oppure ancora ho sbagliato a capire?? Mii se sono di coccio... anzi di legno :)
Grazie comunque per aver tentato :)

in realtà, diciamo che farebbero entrambe un passo verso "il centro" da posizioni più estreme. Si tratta di una questione "politica" :sofico:
:D

Non farti ingannare dal nome non è la top che sarà costituita dalle GTX685/690 con il GK110.
dallo stesso sito...

http://www.3dcenter.org/news/nvidia-eigene-gk104-benchmarks-schneller-als-die-radeon-hd-7970

Non è che mi faccio ingannare, è che, se confermato il cambio architetturale ecc..., sono propenso a credere che la TOP verrà fatta con la Dual GPU e non ci sarà più il chippone. O in alternativa il Chippone sarà il GK104 a seconda dei punti di vista :D

Il tutto rientrerebbe nella logica che da sempre ha contraddistinto sia AMD che NVIDIA, ovvero di fare uscire sempre per primo il chip più potente da cui poi vengono derivati gli altri.

Ad Nvidia basta che GK104 vada meglio di Thaiti il resto verrebbe da se con la Dual GPU.

no, il double clock si ottiene con semplici moltiplicatori di frequenza e non è necessaria la duplicazione delle linee di trasmissione, controlo, clock,.......

Infatti, non volevo dire quello, ma una semplice ovvietà.:(

Se lo scheduler ha una complessità tale da assegnare 32 thread per ciclo puoi scegliere di avere 32 alu al reference clock o 16 al hot clock.

L'efficienza risulterebbe uguale dato che nvidia già usa un solo ciclo di latenza (ipotetico) per eseguire i suoi warp.


ps. Yoss tornerai su appunti digitali con una nuova serie di articoli ?

Grazie mille per le spiegazioni date fino a qui.
Quindi la complessità è uguale ma la dimensione della unità di elaborazione è più grande... però allora a questo punto non ho capito come sono passati da 384 unità scalari a 1536 unità vettoriali più grandi!


semplice, perchè se si tratta di alu vettoriali, non parliamo di 1536 alu ma, ad esempio , di 384 di tipo vect4, ossia 384 alu 4-way che equivalgono, ma solo numericamente, a 1536 alu scalari :D
Ricapitolando, secondo l'esempio che ho fatto sopra, non si può più parlare di 1536 alu ma di 384, ognuna formata da "un vettore a 4 vie".
Stessa cosa, ad esempio, per tahiti: non hai 2048 alu, ma 128 alu 16-way arrangiate in gruppi da 4. Questo è il motivo per cui continuo a sostenere che si deve attribuire ad ogni cosa il nome corretto e termini come stream processor o cuda core, quando attribuiti ad una semplice alu, sono buoni per il marketing ma del tutto fuorvianti

Quindi vuol dire che se devo fare 4 operazioni fp32 non le posso impacchettare in una singola ALU ed eseguirle contemporaneamente?
solo singole istruzioni di tipo vettoriale sono eseguite in un solo ciclo. L?operazione che vuoi fare tu si può fare con architetture vliw.

Ok, ma ci sarà l'istruzione singola della ALU che permetterà di fare questo, no?
Altrimenti non è che si guadagni molto rispetto alla VLIW di AMD quando le istruzioni non sono indipendenti.

non si guadagna niente. Infatti vliw ed epic, per applicazioni di tipo special purpose sono ottime, poichè permettono di raggiungere elevate potenze di calcolo con die size ridotti rispetto ad altre architetture. Il problema è come ottimizzare una vliw molto complessa e integrarla in un SoC con una cpu x86 out of order. Molto più facile farlo con un vettoriale :D


Però a questo punto dal quel che ho capito le unità vettoriali male che vada eseguono lo stesso numero di istruzioni delle scalari nello stesso numero di cicli. Mettiamo che tutte le istruzioni siano fp32, il numero di cicli per completare il wavefront dovrebbe essere lo stesso su scalare o vettoriale, giusto?


tornando all'esempio di prima, con alu scalari 4-way (siamo nel campo delle ipotesi, ovviamente, poichè di kepler, al momento non si hanno notizie certe ma solo voci), se ho una serie di istruzioni scalari indipendenti, fermi ne potrebbe (sempre in teoria) eseguire 512 in parallelo, mentre un'architettura con 384 alu vect4 (1536 alu scalari complessive) solo 384, quindi con un ILP nettamente inferiore.



Quindi se le unità vettoriali vanno il 60% in meno in frequenza, ma il loro numero è triplicato rispetto al GF110 e quadruplicato rispetto a GF114 uno si aspetta che comunque la differenza di potenza rispetto ad un GF110 sia quella che ho calcolato prima, ovvero 1459200/790528 = 1.8 oppure rispetto ad un GF114 con 384 shader e 820MHz di frequenza di core 1459200/629760 = 2,3.

Oppure ancora ho sbagliato a capire?? Mii se sono di coccio... anzi di legno :)
Grazie comunque per aver tentato :)

con istruzioni scalari un ipotetico chip da 384 alu vect4 a 950 MHz rispetto ad uno con 384 alu scalari a 1640 MHz (parlo di frequenza nelle sole operazioni matematiche e di sole operazioni scalari fp32, perchè poi c'è da valutare il resto dell'architettura), va quasi la metà :p
Per fortuna, solo parte delle istruzioni prevedono operazioni scalari, altrimenti non avrebbero senso architetture vettoriali, vliw, epic, istruzioni SSE, MMX, BMX e ciclocross :sofico:
In ogni caso, se (siamo sempre nel campo delle ipotesi) nVidia ha deciso di adottare un'architettura di tipo vettoriale (e, se si, non conosciamo, comunque, il numero di vie delle alu e la loro organizzazione), paragonare il numero teorico di flops di fermi e kepler per trarre indicazioni sulle prestazioni, senza valutare tutto il resto, è quanto di più fuorviante si possa fare.

Infatti, non volevo dire quello, ma una semplice ovvietà.:(

Se lo scheduler ha una complessità tale da assegnare 32 thread per ciclo puoi scegliere di avere 32 alu al reference clock o 16 al hot clock.

L'efficienza risulterebbe uguale dato che nvidia già usa un solo ciclo di latenza (ipotetico) per eseguire i suoi warp.



ciao Ren, la complessità dello scheduler è relativa, tanto più che, in questo tipo di chip complessi, hai una logica a più livelli, proprio per semplificare ogni livello. Ad esempio, fermi ha un'architettura piramidale organizzata in 4 raster engine ognuno dei quali serve 4 SM con 32 alu ciascuno, gestite da 2 scheduler, in modo da poter avere 2 warp per ciclo per ogni SIMD in esecuzione. Il perchè di tutta questa apparente complicazione è presto spiegato. Ogni livello ha un suo scheduler e ogni scheduler vede solo gli elementi o i blocchi del suo livello. Così, al primo livello vengono visti 4 raster engine, al secondo livello, per ogni raster engine, 4 SM e all'interno di ogni SM 2 blocchi di 16 alu ciascuno. Il tutto è gestito da un ring bus con un suo MC che, però, anche lui, vede un numero limitato di utilizzatori. Ogni GPC o, al limite, ogni SM, può essere definito uno stream processor (la singola unità di calcolo è una semplice fpu). Insomma, come vedi, la complessità per ogni singolo livello è decisamente ridotta ma la complessità a livello generale è decisamente elevata (anche se lo sarebbe stata ancora di più senza quest'organizzazione piramidale). Tutti questi circuiti "logici" rubano molto spazio alle unità funzionali e obbligano a far lavorare, almeno le alu, a frequenza doppia per avere una sufficiente potenza di calcolo per essere competitivi. La complessità che vanno ad aggiungere i moltiplicatori di frequenza, in questo contesto, è veramente piccola. L'unico modo per ottenere un consistente aumento delle unità funzionali è variare il rapporto tra numero di transistor necessario a queste e numero di transistor per i circuiti logici e l'unico modo è quello di avere più unità di calcolo a parità di complessità dei circuiti "logici" (continuo a chiamarli così anche se il termine non è del tutto corretto ed è riduttivo, ma spero che il concetto sia chiaro). Per far ciò, le strade sono due: vliw (o epic) ma, all'aumentare della complessità dei circuiti aumentano le difficoltà di ottimizzazione del compiler e il livello di esaurimento di chi scrive driver :D , oppure architettura vettoriale (che è la strada scelta da AMD e, forse, anche da nVidia).



ps. Yoss tornerai su appunti digitali con una nuova serie di articoli ?

in realtà non sono mai andato via e sto cercando il tempo per scrivere qualcosa su tahiti e, ancora, sulla relazione tra rumore digitale e dimensione dei pixel nei sensori, argomento su cui, ultimamente, ho letto teorie piuttosto fantasiose :p
:

Sarò io che mi spiego male, ma hai risposto ad una domanda (o deduzione) che non ho fatto...:fagiano:


ps. se trovi il tempo non mi dispiacerebbe una serie di articoli sulle gpu mobile(adreno,mali,powervr).:p

se fosse un +20% anche se uscisse a giugno di sicuro ci sarebbe poco da fare per amd.

Il thread e filato via liscio fino ad ora...... evitiamo trollate di infimo livello per favore.

Grazie Yoss! Come sempre è un piacere leggerti.

Sarò io che mi spiego male, ma hai risposto ad una domanda (o deduzione) che non ho fatto...:fagiano:



probabilmente sono io che non ho capito cosa intendevi. Io ho ricollegato il tutto alla possibilità di guadagnare spazio per allocare alu di tipo scalare, riducendso la complessità dei thread processor iin seguito all'eliminazione delle frequenze differenziate tra fpu e resto del mondo :D .
Quindi la mia risposta era del tipo:"non gudagni praticamente niente facendo questo tipo di operazione, poichè il guadagno in ternmini di transistor è quello di un moltiplicatore di frequenza in meno. In quanto alla possibilità di scheduare n thread per ciclo, questa è indipendente dalla frequenza di funzionamento dello shader core ma dipende dal numero di registri a disposizione per SM. Ogni SM di fermi può schedulare 2 warp, ovvero 2 volte 32 thread, uno per ogni 16 alu. Ossia, ogni gruppo di 16 alu ha a dispsizione 16384 registri da 32 bit in modo tale da poter "caricare" i dati relativi a 32 thread di cui, ad ogni ciclo, ne viene mandato uno in esecuzione, indipendentemente dala frequenza del chip.
Stavolta spero di aver risposto :D


ps. se trovi il tempo non mi dispiacerebbe una serie di articoli sulle gpu mobile(adreno,mali,powervr).:p

non è proprio il mio campo, però vedo se riesco a tirare fuori qualcosa di accettabile :p

Grazie yossarian.
Ora ho capito. Il fraintendimento è su cosa si intenda per shader a questo punto. Un po' come lo è stato con il VLIW.
Effettivamente è difficile catalogare questo tipo di architetture. Perché contare le semplici ALU senza considerare la dimensione del vettore su cui operano, non è ancora giusto. 100 unità che operano su un vettore x4 sono diverse da 100 che operano su un vettore x2. Tuttavia il fraintendimento è tra il numero di queste ALU e quelle vecchie scalari. Una volta che si è capito come "contarle" allora si possono fare i confronti.

A questo punto la cosa più facile per "indovinare" le presunte prestazioni è vedere quali altre risorse hanno aumentato. Le TMU sono raddoppiate, e se tanto mi dà tanto...

Grazie yossarian.
Ora ho capito. Il fraintendimento è su cosa si intenda per shader a questo punto. Un po' come lo è stato con il VLIW.
Effettivamente è difficile catalogare questo tipo di architetture. Perché contare le semplici ALU senza considerare la dimensione del vettore su cui operano, non è ancora giusto. 100 unità che operano su un vettore x4 sono diverse da 100 che operano su un vettore x2. Tuttavia il fraintendimento è tra il numero di queste ALU e quelle vecchie scalari. Una volta che si è capito come "contarle" allora si possono fare i confronti.

A questo punto la cosa più facile per "indovinare" le presunte prestazioni è vedere quali altre risorse hanno aumentato. Le TMU sono raddoppiate, e se tanto mi dà tanto...
e anche, nel caso che l'ipotesi di alu vettoriali sia corretta, capire a quante vie siano. Prendendo per buone le indiscrezioni su numero di unità di fpu, dimensioni del die e numermo di tmu, sarei portato a ipotizzare alu 12-way, quindi non troppo dissimili dalle 16-way di tahiti. In quel caso, si dovrebbe parlare di chip con 128 fpu di tipo vect12 e non di chip con 1536 fpu, perchè in caso di trattamento di dati scalari, capisci che le cose cambiano e di parecchio :p

probabilmente sono io che non ho capito cosa intendevi. Io ho ricollegato il tutto alla possibilità di guadagnare spazio per allocare alu di tipo scalare, riducendso la complessità dei thread processor iin seguito all'eliminazione delle frequenze differenziate tra fpu e resto del mondo :D .
cut


esatto, pure io avevo capito così, per questo chiedevo anche un tuo parere al riguardo...

e anche, nel caso che l'ipotesi di alu vettoriali sia corretta, capire a quante vie siano. Prendendo per buone le indiscrezioni su numero di unità di fpu, dimensioni del die e numermo di tmu, sarei portato a ipotizzare alu 12-way, quindi non troppo dissimili dalle 16-way di tahiti. In quel caso, si dovrebbe parlare di chip con 128 fpu di tipo vect12 e non di chip con 1536 fpu, perchè in caso di trattamento di dati scalari, capisci che le cose cambiano e di parecchio :p

si, perchè Amd in questi anni ha sempre detto X sp di tipo vliw5, o adesso Y sp di tipo vect16 :asd:

edit: se così fosse l'architettura nvidia, si perderebbe quella "facilità" a programmare i driver che si aveva con la superscalare, e che era imho uno dei punti di forza nVidia da g80 a Fermi?

esatto, pure io avevo capito così, per questo chiedevo anche un tuo parere al riguardo...



sentiamo Ren, per capire cosa intendeva. Io ho risposto sulla base della tua interpretazione



si, perchè Amd in questi anni ha sempre detto X sp di tipo vliw5, o adesso Y sp di tipo vect16 :asd:


sono anni che sto invitando tutti a chiamare le cose con il nome corretto, al di là delle uscite dei reparti di marketing


edit: se così fosse l'architettura nvidia, si perderebbe quella "facilità" a programmare i driver che si aveva con la superscalare, e che era imho uno dei punti di forza nVidia da g80 a Fermi?

non necessariamente, ma perderesti l'efficienza di un'architettura superscalare, guadagnando in "forza bruta". Insomma, tante unità di calcolo in più ma minor efficienza architetturale

sentiamo Ren, per capire cosa intendeva. Io ho risposto sulla base della tua interpretazione

si certo :)


sono anni che sto invitando tutti a chiamare le cose con il nome corretto, al di là delle uscite dei reparti di marketing

:D

non necessariamente, ma perderesti l'efficienza di un'architettura superscalare, guadagnando in "forza bruta". Insomma, tante unità di calcolo in più ma minor efficienza architetturale

ok grazie, spero comunque non si abbia una situazione tipo la vliw e il compilatore ecc ecc

ok grazie, spero comunque non si abbia una situazione tipo la vliw e il compilatore ecc ecc

Beh da quello che ha scritto yoss, credo che questo pericolo sia scongiurato. La VLIW in teoria doveva essere più performante dell'approccio della concorrenza (anche Buldozzer a dire il vero:muro: :muro: :muro: ), purtroppo le SP venivano sfruttate male con parecchie unita che giravano a vuoto a causa del codice e driver mal ottimizzati. Con questo approccio non mi sembra ci siano di questi rischi. Almeno e quello che ho capito :D

Beh a dire il vero, a parte nelle prime incarnazioni, le Vliw mi pare finora abbiano funzionato meglio della concorrenza.
Ma come ha detto Yossarian, due elementi ne hanno favorito l'abbandono da parte di AMD: la difficoltà ad ottimizzare i driver dovuta alla crescente complessità e la necessità di utilizzare la gpu come strumento di calcolo generico fino alla sua integrazione con la cpu (hsa).

Beh a dire il vero, a parte nelle prime incarnazioni, le Vliw mi pare finora abbiano funzionato meglio della concorrenza.
Ma come ha detto Yossarian, due elementi ne hanno favorito l'abbandono da parte di AMD: la difficoltà ad ottimizzare i driver dovuta alla crescente complessità e la necessità di utilizzare la gpu come strumento di calcolo generico fino alla sua integrazione con la cpu (hsa).

A me pare che invece i chip della concorrenza andassero di più;) Teoricamente dovevano andare di più ma venivano sfruttati al 60-70% a causa di questa incomprensibile :sofico: combinazione di lettere TWIMTBP. Credo che in AMD abbiano sottovalutato questo aspetto e quando si sono svegliati era tardi oramai. Non vorrei dire una scemenza (yoss mi smonterà il tutto) ma credo che Cayman sia sulla carta più potente di Tahiti..... pero Tahiti viene sfruttato meglio.

probabilmente sono io che non ho capito cosa intendevi. Io ho ricollegato il tutto alla possibilità di guadagnare spazio per allocare alu di tipo scalare, riducendso la complessità dei thread processor iin seguito all'eliminazione delle frequenze differenziate tra fpu e resto del mondo :D .
Quindi la mia risposta era del tipo:"non gudagni praticamente niente facendo questo tipo di operazione, poichè il guadagno in ternmini di transistor è quello di un moltiplicatore di frequenza in meno.

Infatti non intendevo un guadagno in termini di transistor e superficie, ma un peggioramento, volto ad abbassare i consumi.

Rimuovere hotclock, ma mantenere lo stesso throughtput con il doppio delle alu al reference clock.

Se nvidia non spara numeri a caso (0.1mm2|40nm per una FPU, oltretutto a 64bit), stiamo parlando di qualche decina di mm2 in più.

A me pare che invece i chip della concorrenza andassero di più;) [...]
Andavano di più perchè erano più grossi.
Ma dato che qui stiamo parlando di architettura, ciò che conta è il chip con migliori prestazioni per mm^2 e con certi consumi, non quello che aveva migliori prestazioni in assoluto.

Infatti non intendevo un guadagno in termini di transistor e superficie, ma un peggioramento, volto ad abbassare i consumi.

Rimuovere hotclock, ma mantenere lo stesso throughtput con il doppio delle alu al reference clock.

Se nvidia non spara numeri a caso (0.1mm2|40nm per una FPU, oltretutto a 64bit), stiamo parlando di qualche decina di mm2 in più.

ok, ora è chiaro anche se ci sono cose che non mi tornano. La frequenza delle alu non c'entra niente con la capacità di eseguire calcoli in fp64. Le alu sono fp32 e solo le operazioni di load/store e addressing avvengono a 64 bit. Il fatto di poter schedulare un warp a 64 bit al posto di 2 a 32 bit dipende esclusivamente dal fatto che, quando lavorano a 64 bit, le alu sono accoppiate (quindi, al posto di 32 alu fp32 per SM hai 16 alu fp64).
Sul risparmio energetico, invece, è vero che se ho il doppio delle unità di calcolo a frequenza dimezzata consumo di meno.

ok, ora è chiaro anche se ci sono cose che non mi tornano. La frequenza delle alu non c'entra niente con la capacità di eseguire calcoli in fp64. Le alu sono fp32 e solo le operazioni di load/store e addressing avvengono a 64 bit. Il fatto di poter schedulare un warp a 64 bit al posto di 2 a 32 bit dipende esclusivamente dal fatto che, quando lavorano a 64 bit, le alu sono accoppiate (quindi, al posto di 32 alu fp32 per SM hai 16 alu fp64).
Sul risparmio energetico, invece, è vero che se ho il doppio delle unità di calcolo a frequenza dimezzata consumo di meno.

Il riferimento alla FPU 64bit era solo per chiarire la sua grandezza in mm2, non per menzionare il metodo di esecuzione dei calcoli 64bit di Fermi.

Per la serie, se una fpu 64bit occupa 0.1mm2, quella da 32bit occuperà ancora meno...

Il riferimento alla FPU 64bit era solo per chiarire la sua grandezza in mm2, non per menzionare il metodo di esecuzione dei calcoli 64bit di Fermi.

Per la serie, se una fpu 64bit occupa 0.1mm2, quella da 32bit occuperà ancora meno...

ma fermi non ha fpu a 64 bit, per questo non ho chiaro a cosa abbiano fatto riferimento e non mi è chiaro cosa c'entri la frequenza dimezzata delle alu con i calcoli a 64 bit.

ma fermi non ha fpu a 64 bit, per questo non ho chiaro a cosa abbiano fatto riferimento e non mi è chiaro cosa c'entri la frequenza dimezzata delle alu con i calcoli a 64 bit.

La fonte è un paper nvidia che parla in generale di scelte di design delle gpu (presenti e future).

Infatti la frequenza non centra niente nei calcoli 64bit.

La fonte è un paper nvidia che parla in generale di scelte di design delle gpu (presenti e future).

Infatti la frequenza non centra niente nei calcoli 64bit.

La mia prima risposta a appleroof era relativa a questo post che lui aveva quotato
I chip nvidia hanno dei circuiti di logica interna che gestiscono il doppio delle informazioni per via del double clock. Se elimini il doppio clock, le alu che occupano pochissimo spazio raddoppiano, ma l'altra logica rimane la stessa. In poche parole, il diesize e le prestazioni non variano di molto, ma i consumi migliorano.

Fermi scalato occuperebbe circa 370-380mm2, quindi non mi sembra difficile integrare il design della vecchia serie mainstream (3cluster-8tmu), togliendo bus e rop's per rientrare sotto i 400mm2.

L'aumento dovrebbe riferirsi al chip top di gamma (in uscita più tardi) ed è di quasi 3X.

in cui parli di gestione del doppio delle informazioni a causa del double clock. Ora, poichè non serve avere il doppio dei circuiti logici per gestire blocchi a differenti valori di clock, mi sono limitato a rispondere che l'unica cosa che si poteva rimuovere era qualche moltiplicatore di frequenza. Tutto questo non ha niente a che vedere con alu a 64 bit. In quanto a queste ultime, di fatto dntro i chip nVidia della serie fermi non esistono fpu a 64 bit dedicate, quindi no ho chiaaro cosa possano rimuovere. Se, invece, ti riferisci a qualche paper del periodo di gt200, allora è un'altra cosa, dato che quella derivata da gt200 è l'unica famiglia ad avere alu fp64 dedicate

Yoss non fissarti su questa benedetta alu fp64, perchè era una semplice unità di misura in mm2, per capire quanto una alu occupi. Non c'entra una mazza (è fuori contesto) con il funzionamento di fermi o altre GPU.

in cui parli di gestione del doppio delle informazioni a causa del double clock. Ora, poichè non serve avere il doppio dei circuiti logici per gestire blocchi a differenti valori di clock, mi sono limitato a rispondere che l'unica cosa che si poteva rimuovere era qualche moltiplicatore di frequenza.

Qui mi sono spiegato male, non intendevo che serve il doppio della logica per gestire il double clock, ma che fermi ha abbastanza logica da gestire un throughput doppio, quindi avere 512x2(hot clock) o 1024alu non è poi così diverso(si tratta di pochi mm2 in più).

Spero di essermi spiegato, perchè comincio ad accusare la stanchezza... :sofico:

Yoss non fissarti su questa benedetta alu fp64, perchè era una semplice unità di misura in mm2, per capire quanto una alu occupi. Non c'entra una mazza (è fuori contesto) con il funzionamento di fermi o altre GPU.



Qui mi sono spiegato male, non intendevo che serve il doppio della logica per gestire il double clock, ma che fermi ha abbastanza logica da gestire un throughput doppio, quindi avere 512x2(hot clock) o 1024alu non è poi così diverso(si tratta di pochi mm2 in più).

Spero di essermi spiegato, perchè comincio ad accusare la stanchezza... :sofico:

ora mi sono perso del tutto :D
512x2 non ha senso. Il fatto che le 512 alu di fermi funzionino a frequenza doppia rispetto al resto del chip non comporta il raddoppio della logica di controllo. Si tratta semplicemente di uno stadio che lavora a velocità doppia rispetto al resto ma i cui risultati sono messi a disposizione dei restanti stadi che lavorano a frequenze "ordinarie". Insomma, non c'è una doppia pipeline una per le frequenze normali e una per le frequenze doppie ma un'unica pipeline con stadi che lavorano a frequenza differente per il semplice motivo che il numero di fpu è sottodimensionato rispetto ai restanti blocchi del chip. Questo significa che le linee di trasmissione controllo, i thread processor, gli scheduler, i sequencer non sono raddoppiati. Questo significa che passare da 512 alu da 1500 Mhz a 1024 alu da 750 MHz ti permette di risparmiare solo i transistor necessari ai moltiplicatori di frequenza (ovvero, praticamente, niente). Quello che ti permette di risparmiare è l'utilizzo di alu vettoriali.
Se fosse vero quello che sostieni, allora nVidia avrebbe, finora, sbagliato tutto, in quanto se avesse sostituito n alu a x MHz con 2n alu a x/2 MHz avrebbe ottenuto le stesse prestazioni con consumi minori, a parità di die size. Invece era proprio questo che non era possibile ottenere e si è dovuti ricorrere al "trucco" delle frequenze doppie per le fpu. Per farlo,è sufficiente inserire dei moltiplicatori di frequenza lungo la pipeline che raddoppino il clock in ingresso allo shader dore e lo dimezzino in uscita dallo shader core.

Beh a dire il vero, a parte nelle prime incarnazioni, le Vliw mi pare finora abbiano funzionato meglio della concorrenza.
Ma come ha detto Yossarian, due elementi ne hanno favorito l'abbandono da parte di AMD: la difficoltà ad ottimizzare i driver dovuta alla crescente complessità e la necessità di utilizzare la gpu come strumento di calcolo generico fino alla sua integrazione con la cpu (hsa).

Non hanno funzionato meglio, visto che a causa del lavoraccio sui driver non sono mai state sfruttate bene, hanno svolto il loro compito ossia dare da rv770 in poi gpu piccole ma sufficientemente potenti, ma la vliw è stata un incubo di efficenza intesa non come p/w


Andavano di più perchè erano più grossi.
Ma dato che qui stiamo parlando di architettura, ciò che conta è il chip con migliori prestazioni per mm^2 e con certi consumi, non quello che aveva migliori prestazioni in assoluto.

No andavano di più perché più efficiente l'architettura, e forse se nvidia non avesse avuto la necessità -di fatto non è stata proprio una scelta- di entrare nel mercato hpc, forse sarebbero state pure più vicine alle p/w della concorrenza in ambito gaming. In ambito gpgpu pensa che fermi è vantaggioso performance/watt.

Non hanno funzionato meglio, visto che a causa del lavoraccio sui driver non sono mai state sfruttate bene, hanno svolto il loro compito ossia dare da rv770 in poi gpu piccole ma sufficientemente potenti, ma la vliw è stata un incubo di efficenza intesa non come p/w

No andavano di più perché più efficiente l'architettura, e forse se nvidia non avesse avuto la necessità -di fatto non è stata proprio una scelta- di entrare nel mercato hpc, forse sarebbero state pure più vicine alle p/w della concorrenza in ambito gaming. In ambito gpgpu pensa che fermi è vantaggioso performance/watt.
Non sono affatto d'accordo.

Prima di tutto, l'efficienza intesa come sfruttamento delle alu non è un parametro di paragone. Si sa che VLIW ha più difficoltà a sfruttare tutte le unità di calcolo, ma questo fa parte della scelta di questo tipo di architettura.
Per capirci... che ti importa se riesci a sfruttare solo la metà delle tue alu quando rispetto all'altra architettura, nello stesso spazio, riesci a metterne il triplo? (i numeri sono a caso, è giusto per fare un esempio concettuale).

Per l' "andare di più" non vedo come tu possa affermare una cosa simile, dato che il rapporto dimensione/potenza è sempre stato a favore delle amd con architettura VLIW, con casi eclatanti come le hd4xxx contro le gtx2xx.

Non sono affatto d'accordo.

non me l'aspettavo :D

Prima di tutto, l'efficienza intesa come sfruttamento delle alu non è un parametro di paragone. Si sa che VLIW ha più difficoltà a sfruttare tutte le unità di calcolo, ma questo fa parte della scelta di questo tipo di architettura.
Per capirci... che ti importa se riesci a sfruttare solo la metà delle tue alu quando rispetto all'altra architettura, nello stesso spazio, riesci a metterne il triplo? (i numeri sono a caso, è giusto per fare un esempio concettuale).

Per l' "andare di più" non vedo come tu possa affermare una cosa simile, dato che il rapporto dimensione/potenza è sempre stato a favore delle amd con architettura VLIW, con casi eclatanti come le hd4xxx contro le gtx2xx.

non vedi come io possa affermare una cosa simile, o non vedi le review da circa 6 anni a questa parte? ma cosa c'entra il rapporto dimensione/potenza? Alla fine devi vedere il risultato in termini assoluti, che è quello che conta per la maggior parte dei gamers, sono anni che in termini assoluti le architetture nVidia hanno prestazioni maggiori che quelle Amd (superscalare vs vliw).

Non ho poi messo a caso la circostanza che hai bellamente ignorato, ossia la necessità di nVidia di progettare le proprie gpu anche per l'uso gpgpu, necessità che alla fine ha avvertito anche Amd, se è vero che ha abbandonato la vliw, buona per il gaming, scarsa per la programmabilità in ottica gpgpu; nonostante questa necessità le gpu nVidia hanno continuato ad offrire appunto eccellenti prestazioni anche nel gaming.

Ad ogni modo è un dato di fatto che le vliw Amd in ambito gaming sono state più efficenti performance/watt* (sopratutto da rv770 in poi) e quelle nVidia più efficenti in termini di performance (ripeto, se poi spostiamo il discorso sul gpgpu che non può essere ignorato alla bisogna, visto che esiste ed incide sulle scelte di nVidia, ed adesso pure di Amd, fermi e company diventano efficenti anche lato performance/watt)

adesso forse (in attesa di sapere i dettagli di kepler) stanno convergendo per motivi diversi (l'una perchè la vliw è complicata e rende poco in termini assoluti, oltre che più difficilmente programmabile in ambito hpc; l'altra perchè dà vita a scarsi risultati p/w in ambito gaming; entrambe credo avrebbero peggiorato questi lati negativi con il prgredire del tempo, per cui per motivi diversi si sono -sarebbero, perchè su kepler non ci sono ancora dati certi sull'architettura- imposte svolte)

non credo ci sia un "vincitore" perchè come sempre entrambe le scelte hanno avuto punti di forza e debolezza (la perfezione non è di questo mondo :D ), e per affermare che non ci sia il vincitore credo serva un minimo di onestà intellettuale che nei tuoi post non ho visto (magari per mie limiti interpretativi :D ), per cui ti ho risposto in quel modo.


* non dimentichiamo poi che le potenzialità sono state spesso frustrate dalla difficoltà di programmare i driver, in multigpu è stato quasi un disastro poi, che te ne fai poi di potenza senza controllo? http://hardocp.com/article/2012/01/17/amd_crossfirex_drivers_opportunity_lost/

Eheh, sono prevedibile! :p
Per non divagare troppo, quoto solo alcuni punti:

ma cosa c'entra il rapporto dimensione/potenza? Alla fine devi vedere il risultato in termini assoluti [...]
Ma come cosa centra!?! Se si sta parlando di quale architettura è la scelta migliore, allora è l'unica cosa che conta.
Se Nvidia con la sua mania del chippone ha dovuto fare padelle grandi il doppio (si fa per dire) per avere prestazioni superiori, quella è una scelta di nvidia (scelta che ha dovuto fare i conti con le difficoltà produttive che conosciamo, da g200 in poi). AMD ha scelto una politica di produzione differente, con chip non troppo grandi per massimizzare le rese.
E se vogliamo infierire, AMD ha anche inserito molte ridondanze nei chip per questo motivo, che ne aumentano il die size.

Non confondiamo le scelte commerciali con l'architettura, perchè a questo punto uno potrebbe dire: e se amd avesse fatto un chip grosso come quello nvidia, chi sarebbe andato di più?
Se si valuta un'architettura, va fatto a parità di die size e consumi.

Non ho poi messo a caso la circostanza che hai bellamente ignorato, ossia la necessità di nVidia di progettare le proprie gpu anche per l'uso gpgpu[...]
Ignorato semplicemente perchè la maggiore attitudine dell'approccio al GpGPU è intrinseco delle architetture superscalari, quindi fa già parte del contesto.
Certo, può contemplare un aumento di die size per le cache e il supporto ai diversi linguaggi di programmazione, ma a questo punto ho preferito spannometricamente fare pari e patta con le ridondanze dei chip amd, dato che non sono in grado di valutare precisamente l'impatto di nessuno dei due.

non credo ci sia un "vincitore" [...]
Al di la dei discorsi sull'onestà intellettuale (perdonami, ma anche io ho la stessa impressione sulle tue risposte, ma preferisco evitare allusioni), credo che al momento l'approccio AMD si sia rivelato vincente.
Ovviamente ogni scelta va rapportata al momento in cui questa viene fatta: ad oggi potrebbe non essere più la scelta giusta, e infatti sia AMD che Nvidia (pare) stanno convergendo su posizioni meno estreme.

non dimentichiamo poi che le potenzialità sono state spesso frustrate dalla difficoltà di programmare i driver, in multigpu è stato quasi un disastro poi, che te ne fai poi di potenza senza controllo? [...]
Non sono sicuro di aver colto il riferimento al multiGPU, dato che nelle ultime incarnazioni l'efficienza in multiGPU delle schede AMD non ha nulla a che invidiare a quelle nvidia (anzi, all'uscita delle HD6xxx aveva mostrato percentuali di incremento superiori).
Non direi quindi che l'approccio VLIW abbia minato questa caratteristica... al più è una pecca di AMD, se i problemi citati nell'articolo sono reali (non ho esperienza diretta e non mi pronuncio a riguardo).

Eheh, sono prevedibile! :p
Per non divagare troppo, quoto solo alcuni punti:


Ma come cosa centra!?! Se si sta parlando di quale architettura è la scelta migliore, allora è l'unica cosa che conta.
Se Nvidia con la sua mania del chippone ha dovuto fare padelle grandi il doppio (si fa per dire) per avere prestazioni superiori, quella è una scelta di nvidia (scelta che ha dovuto fare i conti con le difficoltà produttive che conosciamo, da g200 in poi). AMD ha scelto una politica di produzione differente, con chip non troppo grandi per massimizzare le rese.
E se vogliamo infierire, AMD ha anche inserito molte ridondanze nei chip per questo motivo, che ne aumentano il die size.

Non confondiamo le scelte commerciali con l'architettura, perchè a questo punto uno potrebbe dire: e se amd avesse fatto un chip grosso come quello nvidia, chi sarebbe andato di più?
Se si valuta un'architettura, va fatto a parità di die size e consumi.


Ignorato semplicemente perchè la maggiore attitudine dell'approccio al GpGPU è intrinseco delle architetture superscalari, quindi fa già parte del contesto.
Certo, può contemplare un aumento di die size per le cache e il supporto ai diversi linguaggi di programmazione, ma a questo punto ho preferito spannometricamente fare pari e patta con le ridondanze dei chip amd, dato che non sono in grado di valutare precisamente l'impatto di nessuno dei due.

già qua abbiamo un punto fermo dove siamo d'accordo :D

Al di la dei discorsi sull'onestà intellettuale (perdonami, ma anche io ho la stessa impressione sulle tue risposte, ma preferisco evitare allusioni), credo che al momento l'approccio AMD si sia rivelato vincente.
Ovviamente ogni scelta va rapportata al momento in cui questa viene fatta: ad oggi potrebbe non essere più la scelta giusta, e infatti sia AMD che Nvidia (pare) stanno convergendo su posizioni meno estreme.

imho continui nel tuo discorso, se nVidia ha recuperato miliardi dal mercato GPGPU

But why does AMD want to chase compute in the first place when they already have a successful graphics GPU business? In the long term GCN plays a big part in AMD’s Fusion plans, but in the short term there’s a much simpler answer: because they have to.

In Q3’2011 NVIDIA’s Professional Solutions Business (Quadro + Tesla) had an operating income of 95M on 230M in revenue. Their (consumer) GPU business had an operating income of 146M, but on a much larger 644M in revenue. Professional products have much higher profit margins and it’s a growing business, particularly the GPU computing side. As it stands NVIDIA and AMD may have relatively equal shares of the discrete GPU market, but it’s NVIDIA that makes all the money. For AMD’s GPU business it’s no longer enough to focus only on graphics, they need a larger piece of the professional product market to survive and thrive in the future. And thus we have GCN.

http://www.anandtech.com/show/5261/amd-radeon-hd-7970-review/2

a fronte di un mercato, quello delle gpu discrete che sul lungo periodo è dato come al capolinea, qual'è la scelta vincente o meno (anche se in qualche modo obbligata? :D )

da non dimenticare che contemporaneamente, se Amd grazie ai suoi ottimi prodotti ha conquistato fette di marketshare in mabito vga discrete per il gaming, nVidia ha resistito benissimo, questo dato da solo vale a dire che nonostante le sue gpu siano state pensate con più di un occhio di riguardo al gpgpu, hanno comunque reso bene sul fronte gaming....tutto sommato direi che secondo me è stata leggermente più premiante la scelta nVidia, quindi.


p.s.: chiariamo in maniera esplicita: nessuna allusione con le parolee "onestà intellettuale", non volevo offenderti nè chiamarti fanboy, solo dire quello che ho detto...


Non sono sicuro di aver colto il riferimento al multiGPU, dato che nelle ultime incarnazioni l'efficienza in multiGPU delle schede AMD non ha nulla a che invidiare a quelle nvidia (anzi, all'uscita delle HD6xxx aveva mostrato percentuali di incremento superiori).
Non direi quindi che l'approccio VLIW abbia minato questa caratteristica...

non c'è nulla da cogliere: basta leggere l'articolo di hardopc. Non è filosofia zen :D

Secondo me nel valutare vincente la strategia nvidia non tieni conto di alcune cose:
- davo sott'inteso che si parlasse dell'ambito consumer, e li Nvidia ha sofferto.
- nvidia vende bene anche per il brand. A parti invertite dubito che AMD avrebbe retto.
- nvidia era ed è avanti sulle piattaforme professionali, ad AMD non sarebbe bastato fare una piattaforma adatta al GpGPU, aveva bisogno di sviluppare anche la parte software e il supporto. E difatti ci sta arrivando piano piano col tempo, farlo prima sarebbe stato prematuro.
Io speravo avremo visto qualcosa di adeguato in minor tempo, ma a quanto pare il progetto che porterà poi a fusion richiede più tempo.

non c'è nulla da cogliere: basta leggere l'articolo di hardopc. Non è filosofia zen :D
Ciò che intendevo dire è che una eventuale scelta scellerata di AMD di ridurre il supporto al multiGPU, non è nulla di legato al discorso precedente.
In questo senso non colgo il nesso.

Secondo me nel valutare vincente la strategia nvidia non tieni conto di alcune cose:
- davo sott'inteso che si parlasse dell'ambito consumer, e li Nvidia ha sofferto.
- nvidia vende bene anche per il brand. A parti invertite dubito che AMD avrebbe retto.
- nvidia era ed è avanti sulle piattaforme professionali, ad AMD non sarebbe bastato fare una piattaforma adatta al GpGPU, aveva bisogno di sviluppare anche la parte software e il supporto. E difatti ci sta arrivando piano piano col tempo, farlo prima sarebbe stato prematuro.
Io speravo avremo visto qualcosa di adeguato in minor tempo, ma a quanto pare il progetto che porterà poi a fusion richiede più tempo.

1) non si parlava di architetture più o meno buone? Nel valutarne la bontà non si può imho prescindere dal contesto che ha comportato la scelta di adozione, sennò "tiriamo" il discorso solo da una parte e non credo sia obiettivo....
2) vende bene per il brand dove, in ambito gaming? Non credo che Ati fosse meno conosciuto e stimato come marchio in quell'ambito...cmq se uno si è fatto un marchio se l'è fatto con i fatti, non credi?
3) ma anche qui siamo sul discorso che i risultati vengono a seguito di una scelta strategica e del cercare di lavorare bene nella direzione intrapresa: una volta erano le Quadro con i relativi driver, oggi il gpgpu con CUDA, se nVidia negli anni si è fatta un nome in realtà dove i fanboy stanno a zero, ci sarà un perchè

forse Amd pensava di poter supplire grazie alle cpu, nel frattempo, ad ogni modo sono contento che pure Amd ci sia buttata infine, un pò di concorrenza non può che far bene, in ogni ambito (direbbe Monti :stordita: :D ), qui si pone imho un'ulteriore difficoltà per nVidia che -credo- non a caso si stà inventando un sistema integrato con cpu arm (amd ha invece le collaudate x86 nel suo arco) per il mondo hpc

Ciò che intendevo dire è che una eventuale scelta scellerata di AMD di ridurre il supporto al multiGPU, non è nulla di legato al discorso precedente.
In questo senso non colgo il nesso.

il nesso risiede nel fatto che se valutiamo la bontà di un'architettura a 360° non possiamo prescindere anche dal supporto sw...ti faccio un esempio da ex-possessore di 4870 e 5850: in questo perido ho valutato l'acquisto di 2 7950 come opzione fra altre, mi ha frenato molto (tra molte altre considerazioni, in verità, vabbè) lo scarso supporto driver finora dimostrato in multigpu, dove invece con lo sli mi sono trovato alla grandissima...

chiudo per dire: che te ne fai di una potenza superstellare se poi non puoi usarla? E' come avere una Ferrari con le gomme e le sospensioni di una Panda :D

Cerco di rispondere in breve :p

1) Certamente, ma devi guardare come il discorso è iniziato. Un utente diceva che le schede nvidia andavano meglio (si parlava di ambito gaming consumer), io gli ho detto che invece in quell'ambito la VLIW di amd aveva dato risultati migliori.
Che poi la scelta nvidia abbia pagato altrove è un discorso differente.

2) Intendevo in ambito gaming, ma direi che vale anche in generale. Per quanto Ati sia un brand conosciuto, storielle come quella che nvidia fa driver migliori fanno ancora presa su molti.

3) Se devo essere sincero, data l'anzianità del progetto fusion, pensavo che AMD si sarebbe buttata sul GpGPU prima di Nvidia. Direi che mi sbagliavo! :p

4) Per il crossfire, io non do affatto per scontato che l'approccio VLIW complichi la sua gestione lato driver. La difficoltà sta nell'ottimizzare l'architettura, ma una volta fatto, siamo sicuri che passare al crossfire richieda ulteriori difficoltà? O si tratta semplicemente di un "fattore esterno"?
PS: dato che AMD con la serie HD79xx è passato al vettoriale, le tue preoccupazioni sui driver dovrebbero ridimensionarsi notevolmente! ;)

Il fatto che le 512 alu di fermi funzionino a frequenza doppia rispetto al resto del chip non comporta il raddoppio della logica di controllo. Si tratta semplicemente di uno stadio che lavora a velocità doppia rispetto al resto ma i cui risultati sono messi a disposizione dei restanti stadi che lavorano a frequenze "ordinarie". Insomma, non c'è una doppia pipeline una per le frequenze normali e una per le frequenze doppie ma un'unica pipeline con stadi che lavorano a frequenza differente per il semplice motivo che il numero di fpu è sottodimensionato rispetto ai restanti blocchi del chip. Questo significa che le linee di trasmissione controllo, i thread processor, gli scheduler, i sequencer non sono raddoppiati. Questo significa che passare da 512 alu da 1500 Mhz a 1024 alu da 750 MHz ti permette di risparmiare solo i transistor necessari ai moltiplicatori di frequenza (ovvero, praticamente, niente). Quello che ti permette di risparmiare è l'utilizzo di alu vettoriali.


Mi era già chiaro che non c'è un raddoppio della pipeline, ma solo una doppia frequenza come nel pentium4 per il solo stage di esecuzione.

Gestire le dipendenze di 32 thread avrà qualche peso o no in termini di logica ?

Se non sbaglio ci sono 2x16 scheduler che gestiscono 1024 thread al reference clock per ciclo...

Mi era già chiaro che non c'è un raddoppio della pipeline, ma solo una doppia frequenza come nel pentium4 per il solo stage di esecuzione.

Gestire le dipendenze di 32 thread avrà qualche peso o no in termini di logica ?

Se non sbaglio ci sono 2x16 scheduler che gestiscono 1024 thread al reference clock per ciclo...

si, ma mi auguro che abbiano mantenuto un'impostazione del genere e, se così fosse, da quel lato non si guadagnerebbe niente.
Quello a cui voglio arrivare è che mantenendo un'architettura come quella di fermi superscalare non puoi triplicare le fpu passando da 40 a 28 nm e, addirittura, riducendo il die size e, a maggior ragione non puoi farlo eliminando quei circuiti che o in fermi non esistono (alu fp64) o gli permettono di mantenere un'efficienza architetturale elevata (i 2 warp scheduler per SIMD).

@Yossarian e pleg
immensi grazie ad entrambi per le info date. Pleg, mi piace essere sorpreso.. quando la sorpresa è positiva però! Ovvero, dacci indicazione anonima e casuale del fatto che il GK100/GK110 uscirà prima di quest'estate :)
Se per sorpresa intendi che dovremo aspettare l'anno prossimo per il nuovo chippone.. eh, sì rimarrei sorpreso ma anche un po' deluso.
Il tuo amico Charlie sostiene che il tape-out del GK110 sia stato fatto solo recentemente e che quindi ci vorranno 6 mesi per vederlo sugli scaffali...

@calabar e appleroof
In verità l'architettura scalare di nvidia si è mostrata molto più potente (e flessibile) di quella VLIW di AMD. Infatti il G80 e la revisione G92 hanno fatto sfaceli al punto di convincere nvidia che l'architettura fosse pronta per essere usata anche in ambito GPGPU.
Al tempo del G92 le architetture VLIW di AMD in confronto facevano pena. Tutti hanno parlato (qualcuno lamentandosi) per un sacco di tempo del fatto che nvidia sia riuscita a riciclare il G92 per tre serie consecutive (via via in fasce sempre più basse) semplicemente perché AMD non è riuscita a fare nulla di equivalente in perf/watt (in perf assolute ovviamente sì, ma come detto, quando si scendeva alla fascia con le perf del G92 nessuna nuova architettura AMD è stata concorrenziale per diverso tempo).
Poi nvidia ha decido di fare "le mattonelle" con molta più logica per la gestione del codice GPGPU (con uso di transistor e watt) invece che metterci molte più unità di elaborazione o risparmiare sui watt e quindi è ovvio che l'efficienza di nvidia nel gaming sia scesa.
Rimane comunque il fatto che l'architettura scalare di nvidia abbia mostrato di essere superiore perché adatta a gaming + GPGPU mentre quella di AMD solo al gaming. Per questo le scelte strategiche delle due aziende sono state diverse negli ultimi anni.

@calabar
La questione dell'inserimento di risorse per il supporto a linguaggi alto livello + migliori cache per il GPGPU non si può certo paragonare alla ridondanza delle risorse di AMD. Nel primo caso è una scelta strategica di funzionamento del chip e del mercato in cui lo si vuole porre, nel secondo caso è solo una scelta di miglioramento delle rese. La fusione delle parti ridondanti in eccesso, buone o rotte che siano, porta questi ad avere impatto zero sui consumi. Le parti funzionali di nvidia no, per cui la diversità perf/watt si vede anche in queste cose.