Link alla notizia: http://www.hwupgrade.it/news/skvideo/nvidia-illustra-il-progetto-echelon_34469.html

Nel contesto di un programma sponsorizzato dal DARPA, NVIDIA illustra le caratteristiche di un chip che andrà ad equipaggiare sistemi HPC di classe exaflop

Click sul link per visualizzare la notizia.

Nvidia come sempre investe in nuove tecnologie e magari cosi facendo tralascia un po il settore gaming.

Ma credo si la strada giusta non basta migliorare i prodotti che già esistono,bisogna inventare quelli per il futuro.

Chissà che JC Denton s'incazza :asd:

Mi sa' tanto che 57 kilowatt andranno stretti ad nvidia :stordita: , ma d' altra parte questa è una di quelle proposte che "nun ze pò rifiutare" ... chissà i $ in gioco

cmq darpa exascale gpgpu 2018 echelon mit ... 'sti cazzi :eek: più che una news sembra una recensione su un film di fantascienza :D

Il progetto, attualmente conosciuto con il nome di Echelon...... lo avete detto a Sam Fisher? Grimsdottir lo sa già?? e Redding? cosa dice Redding?...iniziativa sponsorizzata dal DARPA - Defense Advanced Research Project AgencyA quando SkyNet?

"La nostra attenzione, in NVIDIA, è per tutti i prodotti sulle performance per watt"

mmmmmmmmmm...........demagogia? :)

Il progetto ECHELON
Evidentemente alla NSA sono a corto di potenza di calcolo. Lo chiameranno ECHELON 2, a trenta anni di distanza dalla costruzione del primo. Che bello, saremo tutti ancora più spiati. Curiosamente un po' di tempo fà è andato in onda sul digitale terrestre IRIS un film intitolato "In Ascolto" che è molto realistico....

"La nostra attenzione, in NVIDIA, è per tutti i prodotti sulle performance per watt"

mmmmmmmmmm...........demagogia?
Se guardi al mondo dei videogiochi allora le soluzioni nvidia non sono il max per quanto riguarda performance/watt. D'altronde i loro chip si portano dietro una serie di funzionalità per il GPGPU che per i videogiochi non sono usati ma che comunque consumano (e rendono il loro chip delle mattonelle).
Se guardi invece in campo GPGPU non c'è alcuna soluzione che faccia meglio.
Basta guardare le prestazioni della concorrenza nella applicazioni professionali. Le loro schede consumano di più e vanno meno anche se nell'eseguire i soli compiti grafici sono più efficienti.

Se guardi al mondo dei videogiochi allora le soluzioni nvidia non sono il max per quanto riguarda performance/watt. D'altronde i loro chip si portano dietro una serie di funzionalità per il GPGPU che per i videogiochi non sono usati ma che comunque consumano (e rendono il loro chip delle mattonelle).
Se guardi invece in campo GPGPU non c'è alcuna soluzione che faccia meglio.
Basta guardare le prestazioni della concorrenza nella applicazioni professionali. Le loro schede consumano di più e vanno meno anche se nell'eseguire i soli compiti grafici sono più efficienti.

non voglio scatenare flame, ma parli per sentito dire o per conoscenza diretta?
Secondo me parli per sentito dire.

CUDA è un ottimo toolkit che manca alla concorrenza, ma se uno si fa il programma in casa senza bisogno di toolkit (facendo però più fatica) i risultati che si hanno con le schede della concorrenza (leggasi ATi) molte volte sono equiparabili, spesso migliori, solo poche volte sono meno efficienti.

Ah, consumano anche molto meno.

non voglio scatenare flame, ma parli per sentito dire o per conoscenza diretta?
Nessun flame. Solo questioni di numeri. Vedi i benchmark eseguiti sui programmi professionali che non fanno solo texturing ma implicano l'uso delle capacitò di calcolo per fare qualcosa di più.
Qui trovi qualche test: http://tech.icrontic.com/articles/reviews/back-in-the-big-leagues-the-nvidia-quadro-6000-reviewed/
In conclusione dell'articolo:
The Quadro 6000 managed to score higher than the FirePro V8800 in all of the tests, and in roughly half of the tests on average, it managed to double the performance of the V8800. That is quite the impressive increase. Professionals who work with incredibly intensive projects should take note.

In alcuni test la concorrenza è indietro davvero di tantissimo.

Non è un caso che nvidia abbia il 90% del mercato professionale con le Quadro in un mercato più che maturo e che sa valutare quello che viene offerto.
Le capacità di calcolo delle sue architetture sono oggettivamente superiori. Se poi tu ti fai l'applicazione a casa per calcolarti una specifica cosa è probabile che trovi il modo di sfruttare meglio l'architettura AMD per quella particolare cosa. Ma per il calcolo scientifico, quello generale che implica l'uso di diverse strutture e metodi di calcolo, per ora la concorrenza non c'è.

In OpenCL, che dovrebbe essere il cavallo di battaglia di AMD contro CUDa questi sembrano essere i risultati. Ovviamente stiamo parlando solo di alcuni bench, ma questo è quello che uno si trova davanti quando deve valutare un prodotto:

http://blog.cudachess.org/2010/03/nvidia-gtx-480-first-opencl-benchmark/

http://www.anandtech.com/show/2977/nvidia-s-geforce-gtx-480-and-gtx-470-6-months-late-was-it-worth-the-wait-/6

E ti anticipo con questa nota:
The OpenCL GPGPU benchmark suite forms part of SiSoftware Sandra 2010. AMD believes it is the only company that can provide a complete OpenCL development platform for GPGPUs - essentially a combination of graphics chip and microprocessor.

Ovvero il test di SiSoft Sandra è già ottimizzato per le GPU ATI poichè ci hanno lavorato assieme.

Se guardi al mondo dei videogiochi allora le soluzioni nvidia non sono il max per quanto riguarda performance/watt. D'altronde i loro chip si portano dietro una serie di funzionalità per il GPGPU che per i videogiochi non sono usati ma che comunque consumano (e rendono il loro chip delle mattonelle).
Se guardi invece in campo GPGPU non c'è alcuna soluzione che faccia meglio.
Basta guardare le prestazioni della concorrenza nella applicazioni professionali. Le loro schede consumano di più e vanno meno anche se nell'eseguire i soli compiti grafici sono più efficienti.

che intendi per "applicazioni professionali"? Qui si parla di gpgpu e, in quell'ambito, a fare la differenza è la capacità di calcolo in DP
Qui (http://www.beyond3d.com/content/reviews/55/11) c'è una comparativa piuttosto esaustiva delle performance nei puri calcoli aritmetici, tra GTX470 e HD5870
Chi volesse leggere tutto l'articolo può andare qui (http://www.beyond3d.com/content/reviews/55/1)

Qui (http://www.realworldtech.com/page.cfm?ArticleID=RWT090909050230&p=2), invece, c'è una comparativa tra processori della precedente generazione, in relazione alle performance in DP per unità di superficie

che intendi per "applicazioni professionali"? Qui si parla di gpgpu e, in quell'ambito, a fare la differenza è la capacità di calcolo in DP
Qui (http://www.beyond3d.com/content/reviews/55/11) c'è una comparativa piuttosto esaustiva delle performance nei puri calcoli aritmetici, tra GTX470 e HD5870
Chi volesse leggere tutto l'articolo può andare qui (http://www.beyond3d.com/content/reviews/55/1)


Pero' in quel link si parla di schede consumer, sarebbe interessante vedere i numeri per le soluzioni HPC (Tesla ecc.). Ad es. per GF100 le performance in DP di un prodotto Tesla dovrebbero essere quadruple della 470 (il rapporto SP:DP e' 2:1 invece che 8:1).
Inoltre, quella e' la peak performance, mentre quello che importa e' la performance che il programma riesce davvero ad estrarre. Conosci delle recensioni al riguardo?

Nei grafici linkati manca l'architettura Fermi. Consideriamo che questa è 8 volte più veloce in DP del G200 per un'area più o meno uguale. Ricordo che le Tesla usano memoria ECC che usa più energia della memoria "normale" quindi il punto di efficienza diminuisce leggermente anche per questo.
I bench del secondo link sono interessanti, ma sono specifici per singola operazione. Nei calcoli veri non si esegue la stessa istruzione un milione di volte e basta saturando in maniera artificiale tutti gli SP alla loro massima efficienza. Entrano in gioco molte altre cose, come ad esempio la capacità di passare i risultati da un thread al successivo o di mixare istruzioni diverse.
Nei bench OpenCL, gli unici che permettono di avere un confronto diretto tra le due architetture, si vede che l'architettura Fermi funziona meglio in quasi tutti gli scenari.
Negli algoritmi dove non si fa solo moltiplicazioni di matrici in DP ad hoc per mostrare la massima efficienza dell'architettura, si vede dove le capacità dell'architettura nvidia vs quella AMD prevale.

Qui si parla di gpgpu e, in quell'ambito, a fare la differenza è la capacità di calcolo in DP
Nel campo professionale si usano le capacità di calcolo per fare cose che non sono sole ed esclusivamente quello di muovere poligoni sullo schermo come nei videogiochi.
Potresti spiegare altrimenti come è possibile che il Cypress che nel campo videoludico praticamente sta un solo passo dietro al GF100, nel campo professionale sta 5 o 10 passi indietro. E le specifiche delle schede Quadro non sono quelle GeForce. Nelle Quadro si usa il chip della 470 con frequenze inferiori. I bench dei consumi indicano addirittura che queste schede consumano meno delle schede AMD e vanno di più. Una cosa che a guardare i bench dei videogiochi nessuno crederebbe.

Pero' in quel link si parla di schede consumer, sarebbe interessante vedere i numeri per le soluzioni HPC (Tesla ecc.). Ad es. per GF100 le performance in DP di un prodotto Tesla dovrebbero essere quadruple della 470 (il rapporto SP:DP e' 2:1 invece che 8:1).
Inoltre, quella e' la peak performance, mentre quello che importa e' la performance che il programma riesce davvero ad estrarre. Conosci delle recensioni al riguardo?

ciao Davide, un chip derivato da gf100 destinato ad equipaggiare una scheda di tipo tesla, ha un numero di alu pari a 448 con frequenza di 1150 MHz e performance di picco pari a 515,2 Gflops in SP e 257,6 in DP per operazioni di tipo scalare. Questi valori calano ad 1/4 per operazioni su vettori mentre restano invariate le prestazioni con funzioni trascendentali rispetto ai chip di tipo consumer. Questo significa che arrivano a pareggiare i conti con la 5870 nelle operazioni scalari e nelle MUL e MAD vettoriali.
Quelli riportati in tabella sono i valori teorici mentre quelli nei grafici sono valori misurati sperimentalmente; infatti quantitativamente si discostano da quelli teorici e, in più di qualche occasione, anche l'andamento qualitativo non si allinea alla teoria. In alcuni casi la cosa è facilmente spiegabile; ad esempio le MAD sono eseguite dai chip nVidia con 2 passaggi anzichè con uno solo perchè non avviene la conversione da MAD in FMA (i chip ATi eseguono entrambi i tipi di calcoli alla stessa velocità mentre quelli nVidia hanno alu in grado di eseguire una FMA in un solo ciclo ma per una MAD hanno bisogno di due cicli).
In ogni caso, la mia risposta era destinata a chi affermava che i chip nVidia hanno un migliora rapporto prestazioni/watt in ambito pro, la qual cosa è palesemente falsa. Una tesla ha prestazioni comparabili, sia in teoria che in pratica, a quelle di una 5870 nell'esecuzione di calcoli matematici ma non ha consumi inferiori.

Nei grafici linkati manca l'architettura Fermi. Consideriamo che questa è 8 volte più veloce in DP del G200 per un'area più o meno uguale. Ricordo che le Tesla usano memoria ECC che usa più energia della memoria "normale" quindi il punto di efficienza diminuisce leggermente anche per questo.


infatti è specificato che si tratta di processori della precedente generazione (non compare neppure la serie 5xx0 di ATi); inoltre GT200 in DP non fa testo in quanto ha una capacità di calcolo veramente ridotta



I bench del secondo link sono interessanti, ma sono specifici per singola operazione. Nei calcoli veri non si esegue la stessa istruzione un milione di volte e basta saturando in maniera artificiale tutti gli SP alla loro massima efficienza. Entrano in gioco molte altre cose, come ad esempio la capacità di passare i risultati da un thread al successivo o di mixare istruzioni diverse.
Nei bench OpenCL, gli unici che permettono di avere un confronto diretto tra le due architetture, si vede che l'architettura Fermi funziona meglio in quasi tutti gli scenari.
Negli algoritmi dove non si fa solo moltiplicazioni di matrici in DP ad hoc per mostrare la massima efficienza dell'architettura, si vede dove le capacità dell'architettura nvidia vs quella AMD prevale.


nell'esecuzione di calcoli matematici, come quelli utilizzati in ambito GPGPU, i valori misurati sperimentalmente sono molto prossimi a quelli teorici, al contrario di quello che succede in ambito videoludico, proprio perchè non ci sono operazioni ad elevate latenze che possono far stallare la pipeline o rallentare l'elaborazione. I valori teorici di fermi e di cypress li conosciamo e quelle tabelle mostrano quelli sperimentali.



Nel campo professionale si usano le capacità di calcolo per fare cose che non sono sole ed esclusivamente quello di muovere poligoni sullo schermo come nei videogiochi.
Potresti spiegare altrimenti come è possibile che il Cypress che nel campo videoludico praticamente sta un solo passo dietro al GF100, nel campo professionale sta 5 o 10 passi indietro. E le specifiche delle schede Quadro non sono quelle GeForce. Nelle Quadro si usa il chip della 470 con frequenze inferiori. I bench dei consumi indicano addirittura che queste schede consumano meno delle schede AMD e vanno di più. Una cosa che a guardare i bench dei videogiochi nessuno crederebbe.

i test che hai linkato riguardano applicazioni di grafica pro e non GPGPU (li le tesla non c'entrano niente). Per questo ti ho chiesto a quali applicazioni pro fai riferimento. E, nel caso di grafica pro, si tratta sempre di muovere poligoni con annessi e connessi (comprese operazioni di texturing, ad esempio). Inoltre, anche in quei grafici si vedono test in cui le quadro sono avanti, in alcuni anche molto avanti, ma se ne vedono altri in cui sono indietro (a volte anche molto indietro). Inoltre non ho trovato scritto da nessuna parte che le quadro consumino meno delle firegl.
In quanto alle differenze di prestazioni, i grafici presenti nell'articolo che ho linkato possono dare molte risposte, anche per quanto riguarda il campo consumer. Se un SW fa molto uso, ad esempio, di istruzioni di tipo scalare in fp32 o di heavy tessellation (come alcuni bench sintetici) i chip nVidia sono sicuramente avvantaggiati.

Per quanto riguarda i consumi avevo visto un benchmark che mostrava consumi inferiori per schede nvidia con potenza simile a quelle ATI. Probabilmente non è il caso della serie QUadro 6000 che consuma una cinquantina di watt in più.
Però non so come tu faccia a dire che le capacità sono le stesse quando i benchmark su prodotti reali, non benchmark fatti ad hoc per mostrare una particolare ottimizzazione all'esecuzione di una sola istruzione (o tipo di istruzioni) è questa:
http://hothardware.com/Reviews/NVIDIA-Unleashes-Quadro-6000-and-5000-Series-Workstation-GPUs-Review/?page=8

Ed è solo un esempio, tra tutti quelli che sono riportati in quella recensione, che evidenzia in maniera chiara la differenza tra le due architetture e mette in mostra anche la differenza con l'architettura vecchia di nvidia (che spesso sorpassa comunque quella nuova di AMD).
Ora, o i numeri teorici che hai riportato sono appunto solo teorici e molto ma molto distanti poi dalla efficienza vera che si ottiene oppure in AMD hanno una architettura stratosferica (secondo i numeri che hai dato) ma che non sanno sfruttare per via di driver penosi.
Ripeto, non si capisce perchè in campo videoludico il Cypress sarebbe solo leggermente inferiore ad un Fermi, quando invece nel campo professionale, dove entrano in gioco altre caratteristiche, gli stessi piombino dietro addirittura al così tanto bistrattato G200.

Oh, mi scuso, ho scritto il commento precedete prima della tua risposta.

nell'esecuzione di calcoli matematici, come quelli utilizzati in ambito GPGPU, i valori misurati sperimentalmente sono molto prossimi a quelli teorici
Credo proprio di no. Basta vedere nei super computer di calcolo ibridi quale è il valore teorico di picco e quello realmente ottenuto dai test che danno il punteggio alle capacità di calcolo reali dell'intero sistema. Si arriva anche ad 1/4 della potenza di picco, indice che per calcoli di complessità elevata l'efficienza è nettamente minore di quella che si ottiene con semplici bench.
Se guardi invece il rapporto tra picco teorico e quello reale di architetture basate solo su "normali" CPU vedi che i numeri sono decisamente più grandi (migliore efficienza). E con il Cell questi numeri sono ancora migliori.
Misurare le capacità HPC con un test che calcola la stessa matrice ottimizzata per la cache del particolare processore e ottenere il 95% della capacità di calcolo dello stesso non ha senso quando, come detto, l'efficienza in campo reale è decisamente molto ma molto più bassa, e quindi è più importante riuscire ad aumentarla con sistemi diversi che semplicemente attraverso la presenza di migliaia di ALU che fanno DP in un solo ciclo di clock che vengono saturate solo in condizioni ideali.
Certo aiuta, ma non sembra essere la condizione dominante per avere un sistema che performa meglio di un altro.

Per quanto riguarda i consumi avevo visto un benchmark che mostrava consumi inferiori per schede nvidia con potenza simile a quelle ATI. Probabilmente non è il caso della serie QUadro 6000 che consuma una cinquantina di watt in più.
Però non so come tu faccia a dire che le capacità sono le stesse quando i benchmark su prodotti reali, non benchmark fatti ad hoc per mostrare una particolare ottimizzazione all'esecuzione di una sola istruzione (o tipo di istruzioni) è questa:
http://hothardware.com/Reviews/NVIDIA-Unleashes-Quadro-6000-and-5000-Series-Workstation-GPUs-Review/?page=8

Ed è solo un esempio, tra tutti quelli che sono riportati in quella recensione, che evidenzia in maniera chiara la differenza tra le due architetture e mette in mostra anche la differenza con l'architettura vecchia di nvidia (che spesso sorpassa comunque quella nuova di AMD).
Ora, o i numeri teorici che hai riportato sono appunto solo teorici e molto ma molto distanti poi dalla efficienza vera che si ottiene oppure in AMD hanno una architettura stratosferica (secondo i numeri che hai dato) ma che non sanno sfruttare per via di driver penosi.
Ripeto, non si capisce perchè in campo videoludico il Cypress sarebbe solo leggermente inferiore ad un Fermi, quando invece nel campo professionale, dove entrano in gioco altre caratteristiche, gli stessi piombino dietro addirittura al così tanto bistrattato G200.

quelli che tu definisci esempi "reali" sono solo esempi di SW programmati in modo da favorire, volontariamente o meno, una determinata modalità di esecuzione. Se utilizzi SW che fanno largo uso di istruzioni di tipo vettoriale scopri che i chip ATi diventano molto più veloci della controparte nVidia.
Quelli che tu chiami dati "teorici" sono dati sperimentali sulla capacità di calcolo reale con SW non ottimizzato né per esecuzione seriale né parallela. Infatti mettono in evidenza come i chip nVidia si avvantaggino nel primo caso e quelli ATi nel secondo. Quindi, sono molto più utili a capire le reali capacità di calcolo di una determinata architettura e anche i suoi punti deboli, perchè sono trasparenti alle ottimizzazioni.

Oh, mi scuso, ho scritto il commento precedete prima della tua risposta.


Credo proprio di no. Basta vedere nei super computer di calcolo ibridi quale è il valore teorico di picco e quello realmente ottenuto dai test che danno il punteggio alle capacità di calcolo reali dell'intero sistema. Si arriva anche ad 1/4 della potenza di picco, indice che per calcoli di complessità elevata l'efficienza è nettamente minore di quella che si ottiene con semplici bench.
Se guardi invece il rapporto tra picco teorico e quello reale di architetture basate solo su "normali" CPU vedi che i numeri sono decisamente più grandi (migliore efficienza). E con il Cell questi numeri sono ancora migliori.
Misurare le capacità HPC con un test che calcola la stessa matrice ottimizzata per la cache del particolare processore e ottenere il 95% della capacità di calcolo dello stesso non ha senso quando, come detto, l'efficienza in campo reale è decisamente molto ma molto più bassa, e quindi è più importante riuscire ad aumentarla con sistemi diversi che semplicemente attraverso la presenza di migliaia di ALU che fanno DP in un solo ciclo di clock che vengono saturate solo in condizioni ideali.
Certo aiuta, ma non sembra essere la condizione dominante per avere un sistema che performa meglio di un altro.

Cosa c'entrano i supercomputer? Lo sai che in un elaboratore del genere il collo di bottiglia è, nella stragrande maggioranza dei casi, il bus di connessione tra i vari processori? Qualunque sistema di tipo multiprocessore ha, spesso, nel bus il collo di bottiglia. Persino nel cell, con soli 8 processori, a seconda di come programmi il trasferimento dati da un SPE all'altro, puoi avvicinarti alla potenza di picco teorica o ridurre la capacità di calcolo del chip ad 1/3 di quest'ultima. Ben diverso è quello che avviene all'interno di una gpu. Nel supercomputer cinese di cui ha parlato anche HWU (http://www.businessmagazine.it/news/il-nuovo-top-supercomputer-mondiale-e-cinese_34408.html), gran parte dell'incremento della potenza di calcolo è dovuto all'utilizzo di un nuovo tipo di bus che raddoppia la banda a disposizione rispetto a quello utilizzato dal vecchio Tianhe.
Inoltre continui a fare confusione, parlando di GPGPU e tesla e postando test che riguardano le quadro. Sono due ambiti del tutto differenti

Cosa c'entrano i supercomputer?
Scusa riassumiamo un attimo.

I bench delle Quadro non vanno bene perchè mostrano che una Quadro Basata su Fermi va il doppio di una basata su Cypress, e non si sa il perchè dato che in ambito videoludico i due chip sono quasi alla pari.

In ambito con i super computer (che sono usati per fare calcoli matematici) i bench non vanno bene perchè i limiti sono della banda.

Siamo sempre ai soliti discorsi di teoria vs pratica. Io vedo dei numeri che dall'altra parte non ci sono. Sarà perché l'architettura AMD non è all'altezza di quella nvidia nell'atto pratico (non teorico dove sfoggia numeri più grandi) o perchè AMD non è in grado di fare driver all'altezza di sfruttare i propri transistor tanto sudatamente progettati. O una combinazione delle due.
Fatto sta che nella pratica, cioè per quello che riguarda l'uso di programmi usati in ambito professionale/HPC non c'è alcun riferimento oggettivo che tutta questa potenza sia espressa. Anzi, mi sembra che proprio non ci sia.

Dimmi in poche parole perché le Quadro fanno quei numeri e perché nei bench OpenCL nvidia surclassa in quasi tutti i bench le schede ATI anche se dai grafici che hai postato tu le schede ATI dovrebbero essere sensibilmente più veloci in linea teorica. Dove sta il problema? Sempre e solo nei driver?

Someone, il fatto di non poter usare un cluster per valutare le performance di una singola componente è palese

daltronde non si possono neanche confrontare direttamente le due architetture per "via numerica" (n° shader ecc ecc) in quanto le architteture sono troppo diverse.

rimane solo la possibilità di testare mediante bench una singola gpu ma anche qui bisogna stare attenti in quanto le architetture fondamentalmente diverse permettono facilmente di taroccare il risultato in base a come viene svolto il benchmark


e comunque a cappello di tutto visto il tuo storico messaggi diciamo non super partes chiederei gentilmente di dimostrare ogni tua tesi in maniera oggettiva e documentata

Scusa riassumiamo un attimo.


ok, riassumiamo :D

Scusa riassumiamo un attimo.

I bench delle Quadro non vanno bene perchè mostrano che una Quadro Basata su Fermi va il doppio di una basata su Cypress, e non si sa il perchè dato che in ambito videoludico i due chip sono quasi alla pari.

si parla di GPGPU e tesla e tu tiri fuori bench delle quadro che con alcune applicazioni vanno meglio e con altre peggio della controparte ATi e concludi che vanno il doppio e consumano di meno. Vengono postati bench in cui si analizza la capacità matematica dei chip singoli e li bolli come dati teorici, cominciando a sproloquiare di HPC (e riproponendo i test delle quadro che non c'entrano una mazza con i supercomputer).


In ambito con i super computer (che sono usati per fare calcoli matematici) i bench non vanno bene perchè i limiti sono della banda.


quali bench? Quelli che dicono che il tianhe-1A è molto più veloce del tianhe? A parte il fatto che il primo ha molti più core del secondo, il primo ha anche una banda doppia rispetto al secondo per mettere in comunicazione questi processori. Se per te questo non significa niente è un problema tuo e non mio.


Siamo sempre ai soliti discorsi di teoria vs pratica.
la pratica non significa niente senza teoria.


Io vedo dei numeri che dall'altra parte non ci sono.

dall'altra parte ci sono ma tu fai finta di ignorarli o li bolli come "teoria". Quelli sono test pratici e reali quanto e più di un vantage o di qualunque altro test perchè permettono di far luce sull'architettura di un chip cosa che con il punteggio finale del 3dmark o con gli fps di crysis non vedi.


Sarà perché l'architettura AMD non è all'altezza di quella nvidia nell'atto pratico (non teorico dove sfoggia numeri più grandi) o perchè AMD non è in grado di fare driver all'altezza di sfruttare i propri transistor tanto sudatamente progettati. O una combinazione delle due.
Fatto sta che nella pratica, cioè per quello che riguarda l'uso di programmi usati in ambito professionale/HPC non c'è alcun riferimento oggettivo che tutta questa potenza sia espressa. Anzi, mi sembra che proprio non ci sia.


hai parlato di architettura inferiore; adesso tiri in ballo i driver; mancano solo le ottimizzazioni del SW da parte di terzi e il quadro è completo. :sofico:
Ti consiglio un'approfondita lettura dell'articolo di B3D, comprese le conclusioni. Forse ti servirà per chiarirti di più le idee.


Dimmi in poche parole perché le Quadro fanno quei numeri e perché nei bench OpenCL nvidia surclassa in quasi tutti i bench le schede ATI anche se dai grafici che hai postato tu le schede ATI dovrebbero essere sensibilmente più veloci in linea teorica. Dove sta il problema? Sempre e solo nei driver?

dimmelo tu che hai parlato di architettura inferiore in certi ambiti che compete alla pari in altri. Anzi, a dirla tutta, avevi anche affermato, senza lo straccio di una prova, che le quadro (cosa c'entrino con le tesla lo sai solo tu) consumano anche meno della controparte. Questo a prescindere dal fatto che dai test che ho postato io non risulta che i chip ATi sono sensibilmente più veloci ma che sono più veloci in certi ambiti e meno in altri e risulta anche che da quei test si può capire in che modo scrivere codice che avvantaggi l'una o l'altra architettura.

Comunque, per tornare alla parte tecnica dell'articolo :) e' interessante valutare quei numeri: prendendo per buono il valore citato di 200 pJ/istruzione, significa 5 miliardi di istruzioni per Joule, cioe' 5 teraFLOPS per Watt, mentre dai dati citati da Yossarian dovremmo essere intorno a mezzo teraFLOPS per... boh, diciamo 300 watt (regime, non picco) per un GF100 :)

Quindi 3mila volte meno di quanto citato. Il che significa che purtroppo l'energia spesa per effettivamente fare le operazioni numeriche (cioe' quello che ci interessa) e' una frazione trascurabile dell'energia consumata dal chip. Questo non sorprende, il grosso dell'energia e' spesa nel trasferire i dati da e verso la memoria (specie off-chip). Se potessimo davvero spendere energia solo per fare la comptazione, un solo GF100 sarebbe potente circa quanto tutto il nuovo Tianhe :D

In quest'ottica va letta la seconda parte dell'articolo, quando Dally parla di cache multilivello programmabili e tenere i dati il piu' vicino possibile alle unita' funzionali.

Comunque, per tornare alla parte tecnica dell'articolo :) e' interessante valutare quei numeri: prendendo per buono il valore citato di 200 pJ/istruzione, significa 5 miliardi di istruzioni per Joule, cioe' 5 teraFLOPS per Watt, mentre dai dati citati da Yossarian dovremmo essere intorno a mezzo teraFLOPS per... boh, diciamo 300 watt (regime, non picco) per un GF100 :)

Quindi 3mila volte meno di quanto citato. Il che significa che purtroppo l'energia spesa per effettivamente fare le operazioni numeriche (cioe' quello che ci interessa) e' una frazione trascurabile dell'energia consumata dal chip. Questo non sorprende, il grosso dell'energia e' spesa nel trasferire i dati da e verso la memoria (specie off-chip). Se potessimo davvero spendere energia solo per fare la comptazione, un solo GF100 sarebbe potente circa quanto tutto il nuovo Tianhe :D

In quest'ottica va letta la seconda parte dell'articolo, quando Dally parla di cache multilivello programmabili e tenere i dati il piu' vicino possibile alle unita' funzionali.

quello che dici è terribilmente vero. Ormai, all'interno di un chip, la quasi totalità dello spazio è occupato soprattutto da registri, cache e circuiti di controllo e gestione dei thread e del flusso dei dati tra unità funzionali e da e verso la memoria. Il che significa che anche la stragrande maggioranza dei cicli di clock è speso per operazioni di controllo e di load/store. Ovviamente anche il bilancio energetico è influenzato da questi fattori. Le operazioni fatte con la memoria esterna sono anche quelle più "dispendiose" e da qui la necessità di riuscire ad avere tutto a "portata delle unità funzionali" che ormai rivestono un ruolo marginale nel bilancio energetico di un chip.. :p

Ho scritto una cazzata :D
5 miliardi di istruzioni per Joule sono 5 gigaFLOPS, non teraFLOPS, quindi 1.5 teraFLOPS per 300 Watt, quindi un rapporto di 3, non 3mila :)

Cmq il problema di fondo e' quello: l'energia per i bus (specie off-chip), il clock, il controllo, la decodifica delle sitruzioni eccetera e' ben maggiore dell'energia usata per fare i calcoli in se'. Questo e' un bel problema... e di non facile soluzione :)

Ho scritto una cazzata :D
5 miliardi di istruzioni per Joule sono 5 gigaFLOPS, non teraFLOPS, quindi 1.5 teraFLOPS per 300 Watt, quindi un rapporto di 3, non 3mila :)

Cmq il problema di fondo e' quello: l'energia per i bus (specie off-chip), il clock, il controllo, la decodifica delle sitruzioni eccetera e' ben maggiore dell'energia usata per fare i calcoli in se'. Questo e' un bel problema... e di non facile soluzione :)

succede e io non ho controllato perchè mi sono fidato :D
in questi anni sono stati fatti diversi passi avanti: trasferimento di dati in batch dalla ram di sistema alla ram video e da questa all'interno dei registri, per ridurre l'impatto degli accessi a memorie esterne, soprattutto a quella di sistema che passa attraverso il collo di bottiglia del bus pci express); aumento esponenziale del numero di registri per avere più thread on fly (questo porta due vantaggi: riduzione degli accessi all'esterno e, soprattutto, miglior mascheramento delle latenze); introduzione di cache all'interno delle gpu (inizialmente solo per le texture che erano le più problematiche da gestire per le latenze, poi anche per i dati di altra natura); aumento dei bus verso l'esterno e, soprattutto, verso l'interno dei chip, con architetture di tipo asimmetrico sempre più complesse. I memory controller sono diventati, in molti ambiti, i veri arbitri delle prestazioni di un chip.
I chip hanno aumentato notevolmente la loro efficienza passando agli shader unificati ma questo aumento è dovuto ad una diversa gestione del lavoro delle alu e non ad un aumento dell'efficienza della singola alu. Il rovescio della medaglia è stato l'aumento della complessità dei circuiti che si occupano di gestire e controllare il lavoro delle unità funzionali.
Quella di tentare di ridurre al minimo la necessità di accedere alla memoria esterna è una delle scommesse del futuro ma tu sai bene che anche la gestione di una gran mole di traffico all'interno del chip presenterebbe non poche criticità.
Adesso si sta perseguendo la strada di strutturare le architetture interne su più livelli; così hai 2, 3, 4 macro blocchi di alu, ciascuno diviso, a sua volta, in gruppi più piccoli e via dicendo, fino ad arrivare alla singola alu. Ma anche questo tipo di architettura comporta problemi. Una logica a più livelli significa che tutti i circuiti che gestiscono i vari livelli devono dialogare tra di loro (il che si traduce in più cicli impiegati in operazioni che non coinvolgono le unità funzionali).

Gia', ma alla fine ci tocchera' probabilmente rivedere tutta l'interazione hardware/software per raggiungere quei livelli di prestazioni (exascale e oltre). Ad esempio, ci sono tentativi di cambiare il paradigma di programmazione (sempre per applicazioni numeriche, ovviamente) in cui si programma direttamente la gerarchia di memoria: non e' tanto piu' una questione di dispacciare istruzioni alle unita' funzionali, ma una questione di portare i dati il piu' vicino possibile alle unita' funzionali e tenerli li', per ridurre i trasferimenti di memoria. Un esempio:
http://sequoia.stanford.edu/

e se guardi la documentazione, il backend e' in... CUDA! Surprise :D
Cos'e' che si diceva nell'articolo? :D

e comunque a cappello di tutto visto il tuo storico messaggi diciamo non super partes chiederei gentilmente di dimostrare ogni tua tesi in maniera oggettiva e documentata
Ho postato dei link.
In OpenCL l'architettura nvidia mostra una efficienza migliore.

Poi mi fa strano che tu chieda a me di dare dimostrazione di tesi quando dall'altra parte non ci sono link e si continua a distorcere il discorso su consumi e teorie varie per non rispondere alla semplice domanda posta: i problemi OpenCL di AMD sono di driver o di architetttura HW?
E ripeto, come è possibile che due architetture apparentemente simili nel campo consumer poi mostrino tante differenze quando si tratta di usare programmi professionali? Come si vede questi programmi usano qualcosa di diverso rispetto ai videogiochi, dato che è ben visibile la differenza tra una Quadro e una GeForce con lo stesso chip. I driver sbloccano queste funzionalità sulle schede Quadro/FireStream, ma perchè da una parte queste funzioni vanno il doppio? Perché il Cypress spesso non raggiunge nemmeno le prestazioni del G200?

Perchè? Pronto, dall'altra parte, invece di confondere il discorso con argomenti senza senso, rispondere a queste domande. Magari anche solo alla prima relativamente all'OpenCL.
Grazie.

Gia', ma alla fine ci tocchera' probabilmente rivedere tutta l'interazione hardware/software per raggiungere quei livelli di prestazioni (exascale e oltre). Ad esempio, ci sono tentativi di cambiare il paradigma di programmazione (sempre per applicazioni numeriche, ovviamente) in cui si programma direttamente la gerarchia di memoria: non e' tanto piu' una questione di dispacciare istruzioni alle unita' funzionali, ma una questione di portare i dati il piu' vicino possibile alle unita' funzionali e tenerli li', per ridurre i trasferimenti di memoria. Un esempio:
http://sequoia.stanford.edu/

e se guardi la documentazione, il backend e' in... CUDA! Surprise :D
Cos'e' che si diceva nell'articolo? :D

faccio l'avvocato del diavolo (mi riferisco al modello per gpu, ovviamente :D ). Nella documentazione c'è scritto che con la versione 3.0 di CUDA si fa uso di 4 livelli di memoria (due di tipo dram, ovvero ram di sistema e vram) e 2 di tipo sram (le cache L2 e L1). I primi due non sono direttamente accessibili alle unità interne della gpu e questa è già una prima limitazione al modello sequoia (L1 ed L2 sono, tra l'altro, di dimensioni piuttosto ridotte). In ogni caso, anche qualora fossero direttamente accessibili, le latenze sarebbero piuttosto elevate. Nella gpu ATi, da R5x0 in poi, è stata aggiunta la funzionalità memexport e dalla serie 4xx0 in poi anche la memimport che consentono alla gpu di accedere direttamente ad una porzione della ram di sistema. Tra i suggerimenti dati per ottimizzare i chip ATi c'è quello di far ricorso a queste funzionalità solo in casi particolari.
Anche il fatto che non ci possa agire direttamente sui registri è un'altra limitazione. Le unità funzionali delle gpu lavorano quasi esclusivamente con i registri.
Facendo un passo indietro ed ammettendo che siano accessibili direttamente anche L1 ed L2, a quali unità interne le si potrebbe abbinare? L2, magari, alle RBE o utilizzata in un sistema dual gpu sulla stessa vga ma per L1 l'unico uso che mi viene in mente è quello nell'ambito di un sistema multichip, magari anche di tipo asimmetrico, con cpu e gpu.
In sintesi, al momento, non mi sembra l'ideale per gestire il lavoro di processori che fanno del parallelismo e del multithreading i loro punti di forza.
Altra cosa, non mi pare (ma forse mi è sfuggito) di aver letto nulla riguardo alla gestione delle texture cache. Questo significa che Sequoia è progettato solo per il gpgpu? In caso contrario, ritengo che il modello di programmazione per gpu debba esporre anche le texture cache.
Infine, ho letto che, la comunicazione tra livelli è limitata alla copia dei dati dalla cache di un livello a quella di un altro livello col meccanismo dei DMA. In tal caso, però, rischi di scontrarti con gli stessi limiti dei sistemi attuali. Un DMA è gestito dal memory controler in maniera trasparente al programmatore e quindi bus e MC potrebbero diventare, di nuovo, il collo di bottiglia.

Queste sono considerazioni fatte dopo una lettura al volo del documento di presentazione di Sequoia (di cui avevo solo sentito parlare) e, ovviamente, qualcosa può essermi sfuggita.
In quanto all'utilizzo di CUDA per il backend, la cosa non deve sorprendere, visto che, al momento, per le gpu, l'unico modello proposto si basa su CUDA ed è stato progettato basandosi su gt200 prima e gf100 poi. :D

Ho postato dei link.
In OpenCL l'architettura nvidia mostra una efficienza migliore.

Poi mi fa strano che tu chieda a me di dare dimostrazione di tesi quando dall'altra parte non ci sono link e si continua a distorcere il discorso su consumi e teorie varie per non rispondere alla semplice domanda posta: i problemi OpenCL di AMD sono di driver o di architetttura HW?
E ripeto, come è possibile che due architetture apparentemente simili nel campo consumer poi mostrino tante differenze quando si tratta di usare programmi professionali? Come si vede questi programmi usano qualcosa di diverso rispetto ai videogiochi, dato che è ben visibile la differenza tra una Quadro e una GeForce con lo stesso chip. I driver sbloccano queste funzionalità sulle schede Quadro/FireStream, ma perchè da una parte queste funzioni vanno il doppio? Perché il Cypress spesso non raggiunge nemmeno le prestazioni del G200?

Perchè? Pronto, dall'altra parte, invece di confondere il discorso con argomenti senza senso, rispondere a queste domande. Magari anche solo alla prima relativamente all'OpenCL.
Grazie.

non viene sbloccato un bel niente perchè non ci sono funzionalità "nascoste" da sbloccare; si tratta solo di ottimizzazioni e se tu non continuassi ad ignorare i link che ho postato, magari arriveresti anche a capirne qualcosa di più. Forse (e il forse è d'obbligo perchè le quadro/firegl non c'entrano una mazza con il gpgpu, cosa che, evidentemente, non ti entra in testa). In quanto ai consumi, forse dimentichi che sei stato tu a tirarli in ballo a sproposito :rolleyes:
Tra l'altro, sei talmente preso dal tentativo ridicolo di dimostrare l'esistenza di "armi segrete" che non ti sei neppure reso conto di quanto, in questi test (http://hothardware.com/Reviews/NVIDIA-Unleashes-Quadro-6000-and-5000-Series-Workstation-GPUs-Review/?page=5), la 480 GTX faccia, insolitamente, schifo anche rispetto alla 5870 da cui le prende sonoramente ovunque. Considerato che si parla sempre e solo di "muovere poligoni" e che il chip è lo stesso IDENTICO delle quadro, trai tu le tue conclusioni. Per la cronaca, in nessuno di quei bench si fa uso di fp64 e queste
Cinebench OpenGL testing reveals similar performance between the Quadro 6000 and 5000 videocards. Looking at the rest of the scores, its apparent that ATI has optimized their drivers for this particular benchmark, while NVIDIA has yet to do so. As new drivers are released, we expect to see Cinebench scores of the Quardo cards increase.
che tu hai preso per verità assoluta, sono solo pippe mentali del recensore

faccio l'avvocato del diavolo (mi riferisco al modello per gpu, ovviamente :D ). Nella documentazione c'è scritto che con la versione 3.0 di CUDA si fa uso di 4 livelli di memoria (due di tipo dram, ovvero ram di sistema e vram) e 2 di tipo sram (le cache L2 e L1). I primi due non sono direttamente accessibili alle unità interne della gpu e questa è già una prima limitazione al modello sequoia (L1 ed L2 sono, tra l'altro, di dimensioni piuttosto ridotte). In ogni caso, anche qualora fossero direttamente accessibili, le latenze sarebbero piuttosto elevate. Nella gpu ATi, da R5x0 in poi, è stata aggiunta la funzionalità memexport e dalla serie 4xx0 in poi anche la memimport che consentono alla gpu di accedere direttamente ad una porzione della ram di sistema. Tra i suggerimenti dati per ottimizzare i chip ATi c'è quello di far ricorso a queste funzionalità solo in casi particolari.

Beh il modello e' uan gerarchia ad albero di memorie ed eventuali unita' funzionali che operano su di esse (una per memoria), quindi semplicemente RAM e VRAM non hanno unita' funzionali... per ora :D e' facile pensare ad un modello "Fusion" in cui la CPU e' l'unita' funzionale della RAM e la GPU quella dei livelli sotto la VRAM (dico "sotto" perche' come fai notare operare direttamente sulla VRAM non e' uan buona idea, la latenza e' troppo alta).


Anche il fatto che non ci possa agire direttamente sui registri è un'altra limitazione. Le unità funzionali delle gpu lavorano quasi esclusivamente con i registri.

Questa puo' essere vista come: 1. uan limitazione temporanea, limitata da CUDA, o 2. una cosa desiderabile: uan volta che hai spostato un certo task sul livello piu' basso (i registri) e' meglio che sia l'hardware a gestirli direttamente, senza micro-management da parte del software, perche' a quel punto l'hardware puo' andare alla massima velocita'.



Altra cosa, non mi pare (ma forse mi è sfuggito) di aver letto nulla riguardo alla gestione delle texture cache. Questo significa che Sequoia è progettato solo per il gpgpu? In caso contrario, ritengo che il modello di programmazione per gpu debba esporre anche le texture cache.

Nei primi capitoli, dove parla del modello, dice che e' un modello astratto che viene poi compilato per macchine specifiche, SMP / CMP / GPGPU ecc.


Infine, ho letto che, la comunicazione tra livelli è limitata alla copia dei dati dalla cache di un livello a quella di un altro livello col meccanismo dei DMA. In tal caso, però, rischi di scontrarti con gli stessi limiti dei sistemi attuali. Un DMA è gestito dal memory controler in maniera trasparente al programmatore e quindi bus e MC potrebbero diventare, di nuovo, il collo di bottiglia.

Credo per con DMA intenda piu' che altro "bulk transfer": il programma specifica cosa va e dove, e il DMA fa si' che i dati vengano trasferiti in un colpo solo tra i diversi livelli (supporta anche gather/scatter, lo dice da qualche parte). Cmq si' alla fine il bus e' il collo di bottiglia... ma quello e' desiderabile: vuoi che la computazione vada alla massima velocita' resa possibile dalla memoria, cioe' che la memoria sia l'unico collo di bottiglia.

Tra l'altro, sei talmente preso dal tentativo ridicolo di dimostrare l'esistenza di "armi segrete" che non ti sei neppure reso conto di quanto, in questi test, la 480 GTX faccia, insolitamente, schifo anche rispetto alla 5870 da cui le prende sonoramente ovunque.
Testimonianza che non leggi quello che scrivo ma vai per conto tuo. Prova a cercare:
dato che è ben visibile la differenza tra una Quadro e una GeForce con lo stesso chip

Ancora non hai risposto alle domande comunque. Sei su dei binari morti e non sei in grado di uscirne.
Se vuoi te la ripeto un'altra volta, con parole diverse, non si sa mai che tu non l'abbia capita: perchè in OpenCL, sistema dove AMD sta impiegando tutte le proprie forze mentre nvidia è ben più interessata a lanciare CUDA, le schede nvidia vanno di più in praticamente tutti i bench che vengono mostrati? Compresi quelli preparati da AMD insieme a SiSoft?

Beh il modello e' uan gerarchia ad albero di memorie ed eventuali unita' funzionali che operano su di esse (una per memoria), quindi semplicemente RAM e VRAM non hanno unita' funzionali... per ora :D e' facile pensare ad un modello "Fusion" in cui la CPU e' l'unita' funzionale della RAM e la GPU quella dei livelli sotto la VRAM (dico "sotto" perche' come fai notare operare direttamente sulla VRAM non e' uan buona idea, la latenza e' troppo alta).



infatti, nel precedente intervento ho scritto che l'unico impiego che mi viene in mente per L1 è quello di un sistema multichip asimmetrico (cpu con una o più gpu a fare da coprocessori). E, anche in quel caso, l'accesso diretto da parte della cpu lo limiterei ad operazioni quale trasferimento di dati verso la gpu o le cache interne alla cpu e, solo in casi eccezionali all'accesso diretto ad L1. In tal caso, L1 sarebbe una ram condivisa tra cpu e gpu e non riesco a vedere l'utilità di una VRAM.




Questa puo' essere vista come: 1. uan limitazione temporanea, limitata da CUDA, o 2. una cosa desiderabile: uan volta che hai spostato un certo task sul livello piu' basso (i registri) e' meglio che sia l'hardware a gestirli direttamente, senza micro-management da parte del software, perche' a quel punto l'hardware puo' andare alla massima velocita'.


vero; lo spostamento iniziale (il riempimento dei registri costanti) avviene prima del lancio dell'applicazione e, in seguito, i successivi trasferimenti sono gestiti sia dal thread processor, man mano che si riempiono di nuovo i suoi instruction buffer, che dai MC in modalità OoO e in real time e, quindi, sicuramente in maniera più efficiente di quanto non si potrebbe fare at compile time. A quel punto, solo lo scheduler di ogni singolo stream processor (chiamo SP un intero cluster di alu, per ntenderci :D ) lavorerebbe in order ma sempre in real time. Forse, a questo punto, sarebbe da valutare se non sia conveniente far lavorare in modalità OoO anche gli scheduler dei singoli SP (ma questo non ha a che fare con Sequoia :D ). In ogni caso, a questo punto, non vedo grandi rivoluzioni rispetto al modello attuale, almeno con questo tipo di architetture per le gpu.......



Nei primi capitoli, dove parla del modello, dice che e' un modello astratto che viene poi compilato per macchine specifiche, SMP / CMP / GPGPU ecc.



si, però mi riferivo alla gerarchia di cache del modello gpgpu, dove fa riferimento a 4 livelli, citando esplicitamente ram di sistema, vram, L1 ed L2, in riferimento all'architettura di GF100. Ora, L2 è la cache condivisa tra tutti gli SP ed L1 è una porzione della memoria condivisa tra le alu di ogni singolo SP. Ma ogni SP ha anche accesso ad una texture cache. Quindi l'idea che mi sono fatto è che il modello di programmazione sia limitato al gpgpu e non alla programmazione di una gpu per altri usi (gaming o grafica pro). In tal caso non c'è alcun motivo per fare uso di texture cache, visto che non si usano le TMU. Anche se la cosa che non mi torna è che, mentre nel modello sequoia si parla di 16 KB di L1 per SP, secondo il modello di allocazione della memoria previsto per GF100, in caso di operazioni di rendering la memoria a disposizione del singolo SP viene divisa in modo da avere 16 KB di L1 e 48 KB di memoria condivisa tra le alu dello SP mentre per il GPGPU avviene il contrario (48 KB di L1 e 16 KB di shared memory).



Credo per con DMA intenda piu' che altro "bulk transfer": il programma specifica cosa va e dove, e il DMA fa si' che i dati vengano trasferiti in un colpo solo tra i diversi livelli (supporta anche gather/scatter, lo dice da qualche parte). Cmq si' alla fine il bus e' il collo di bottiglia... ma quello e' desiderabile: vuoi che la computazione vada alla massima velocita' resa possibile dalla memoria, cioe' che la memoria sia l'unico collo di bottiglia.

la gerarchia di memorie di gf100 (ad esempio) al momento, prevede una L1 a disposizione del singolo SP e una L2 condivisa tra i 16 SP che sostituisce la texture cache L2, la cache a disposizione delle ROP's e la cache di tipo FIFO delle precedenti architetture. Se si deve operare un trasferimento da L1 a L2 o viceversa, o tra la L1 di uno SP e quella di un altro SP, si deve passare attraverso L2 (che immagino sarà servita da un ring bus) il cui accesso non può che essere gestito da un local arbiter o da uno dei MC presenti nelle ROP's (sul modello di quanto avviene, ad esempio, con l'EIB nel cell). Altrimenti non vedo come si possa risolvere il problema della concorrenza nell'accesso alle risorse condivise da parte dei diversi SP, soprattutto alla luce del fatto che la gestione dei thread avviene, a livello di registri, dinamicamente e in maniera trasparente al programmatore. Uno dei problemi che determinano le latenze nell'accesso a risorse condivise (compresa la memoria) è proprio nello smaltimento delle code relative alle richieste di accesso. Quindi gli arbiter (e il loro principio di funzionamento) e i criteri di arbitrato impostati diventano un elemento di elevata criticità e la loro ottimizzazione è decisiva ai fini delle prestazioni. Poi, ovviamente, ci sono altri fattori, come l'ampiezza del bus e la velocità di ricerca (in lettura) e trasferimento dei dati. Di fatto, la velocità delle memorie, intesa in senso lato, è influenzata anche da tutti questi elementi. L'unico trasferimento gestito, teoricamente, in un solo ciclo, è quello dai registri alla alu e viceversa, ma solo perchè ogni alu ha i suoi registri dedicati e non si pone il problema di gestire richieste concorrenti.

Se guardi al mondo dei videogiochi allora le soluzioni nvidia non sono il max per quanto riguarda performance/watt. D'altronde i loro chip si portano dietro una serie di funzionalità per il GPGPU che per i videogiochi non sono usati ma che comunque consumano (e rendono il loro chip delle mattonelle).
Se guardi invece in campo GPGPU non c'è alcuna soluzione che faccia meglio.
Basta guardare le prestazioni della concorrenza nella applicazioni professionali. Le loro schede consumano di più e vanno meno anche se nell'eseguire i soli compiti grafici sono più efficienti.

Per quanto riguarda i consumi avevo visto un benchmark che mostrava consumi inferiori per schede nvidia con potenza simile a quelle ATI. Probabilmente non è il caso della serie QUadro 6000 che consuma una cinquantina di watt in più.
Però non so come tu faccia a dire che le capacità sono le stesse quando i benchmark su prodotti reali, non benchmark fatti ad hoc per mostrare una particolare ottimizzazione all'esecuzione di una sola istruzione (o tipo di istruzioni) è questa:
http://hothardware.com/Reviews/NVIDIA-Unleashes-Quadro-6000-and-5000-Series-Workstation-GPUs-Review/?page=8

Ed è solo un esempio, tra tutti quelli che sono riportati in quella recensione, che evidenzia in maniera chiara la differenza tra le due architetture e mette in mostra anche la differenza con l'architettura vecchia di nvidia (che spesso sorpassa comunque quella nuova di AMD).
Ora, o i numeri teorici che hai riportato sono appunto solo teorici e molto ma molto distanti poi dalla efficienza vera che si ottiene oppure in AMD hanno una architettura stratosferica (secondo i numeri che hai dato) ma che non sanno sfruttare per via di driver penosi.
Ripeto, non si capisce perchè in campo videoludico il Cypress sarebbe solo leggermente inferiore ad un Fermi, quando invece nel campo professionale, dove entrano in gioco altre caratteristiche, gli stessi piombino dietro addirittura al così tanto bistrattato G200.

da uno dei tuoi link (http://hothardware.com/Reviews/NVIDIA-Unleashes-Quadro-6000-and-5000-Series-Workstation-GPUs-Review/?page=7)

http://hothardware.com/articleimages/Item1540/quadro_spec6.png

il resto dei test hanno andamento analogo (in alcuni anche peggiore per la geforce)

come spieghi le prestazioni della 480 GTX anche in rapporto alla 5870 (due chip di tipo consumer)? Quanto devo aspettare per avere la risposta? :rolleyes:
A questo intervento, per altro pertinente
non voglio scatenare flame, ma parli per sentito dire o per conoscenza diretta?
Secondo me parli per sentito dire.

CUDA è un ottimo toolkit che manca alla concorrenza, ma se uno si fa il programma in casa senza bisogno di toolkit (facendo però più fatica) i risultati che si hanno con le schede della concorrenza (leggasi ATi) molte volte sono equiparabili, spesso migliori, solo poche volte sono meno efficienti.

Ah, consumano anche molto meno.
hai risposto in questo modo, linkando un test delle quadro quando si stava parlando di CUDA e GPGPU
Nessun flame. Solo questioni di numeri. Vedi i benchmark eseguiti sui programmi professionali che non fanno solo texturing ma implicano l'uso delle capacitò di calcolo per fare qualcosa di più.
Qui trovi qualche test: http://tech.icrontic.com/articles/reviews/back-in-the-big-leagues-the-nvidia-quadro-6000-reviewed/
In conclusione dell'articolo:
The Quadro 6000 managed to score higher than the FirePro V8800 in all of the tests, and in roughly half of the tests on average, it managed to double the performance of the V8800. That is quite the impressive increase. Professionals who work with incredibly intensive projects should take note.

In alcuni test la concorrenza è indietro davvero di tantissimo.



ripeto le domande: cosa fanno le gpu utilizzate in grafica pro di diverso rispetto a quelle utilizzate per i giochi? E cosa c'entrano le quadro con il gpgpu? Quanto devo aspettare per avere le risposte? :rolleyes:


Non è un caso che nvidia abbia il 90% del mercato professionale con le Quadro in un mercato più che maturo e che sa valutare quello che viene offerto.
Le capacità di calcolo delle sue architetture sono oggettivamente superiori. Se poi tu ti fai l'applicazione a casa per calcolarti una specifica cosa è probabile che trovi il modo di sfruttare meglio l'architettura AMD per quella particolare cosa. Ma per il calcolo scientifico, quello generale che implica l'uso di diverse strutture e metodi di calcolo, per ora la concorrenza non c'è.
ripeto la domanda: cosa c'entrano le quadro con il calcolo scientifico? Quanto devo aspettare per avere la risposta? :rolleyes:


I bench del secondo link sono interessanti, ma sono specifici per singola operazione. Nei calcoli veri non si esegue la stessa istruzione un milione di volte e basta saturando in maniera artificiale tutti gli SP alla loro massima efficienza. Entrano in gioco molte altre cose, come ad esempio la capacità di passare i risultati da un thread al successivo o di mixare istruzioni diverse.
Nei bench OpenCL, gli unici che permettono di avere un confronto diretto tra le due architetture, si vede che l'architettura Fermi funziona meglio in quasi tutti gli scenari.
Negli algoritmi dove non si fa solo moltiplicazioni di matrici in DP ad hoc per mostrare la massima efficienza dell'architettura, si vede dove le capacità dell'architettura nvidia vs quella AMD prevale.


Nel campo professionale si usano le capacità di calcolo per fare cose che non sono sole ed esclusivamente quello di muovere poligoni sullo schermo come nei videogiochi.
Potresti spiegare altrimenti come è possibile che il Cypress che nel campo videoludico praticamente sta un solo passo dietro al GF100, nel campo professionale sta 5 o 10 passi indietro. E le specifiche delle schede Quadro non sono quelle GeForce. Nelle Quadro si usa il chip della 470 con frequenze inferiori. I bench dei consumi indicano addirittura che queste schede consumano meno delle schede AMD e vanno di più. Una cosa che a guardare i bench dei videogiochi nessuno crederebbe.
e, infatti, qui di seguito ci mostri un esempio di applicazione OpenCL reale :rotfl:
In OpenCL, che dovrebbe essere il cavallo di battaglia di AMD contro CUDa questi sembrano essere i risultati. Ovviamente stiamo parlando solo di alcuni bench, ma questo è quello che uno si trova davanti quando deve valutare un prodotto:

http://blog.cudachess.org/2010/03/nvidia-gtx-480-first-opencl-benchmark/

E ti anticipo con questa nota:
The OpenCL GPGPU benchmark suite forms part of SiSoftware Sandra 2010. AMD believes it is the only company that can provide a complete OpenCL development platform for GPGPUs - essentially a combination of graphics chip and microprocessor.

Ovvero il test di SiSoft Sandra è già ottimizzato per le GPU ATI poichè ci hanno lavorato assieme.

dal tuo stesso link (http://blog.cudachess.org/2010/03/nvidia-gtx-480-first-opencl-benchmark/) This is the basic “MAD” or “FMAD” test that didn’t correspond to any real-world use of OpenCL

hai idea di cosa sia un loop di fma di tipo scalare a fp32 e chi avvantaggi? Ovviamente no, perchè per te la teoria non serve a niente, l'importante è la pratica che equivale a dire ile "barrette colorate" (anche se poi non capisci neppure a cosa facciano riferimento) :rolleyes:


hai tirato in ballo gli HPC e presunti test che dimostrerebbero non so cosa. Se ti riferivi a quest'articolo (http://www.businessmagazine.it/news/intel-e-nvidia-per-il-piu-potente-supercomputer_34252.html#commenti) che, tra l'altro, contiene dati sbagliati, devo ripeterti quanto già detto: non dimostra un bel niente (http://it.wikipedia.org/wiki/Tianhe-1) e, per quanto possa darti fastidio, da questo link si legge: "Un notevole incremento delle prestazioni del sistema è da imputare al sistema di comunicazione custom sviluppato internamente dal NUDT. Questo sistema permette comunicazioni a 160 Gigabit, il doppio del precedente sistema InfiniBand".

Se vuoi te la ripeto un'altra volta, con parole diverse, non si sa mai che tu non l'abbia capita: perchè in OpenCL, sistema dove AMD sta impiegando tutte le proprie forze mentre nvidia è ben più interessata a lanciare CUDA, le schede nvidia vanno di più in praticamente tutti i bench che vengono mostrati? Compresi quelli preparati da AMD insieme a SiSoft?

http://hothardware.com/Reviews/NVIDIA-Unleashes-Quadro-6000-and-5000-Series-Workstation-GPUs-Review/?page=4

da uno dei tuoi link :D

p.s. nVidia fa parte del consorzio che sviluppa OpenCL (http://it.wikipedia.org/wiki/OpenCL), non è affatto indietro con il supporto e OpenCL non è in competizione con CUDA come non lo è con CAL (chi è il tuo informatore, Paperino?)

Ora, prova a cercare, le risposte alle tue domande ci sono tutte. Quelle che non vedo sono le risposte alle mie :sofico:



Ancora non hai risposto alle domande comunque. Sei su dei binari morti e non sei in grado di uscirne.


se io sono su dei binari morti tu sei deragliato da un pezzo :D

Tutti i test che io ho linkato mostrano che Fermi, sia nelle applicazioni professionali che in quelle di calcolo è nettamente superiore al Cypress. Tu hai postato solo link a test sintetici o particolarmente studiati per eseguire solo un determinato tipo di calcolo.
Ora, ripeto, magari la colpa è dell'ottimizzazione dei driver da parte di AMD, ma il risultato finale è che le schede nvidia vanno di più.

Che la GTX480 vs 5870 vada meno può avere milioni di motivi, come detto, anche il fatto che nvidia sulle versioni consumer delle proprie schede blocca una serie di funzionalità (calcolo DP per esempio)
mentre le sblocca nella versione professionale del chip ottenendo prestazioni più che doppie rispetto alla versione ottimizzata di Cypress. Continui a girare il manico in un paiolo vuoto. Non ha nessuna importanza per chi acquista una Quadro che la GTX480 va una schifezza. Gli interessa che la scheda che acquista faccia il suo mestiere al max, e visti i risultati direi che la concorrenza è una generazione indietro (forse con raddoppio ulteriore degli SP e contorno raggiungerà le performance).
Comunque ti rigiro la frittata: se nel campo professionale le operazioni fatte sono le stesse di quelle usate nei videogiochi, come mai due architetture così simili nei videogiochi poi hanno performance così diverse quando operano (sbloccate, ottimizzate quello che vuoi) nel campo professionale dove ovviamente si cerca di fare in modo che il proprio prodotto dia il massimo senza limitazioni di
sorta?

Il link di Sisandra che mostra la potenza del Cypress maggiore di quella di Fermi è frutto proprio di uno di quei bench semplici che sfruttano le potenzialità dell'architettura 4+1 di AMD (a la 3D Mark).
Ma se guardi i test specifici dove vengono fatti dei bench meno semplici, il Fermi mostra di avere capacità decisamente diverse. Cioè è come se le schede AMD nel 3D mark segnassero il doppio dei punti e poi nei giochi andassero la metà della concorrenza.

Ora, dato che sei tu l'esperto, non è che l'efficienza totale di una architettura non si misura solo nella capacità pura di fare calcoli nella condizione ottimale (come nei bench che TU hai postato) mentre è
un qualcosa che prende in esame anche altre cose che a quanto pare, visti i risulti sul campo, AMD non ha? Prendi per esempio F@H che è un'applicazione a cui sia ATI che nvidia hanno dato grande supporto
per avere un client ottimizzato. Come la spieghi la questione che le schede nvidia siano 3 o 4 volte più veloci? Eppure non è una applicazione sviluppata da nvidia in CUDA e basta. E non è in sviluppo da ieri.
D'altronde, io da puro ignorante al tuo cospetto, mi chiedo che cosa facciano quei 600 milioni di transistor in più in Fermi rispetto al Cypress (o i 500 milioni in più che aveva il G200 rispetto all'RV870)
che lo rendono una piastrella da bagno... forse nvidia aveva voglia di contribuire al riscaldamento globale o ha fatto un accordo con qualche produttore di silicio per consumarne di più senza alcun apparente motivo?

OpenCL non è un concorrente a CUDA? Secondo il marketing AMD lo è. E a guardare i risultati non si direbbe che abbia una grande arma in mano.
Perchè anche se domani le applicazioni (consumer) invece che in CUDA scritte specificatamente per HW nvidia fossero scritte in OpenCL per supportare anche AMD la differenza di prestazioni sarebbe comunque elevata e non favorirebbe certo AMD.

E mi (ti) chiedo. Dove sta il problema di AMD? Architettura (intesa non solo come tipo di scelta per gli SP vettoriali vs scalari) o driver? O per te non ci sono problemi e AMD offre le stesse capacità di nvidia nei settori dove le due architetture vengono spremute? A parte i bench sintetici con moltiplicazioni vettoriali, hai qualche altro link dove mostri che AMD è a questo livello? Io per ora vedo le "famose" barrette mostrare risultati migliori per nvidia invece che per AMD.

Tutti i test che io ho linkato mostrano che Fermi, sia nelle applicazioni professionali che in quelle di calcolo è nettamente superiore al Cypress. Tu hai postato solo link a test sintetici o particolarmente studiati per eseguire solo un determinato tipo di calcolo.
Ora, ripeto, magari la colpa è dell'ottimizzazione dei driver da parte di AMD, ma il risultato finale è che le schede nvidia vanno di più.



anche i tuoi sono test sintetici :D




Che la GTX480 vs 5870 vada meno può avere milioni di motivi, come detto, anche il fatto che nvidia sulle versioni consumer delle proprie schede blocca una serie di funzionalità (calcolo DP per esempio)
mentre le sblocca nella versione professionale del chip ottenendo prestazioni più che doppie rispetto alla versione ottimizzata di Cypress.

la DP non c'entra una mazza con la grafica pro. Sto aspettando ancora la risposta alla domanda: che differenza c'è tra un chip per quadro ed uno per geforce? :D

Continui a girare il manico in un paiolo vuoto. Non ha nessuna importanza per chi acquista una Quadro che la GTX480 va una schifezza. Gli interessa che la scheda che acquista faccia il suo mestiere al max, e visti i risultati direi che la concorrenza è una generazione indietro (forse con raddoppio ulteriore degli SP e contorno raggiungerà le performance).


direi, viste le prestazioni della 480, che hai dimostrato che la 5870 è la miglior vga per rapporto prezzo/prestazioni anche nel professionale. Era questo il tuo intento? :sofico:


Comunque ti rigiro la frittata: se nel campo professionale le operazioni fatte sono le stesse di quelle usate nei videogiochi, come mai due architetture così simili nei videogiochi poi hanno performance così diverse quando operano (sbloccate, ottimizzate quello che vuoi) nel campo professionale dove ovviamente si cerca di fare in modo che il proprio prodotto dia il massimo senza limitazioni di
sorta?


le risposte te le ho date; se tu non le cogli è colpa della tua ignoranza e non ci posso fare niente. Ora sto aspettando le tue risposte.


Il link di Sisandra che mostra la potenza del Cypress maggiore di quella di Fermi è frutto proprio di uno di quei bench semplici che sfruttano le potenzialità dell'architettura 4+1 di AMD (a la 3D Mark).

hai affermato che fermi andava di più con sandra; il tuo stesso link ti ha smentito



Ma se guardi i test specifici dove vengono fatti dei bench meno semplici, il Fermi mostra di avere capacità decisamente diverse. Cioè è come se le schede AMD nel 3D mark segnassero il doppio dei punti e poi nei giochi andassero la metà della concorrenza.


tu non sai niente delle specificità di quei test; hai fatto una figura barbina spacciando per "test pratico, diverso da quelli che fanno ripetere la stessa operazioni fino a saturare tutti gli SP" (parole tue) un test dove c'è scritto chiaramente che si tratta di un loop di fma fp32. Che attendibilità hai quando parli di test in calce ai quali non c'è scritto niente?


Ora, dato che sei tu l'esperto, non è che l'efficienza totale di una architettura non si misura solo nella capacità pura di fare calcoli nella condizione ottimale (come nei bench che TU hai postato) mentre è
un qualcosa che prende in esame anche altre cose che a quanto pare, visti i risulti sul campo, AMD non ha? Prendi per esempio F@H che è un'applicazione a cui sia ATI che nvidia hanno dato grande supporto
per avere un client ottimizzato. Come la spieghi la questione che le schede nvidia siano 3 o 4 volte più veloci? Eppure non è una applicazione sviluppata da nvidia in CUDA e basta. E non è in sviluppo da ieri.


che tipo di operazioni richiede FH?


D'altronde, io da puro ignorante al tuo cospetto, mi chiedo che cosa facciano quei 600 milioni di transistor in più in Fermi rispetto al Cypress (o i 500 milioni in più che aveva il G200 rispetto all'RV870)
che lo rendono una piastrella da bagno... forse nvidia aveva voglia di contribuire al riscaldamento globale o ha fatto un accordo con qualche produttore di silicio per consumarne di più senza alcun apparente motivo?


a causa della finta professione di umiltà da parte di chi, poco sopra, ha scritto: "sei su binari morti e non sai come uscirne" (purtroppo sono bastardo e vendicativo :p ), non perderò tempo a spiegarti quello che ho già detto decine di volte. Però, siccome non sono bastardo fino in fondo, ti dò una dritta: cerca qualcosa su vliw, epic e superscalare.


OpenCL non è un concorrente a CUDA? Secondo il marketing AMD lo è.

di quale marketing parli? Di quello delle chiacchiere da bar del forum o di quello delle dichiarazioni di qualche PR? OpenCL sta a CUDA e CAL come un paio di jeans una felpa e un paio di scarpe stanno ad un coordinato di mutande, calzini e maglietta della salute. Tu ti metti i pantaloni senza mutande? :D


E a guardare i risultati non si direbbe che abbia una grande arma in mano.
Perchè anche se domani le applicazioni (consumer) invece che in CUDA scritte specificatamente per HW nvidia fossero scritte in OpenCL per supportare anche AMD la differenza di prestazioni sarebbe comunque elevata e non favorirebbe certo AMD.


parli sempre dei test con loop di fma fp32? O di quelli che fanno integer bitshift?


E mi (ti) chiedo. Dove sta il problema di AMD? Architettura (intesa non solo come tipo di scelta per gli SP vettoriali vs scalari) o driver? O per te non ci sono problemi e AMD offre le stesse capacità di nvidia nei settori dove le due architetture vengono spremute? A parte i bench sintetici con moltiplicazioni vettoriali, hai qualche altro link dove mostri che AMD è a questo livello? Io per ora vedo le "famose" barrette mostrare risultati migliori per nvidia invece che per AMD.

io, invece, mi chiedo dove stia il tuo di problema. AMD va per la sua strada con i suoi prodotti; vende e anche tanto. nVidia fa altrettanto. Il problema non è né di AMD né di nVidia ma di chi guarda le barrette senza capirci un accidente :mbe:

hai affermato che fermi andava di più con sandra; il tuo stesso link ti ha smentito
Il link che tu hai messo in mostra è il bench sintetico di Sisandra (equivalente ad 3D mark) ed è un bench messo a punto insieme ad AMD. Nei test singoli, dove non si fa semplicemente un loop di una singola istruzione, le prestazioni cambiano.
Cypress scheda con prezzo/prestazioni migliore nel professionale? Ahahah... sìsì, perchè va il doppio dell GF100 montato su una GTX480 e 1/20 dello stesso su una Quadro?
Il chip tra GTX e Quadro è lo stesso, cambia le funzionalità che sono possibili tramite i driver. Ora ti ripeto la domanda, che è di una semplicità disarmante: se i chip sono gli stessi (e lo sono) e con i driver ad hoc si abilitano tutte le funzionalità di cui questi sono capaci (e ci mancherebbe, con quello che si pagano quelle schede) perchè Fermi va il doppio del Cypress? Stiamo parlando di 2 soluzioni che stanno dando (o dovrebbero dare) il massimo delle prestazioni. Dove sta il limite di AMD?

che tipo di operazioni richiede FH?
Usa istruzioni necessarie per fare quello che deve. O uno deve volere una soluzione a seconda dell'architettura che usa? O fare un applicativo che fa un loop infinito di FMA32 per mostrare che una scheda va di più di un'altra? E' una semplice applicazione che fa calcoli (e ne fa tanti) che mostra che l'architettura nvidia funziona meglio. E non è una applicazione fatta da un tizio qualsiasi che si è svegliato la mattina e ha detto: oggi voglio fare una applicazione GPGPU. E' un progetto più che serio dove entrambe AMD e nvidia hanno partecipato attivamente per offrire il meglio. Il risultato non è di qualche punto percentuale di differenza.

Poi ascolta, cerchiamo di recuperare la situazione perchè mi sembra che sia abbastanza degenerata. Tu non hai dato alcuna risposta. Fai solo accenni a cose che tu solo capisci.
Io ho fatto delle domande ben precise, a cui normalmente una persona informata e seria risponde in maniera chiara e comprensibile. Cosa che non è avvenuta.
I test che ho postato come questi: http://www.anandtech.com/show/4008/nvidias-geforce-gtx-580/16 non sono tutti sintetici. In uno di questi si vede che AMD ha un vantaggio rispetto a nvidia, ma in tutti gli altri, dove sono coinvolti operazioni molto complesse come la transcodifica H264 nvidia è decisamente avanti.
Allora, pongo la domanda in maniera diversa: l'approccio VLIW di ATI è efficiente in generale? Ovvero, quanta probabilità c'è in generale che un problema generico possa essere risolto più efficientemente con un approccio vettoriale rispetto a uno scalare?
Guardando le prestazioni di alcuni benchmark, con un calcolo a spanne, sembra che in media gli SP di AMD siano impegnati meno della metà delle loro capacità massime (tenendo conto di numero e frequenza rispetto a quelli nvidia, intendendo come shader proprio le unità singole di calcolo non i gruppi 4+1, ovvero i 1600 shader contro i 512 Cuda core).
Quindi di quelle 5 unità di calcolo solo 2 (più o meno) vengono usate in media. Se i conti spannometrici che ho fatto sono esatti (correggili pure se ho fatto errori), secondo te, è un approccio efficiente rispetto a quello nvidia che li satura sempre tutti magari usando 2 cicli per completare le stesse operazioni che l'architettura AMD fa in un ciclo solo?

Il link che tu hai messo in mostra è il bench sintetico di Sisandra (equivalente ad 3D mark)

veramente sei tu che hai postato quei bench. Memoria corta? Inoltre, vedo che si tratta di bench su memory bandwidth e compute shader: ti risulta che abbiano qualcosa a che fare con 3dmark? Nei link che hai postato per avvalorare la tesi che con sandra le amd andavano meno sono questi
http://hothardware.com/articleimages/Item1540/quadro_sandra1.png


ed è un bench messo a punto insieme ad AMD.
dov'è scritto?


Nei test singoli, dove non si fa semplicemente un loop di una singola istruzione, le prestazioni cambiano.


quali sarebbero questi test singoli; nei link non ne vedo (a parte il loop di fma fp32 che, sicuramente, non è stato messo a punto insieme ad amd :D )


Cypress scheda con prezzo/prestazioni migliore nel professionale? Ahahah... sìsì, perchè va il doppio dell GF100 montato su una GTX480 e 1/20 dello stesso su una Quadro?


http://hothardware.com/articleimages/Item1540/quadro_spec3.png :sofico:

http://hothardware.com/articleimages/Item1540/quadro_spec8.png

http://www.ciao.it/Nvidia_Quadro_6000__3161202

i tuoi conti non tornano :D


Il chip tra GTX e Quadro è lo stesso, cambia le funzionalità che sono possibili tramite i driver. Ora ti ripeto la domanda, che è di una semplicità disarmante: se i chip sono gli stessi (e lo sono) e con i driver ad hoc si abilitano tutte le funzionalità di cui questi sono capaci (e ci mancherebbe, con quello che si pagano quelle schede)

allora, facendo uso degli stessi driver, una 480 va quanto una quadro.........:D


perchè Fermi va il doppio del Cypress? Stiamo parlando di 2 soluzioni che stanno dando (o dovrebbero dare) il massimo delle prestazioni. Dove sta il limite di AMD?


Qui (http://www.beyond3d.com/content/reviews/55/1) e qui (http://www.opengl.org/documentation/) ci sono tutte le risposte. Cercale, visto che sei tanto bravo :p


Usa istruzioni necessarie per fare quello che deve. O uno deve volere una soluzione a seconda dell'architettura che usa? O fare un applicativo che fa un loop infinito di FMA32 per mostrare che una scheda va di più di un'altra? E' una semplice applicazione che fa calcoli (e ne fa tanti) che mostra che l'architettura nvidia funziona meglio. E non è una applicazione fatta da un tizio qualsiasi che si è svegliato la mattina e ha detto: oggi voglio fare una applicazione GPGPU. E' un progetto più che serio dove entrambe AMD e nvidia hanno partecipato attivamente per offrire il meglio. Il risultato non è di qualche punto percentuale di differenza.


che risposta sarebbe?



Poi ascolta, cerchiamo di recuperare la situazione perchè mi sembra che sia abbastanza degenerata. Tu non hai dato alcuna risposta. Fai solo accenni a cose che tu solo capisci.

io le risposte lo ho date tutte; se non capisci è un tuo problema, grand'uomo


Io ho fatto delle domande ben precise, a cui normalmente una persona informata e seria risponde in maniera chiara e comprensibile. Cosa che non è avvenuta.


anche io ho fatto domande chiare e precise che tu hai evitato addirittura di quotare. Il tuo scopo non è quello di ottenere risposte ma di dimostrare una tesi indimostrabile. In più non hai le basi teoriche per sostenere una discussione ma hai l'atteggiamento di chi sa tutto. Hai fatto una serie di affermazioni categoriche smontate dai fatti ma, nonostante tutto, insisti. Allora tieniti le tue convinzioni, visto che ti rifiuti di vedere tutto quello che potrebbe farle crollare. Oppure fai uno sforzo e cerca di studiare un po' di teoria (che schifo!!!!) e non limitarti a guardare le barrette colorate che neppure comprendi.



I test che ho postato come questi: http://www.anandtech.com/show/4008/nvidias-geforce-gtx-580/16 non sono tutti sintetici. In uno di questi si vede che AMD ha un vantaggio rispetto a nvidia, ma in tutti gli altri, dove sono coinvolti operazioni molto complesse come la transcodifica H264 nvidia è decisamente avanti.


la transcodifica h264 non è un'operazione complessa e nei link che ti ho postato c'è la risposta anche a questo. Cercala.



Allora, pongo la domanda in maniera diversa:

ok, adesso si inizia a ragionare.


l'approccio VLIW di ATI è efficiente in generale?
no, come non lo è nessun tipo di approccio. L'architettura con alu di tipo vliw permette di ottenere un'elevata efficienza di tipo performance/watt e, ancora di più, performance/area ma non di avere un'elevata efficienza in valore assoluto.


Ovvero, quanta probabilità c'è in generale che un problema generico possa essere risolto più efficientemente con un approccio vettoriale rispetto a uno scalare?


dipende; in realtà l'approccio vettoriale è ancora differente da uno di tipo vliw. In ogni caso, se guardi le due tabelle di inizio pagina http://www.beyond3d.com/content/reviews/55/11
puoi farti un'idea del tipo di codice che può favorire una o l'altra architettura. Apparentemente, l'architettura vliw ha più situazioni in cui è in vantaggio. Però queste situazioni coinvolgono sempre operazioni di tipo vettoriale. Nelle operazioni scalari (tipo la fma fp32 più volte citata), solo una delle 5 vie di ogni alu è occupata nell'esecuzione dell'istruzione. I SW sono un mix di istruzioni di tipo scalare e vettoriale, in floating point o con interi. Se ho un SW che propone un loop di fma o mad fp32, fermi andrà alla massima velocità mentre cypress ad 1/5 della velocità possibile. Diciamo che l'architettura vliw è più dipendente rispetto alle ottimizzazioni del codice ed alla bontà del compilatore, perchè per avere il maggior numero di alu attive è necessario trovare più istruzioni, relative allo stesso thread, indipendenti tra loro (in modo che possano essere chiamate contemporaneamente). In caso di istruzioni scalari dipendenti le une dalle altre (devo aspettare il termine dell'esecuzione di una perchè nella successiva devo inserire il risultato della precedente) l'approccio vliw è molto penalizzato.
Un esempio pratico è quello che hai fatto sulle transcodifiche. In quel tipo di operazioni, si fa molto ricorso all'utilizzo di interi e, dalle tabelle, puoi vedere che, ad esmepio, nell'escuzione dei calcoli con interi fermi, tranne il caso di mad di tipo vect4 (poco usata in questo contesto) è alla pari con cypress e, addirittura, si avvantaggia nell'uso della mad di tipo scalare.



Guardando le prestazioni di alcuni benchmark, con un calcolo a spanne, sembra che in media gli SP di AMD siano impegnati meno della metà delle loro capacità massime (tenendo conto di numero e frequenza rispetto a quelli nvidia, intendendo come shader proprio le unità singole di calcolo non i gruppi 4+1, ovvero i 1600 shader contro i 512 Cuda core).
Quindi di quelle 5 unità di calcolo solo 2 (più o meno) vengono usate in media.

molto dipende dalle ottimizzazioni del SW. A spanne, l'impiego varia dalle 3 alle 4 con una media di poco inferiore alle 3,5 vie di un'alu 5-way vliw (motivo per cui si sta valutando l'ipotesi di alu 4-way). In ogni caso, in un'elaborazione complessa entrano in gioco altri fattori di limitazione.
Se guardi, sempre nella stessa pagina, i grafici (con esclusione di quelli DP che è usata solo per il gpgpu), puoi vedere che, a parte i domain shader (una delle componenti dell'operazione di tessellation), in tutte le operazioni di tipo geometrico fermi è mediamente avanti, mentre nelle operazioni di pixel shading è avanti solo con valori scalari (lo stesso puoi vederlo qua (http://www.hardware.fr/articles/787-8/dossier-nvidia-geforce-gtx-480-470.html) e qua (http://www.hardware.fr/articles/787-7/dossier-nvidia-geforce-gtx-480-470.html)). Sia i grafici (sperimentali) che le tabelle (teoriche) comprendono tutte le situazioni possibili (scalari, vettoriali con 2, con 3, con 4 istruzioni indipendenti per ciclo). Ad esempio, un singolo thread con 3 istruzioni indipendenti, su cypress è eseguito in un solo ciclo su fermi in 3 cicli. Quindi, in quel caso, avere 3 alu in parallelo è vantaggioso rispetto ad averne una sola per thread. Sulle operazioni di tipo trascendentale è avvantaggiato cypress perchè ha una unità per ogni alu, dedicata a quel tipo di operazioni, mentre fermi ne ha solo 4 per ogni cluster di alu. Nelle operazioni con interi, invece, fermi ha una unità dedicata ogni due alu floating point mentre cypress una ogni 5.
Poi ci sono le operazioni di texturing (http://www.beyond3d.com/content/reviews/55/12) dove è avvantaggiato cypress; questo perchè il texture filtering è eseguito dallo shader core e nei chip nVidia le texture arrivano compresse e devono essere decompresse prima dell'applicazione. Però, all'aumentare delle dimensioni delle texture, il vantaggio di cypress diminuisce a causa del fatto che le texture sono decompresse nel passaggio in L1 e, di conseguenza, occupano più spazio, mentre fermi le decomprime solo quando prima di effettuare l'interpolazione. .
Nelle operazioni di branching (http://www.hardware.fr/articles/787-7/dossier-nvidia-geforce-gtx-480-470.html) fermi utilizza una granularità inferiore (quad di 16 vertex value o 32 pixel vs 16 vertici o 64 pixel) e risulta più efficiente mentre nelle operazioni di color blendong (http://www.beyond3d.com/content/reviews/55/13) è in vantaggio cypress.
Infine ci sono gli accessi alle varie memorie (http://www.beyond3d.com/content/reviews/55/14) e il triangle setup engine in cui è in vantaggio fermi grazie alla possibilità di caricare più di un triangolo per ciclo di clock.
Le variabili in gioco sono tantissime e non è possibile ridurre tutto ad un confronto tra l'efficienza delle sole alu, fermo restando che un'architettura vliw è, in assoluto, meno efficiente se si fa il confronto con i limiti teorici, rispetto ad una superscalare. La diminuzione di efficienza dipende, come detto, in massima parte d come è ottimizzato il SW (per questo un bench che prevede un loop di mad fp32 non può essere stato studiato insieme ad amd, ad esempio).
La cosa curiosa di tutto questo è che c'è stata un'inversione in molti campi rispetto al passato; ad esempio, fino a G70 ed R5x0, il dynamic branching di nVidia era un disastro mentre era in vantaggio con le operazioni di texture filtering. Discorso analogo per le operazioni geometriche e per le raster operation (color e alpha blending). Nelle prime era in vantaggio ATi e nelle seconde nVidia. :D


Se i conti spannometrici che ho fatto sono esatti (correggili pure se ho fatto errori), secondo te, è un approccio efficiente rispetto a quello nvidia che li satura sempre tutti magari usando 2 cicli per completare le stesse operazioni che l'architettura AMD fa in un ciclo solo?

AMD punta ad avere un elevato rapporto performance/area e performance/watt, in modo da ridurre i costi di produzione. Ovviamente, parte di quello che non si spende a livello di progettazione e ricerca per l'hardware lo si spende per il SW, poichè l'architettura vliw sposta parte del lavoro di parallelizzazione a livello di compilatore (quanto di questo lavoro è spostato a livello di software dipende dal tipo di architettura, poichè esistono 3 tipi riconducibili al modello vliw, uno detto "statico", uno "dinamico" e, infine la epic). Sui chip AMD il bilanciamento dei carichi di lavoro è gestito via hardware, come in quelli nVidia; quello che è gestito via SW è l'ILP (instruction level parallelism) ovvero il compilatore si deve occupare di cercare il maggior numero di istruzioni relative ad uno stesso thread che siano indipendenti. Se l'applicazione è scritta pprivilegiando poerazion scalari e istruzioni dipendenti, il lavoro del compilatore non è per nulla avvantaggiato :D .
Dal canto suo, invece, nVidia ha spostato la maggiore complessità a livello di hardware. Questo significa che i suoi chip sono meno dipendenti dall'ottimizzazione del SW ed è più semplice ottimizzare via driver. Lo svantaggio di questo approccio è che gran parte dei transistor sono utilizzati per circuiti che svolgono compiti non funzionali ai calcoli (circuiti di controllo, feedback, gestione dei clock, instruction e data fetch). Inoltre, un altro vantaggio di cypress è che per mascherare le latenze necessità di un numero inferiore di thread in circolazione all'interno della pipeline, il che si traduce in un minor ricorso a buffer di registri atti temporanei, atti a contenere i risultati intermedi delle elaborazioni. Il core di un chip come fermi, quindi, rispetto a cypress, ha, in percentuale, un'area di molto inferiore dedicata alle unità di calcolo vere e proprie. La scelta è stata dettata principalmente dal fatto che nVidia è obbligata a spingere sul gpgpu non potendo realizzare architetture x86 (che resta, nonostante tutto, il modello più utilizzato anche nei sistemi HPC) mentre AMD può puntare su apu asimmetriche con una cpu e una o più gpu come coprocessori
Di conseguenza, da un lato hai una maggiore efficienza che paghi con il poco spazio da poter dedicare alle unità di calcolo (da qui la necessità di differenziare il clock degli shader rispetto al resto del core del chip). Dall'altro una minor efficienza che compensi potendo, ad ogni nuovo processo produttivo, inserire un numero molto maggiore di unità di calcolo rispetto alla concorrenza.
Chiudo con la conclusione dell'articolo di B3D

Great performance with the newest games is in great part-owed to developer relations superiority -- we're sure we'll get some hate-mail over this statement, but we're at a point where we can call them as they are, rather than cater to anyone's sensibilities -- rather than some intrinsic mystic hardware unit that exists only in NVIDIA's products.

And all of this put together underlines the truth that some still choose to ignore: great hardware is nothing without software. We dare say that NVIDIA's great software stack made Fermi look a bit better competitively than its hardware would have allowed (just look at sheer measured throughput!) -- luckily for them, it appears that this particular situation won't be changing soon, with no competitive pressure on the horizon on the software front.

We think that going forward, the major challenges for NVIDIA's architects will be to get all of the nice ideas they've implemented trimmed down in order to descend into the more palatable die-size/thermal envelope area required by smaller chips, as well as smooth off some of the rougher corners: more L2 bandwidth, better GDDR5 memory controllers and better performance for atomics depending on where they're stored in the memory hierarchy spring to mind as viable avenues to pursue, and all would benefit both graphics and compute workloads.

quello che è riportato per i giochi lo si può estendere al SW in generale, compreso quello pro. Migliori relazioni con gli sviluppatori significa, tradotto in parole povere, miglior ottimizzazione del codice per l'hardware nVidia.
In quanto all'ultima parte, sono curioso di vedere se e come sarà affrontato il problema di cercare di ridurre le dimensioni dei chip. Per quanto detto prima, se nVidia mantiene questa tipologia di architettura avrà sempre poco spazio sul die da poter dedicare alle unità funzionali. Ridurre ancora la granularità dei cluster (dai 16+16 attuali) porterebbe ad un incremento dell'efficienza del singolo cluster ma anche ad un ulteriore aumento dello spazio da dedicare a elementi non funzionali.

Sono finalmente riuscito a leggere tutta la review di Beyond3D riguardo a Fermi (il lavoro, questa rottura...)
Premesso che questi test estremamente sintetici hanno solo valore indicativo, dato che come hai detto tu le variabili in gioco sono tantissime e sarebbe bello avere un bench in cui si faccia qualcosa di concreto che prenda in esame la collaborazione delle varie parti della pipeline di calcolo/3D invece che una sola parte specifica, aggiungo solo che i valori di performance nel calcolo DP in quei test è 1/4 e il setup dei triangoli è una frazione di quello che Fermi è in grado di fare per via proprio dei driver "consumer" a cui le GTX sono relegati. Relativamente agli apparenti risultati deludenti dei bench della GTX470 in esame:
In fact, we struggled with many potential theories, until a fortuitous encounter with a Quadro made the truth painfully obvious: product differentiation, a somewhat en vogue term over at NVIDIA, it seems. The Quadro, in spite of being pretty much the same hardware (this is a signal to all those that believe there's magical hardware in the Quadro because it's more expensive – engage rant mode!), is quite happy doing full speed setup on the untessellated plebs.

allora, facendo uso degli stessi driver, una 480 va quanto una quadro.........
Premesso che le Quadro sono fatte con i chip delle 470 non delle 480, l'hack del bios delle schede consumer per farle "sembrare" delle vere Quadro è noto da tempo. nvidia ha deciso di difendere il proprio mercato professionale dall'uso dello stesso HW che vende nel mercato consumer in questo modo. Quando compri una GTX sai che avrai 1/4 delle capacità di calcolo DP e una limitata capacità di gestione delle viewport che vengono completamente sbloccate se paghi di più.

Ecco perchè Fermi su una GTX480 nei test professionali è una schifezza assoluta, mentre montato su una Quadro risulta essere decisamente più veloce anche della concorrenza che secondo i test di Beyond3d dovrebbe essere teoricamente molto (ma molto) più veloce.

L'unica cosa che sembra non essere all'altezza con la concorrenza è il fillrate e la gestione delle texture, sempre secondo i test riportati. Poi per via della diversa modalità di gestione delle texture sarebbe interessante capire quanto di quel vantaggio che i grafici mostrano siano reali in una applicazione reale dove le texture non sono normalmente completamente contenibili nella L1 del Cypress (oltre a verificare che impatto ha la trasmissione di più dati nel Cypress o lo switching di thread che necessitano della L1 che deve essere liberata).

A parte questi dettagli, quello che sembra è che Fermi sia pensato veramente come un sistema General Purpose senza "additivi" vari specialistici. Per quanto è possibile nvidia ricicla le unità standard presenti nel chip per eseguire in maniera generica tutte le possibili computazioni, mentre AMD sembra aver aggiunto HW apposito là dove lo riteneva opportuno.
I due approcci sono equivalentemente validi, ma quello nvidia (sebbene non particolarmente performante in alcune situazioni) sembra permettere una gestione più facile del proprio HW dato che percorsi e inevitabili conflitti sono più facilmente prevedibili e lo scheduler può in questa maniera essere più efficiente. E la logica di gestione la può fare in HW.
Ecco perchè ritengo che la valutazione delle performance andrebbe fatta con un bench che implichi l'uso reale delle risorse per evidenziare l'architettura meglio bilanciata (più efficiente) invece che un'ispezione particolare di ogni sottoparte. Queste analisi sono molto interessanti, ma non danno il senso di quello che è poi il risultato finale, che come in tutti i sistemi complessi (e questi sono forse la cosa più complessa che l'uomo abbia mai creato) non sono la semplice somma dei risultati parziali.
Premesso che la soluzione VLIW sia 4 volte più veloce della soluzione scalare di nvidia in alcune istruzioni, se queste però sono il 5% del totale delle istruzioni eseguite (faccio una ipotesi di quello che potrebbe essere un algoritmo generico) allora il vantaggio prestazionale non sarà evidente e si manterrà un misurabile vantaggio solo se il resto delle istruzioni vengono eseguite almeno con la stessa efficacia della concorrenza. Basta un punto che faccia da collo di bottiglia (o semplicemente il fatto che i risultati ottimali mostrati dai test non si riesca mai a ottenerli in condizioni reali) e tutta la teoria va a escort.

La pratica per ora dice che le Quadro vanno il doppio delle FirePro anche se i test fin qui mostrati suggerirebbero proprio il contrario. Più difficile valutare la parte di computazione dove l'implementazione dell'algoritmo è fondamentale , ma quelli OpenCL mostrano una situazione analoga.

Domanda finale: e' possibile la situazione futura in cui AMD "restringe" la sua architettura VLIW (oltre a quello fatto con Cayman) mentre nvidia "espande" la sua magari a 2 unità in parallelo? O per nvidia la cosa sarebbe troppo difficoltosa e la preferenza sarebbe piuttosto quella i raddoppiare le proprie unita scalari (a discapito della logica HW necessaria a connetterli e gestirli)?

Sono finalmente riuscito a leggere tutta la review di Beyond3D riguardo a Fermi (il lavoro, questa rottura...)
Premesso che questi test estremamente sintetici hanno solo valore indicativo, dato che come hai detto tu le variabili in gioco sono tantissime e sarebbe bello avere un bench in cui si faccia qualcosa di concreto che prenda in esame la collaborazione delle varie parti della pipeline di calcolo/3D invece che una sola parte specifica, aggiungo solo che i valori di performance nel calcolo DP in quei test è 1/4

e questo lo avevamo già detto con pleg. Infatti, in quei test, una tesla pareggia, all'incirca il conto in molti test dove la 470 è sotto.

e il setup dei triangoli è una frazione di quello che Fermi è in grado di fare per via proprio dei driver "consumer" a cui le GTX sono relegati. Relativamente agli apparenti risultati deludenti dei bench della GTX470 in esame:

Premesso che le Quadro sono fatte con i chip delle 470 non delle 480, l'hack del bios delle schede consumer per farle "sembrare" delle vere Quadro è noto da tempo. nvidia ha deciso di difendere il proprio mercato professionale dall'uso dello stesso HW che vende nel mercato consumer in questo modo. Quando compri una GTX sai che avrai 1/4 delle capacità di calcolo DP e una limitata capacità di gestione delle viewport che vengono completamente sbloccate se paghi di più.

Ecco perchè Fermi su una GTX480 nei test professionali è una schifezza assoluta, mentre montato su una Quadro risulta essere decisamente più veloce anche della concorrenza che secondo i test di Beyond3d dovrebbe essere teoricamente molto (ma molto) più veloce.



finalmente :D
ora è chiaro che con SW pro vengono castrate le gpu consumer (nVidia lo fa in maniera molto più pesante ma lo fa anche ati) e viceversa (guarda caso, con i giochi, le schede pro vanno sempre "un po' di meno" a parità di specifiche :D

L'unica cosa che sembra non essere all'altezza con la concorrenza è il fillrate e la gestione delle texture, sempre secondo i test riportati. Poi per via della diversa modalità di gestione delle texture sarebbe interessante capire quanto di quel vantaggio che i grafici mostrano siano reali in una applicazione reale dove le texture non sono normalmente completamente contenibili nella L1 del Cypress (oltre a verificare che impatto ha la trasmissione di più dati nel Cypress o lo switching di thread che necessitano della L1 che deve essere liberata).

direi anche i calcoli che prevedono l'utilizzo di vettori anzichè scalari.
Per le operazioni di texturing, quando si fa un accesso a texture la pipeline non va in stallo in attesa del completamento dell'operazione ma il relativo thread vìene "parcheggiato" in attesa del dato mancante (la texture nella fattispecie) e si passa ad un altro thread (indipendente dal risultato di quello in esecuzione, ovviamente). Un altro fattore che non hai considerato nella generazione delle operazioni di texture e non solo è la gerarchia delle memorie interne. In questo l'architettura vliw è superiore i quanto i dettagli dell'architettura sono completamente esposti. Il risultato è una maggiore efficienza che si traduce in una maggiore velocità nelle operazioni di load e store dai registri e un miglior mascheramento delle latenze (dovuto soprattutto alla maggior velocità di accesso ai vari ordini di memoria).
In quanto al discorso sulla L1, questo è valido solo in caso di cache miss, piuttosto improbabile con gerarchia delle cache di tipo fully associative associata ad algoritmi di branching. .


A parte questi dettagli, quello che sembra è che Fermi sia pensato veramente come un sistema General Purpose senza "additivi" vari specialistici. Per quanto è possibile nvidia ricicla le unità standard presenti nel chip per eseguire in maniera generica tutte le possibili computazioni, mentre AMD sembra aver aggiunto HW apposito là dove lo riteneva opportuno.


rispetto a nvidia, l'unico hardware dedicato di amd è quello relativo a hull e domain shader. Per il resto, pixel, vertex e geometry shader, nonchè texture filtering, sono svolte dalle alu. Le operazioni di texture fetch e address sono svolte da unità dedicate nelle tmu; lo stesso vale per le operazioni a livello di ROP's. Questo perchè è molto più efficiente un approccio di questo tipo (unità dedicate di tipo fixed function) piuttosto che unità generiche (come si proponeva intel con larrabee). Entrambe hanno aggiunto alu di tipo integer per le operazioni con interi (amd una per ogni alu 5-way, nvidia una ogni due unità floating). Anche per le operazioni trascendentali ci sono unità dedicate (amd ne ha una per ogni alu 5-way nvidia 4 ogni cluster di alu; questo spiega il fatto che in questo tipo di operazioni i chip ati sono più veloci).


I due approcci sono equivalentemente validi, ma quello nvidia (sebbene non particolarmente performante in alcune situazioni) sembra permettere una gestione più facile del proprio HW dato che percorsi e inevitabili conflitti sono più facilmente prevedibili e lo scheduler può in questa maniera essere più efficiente. E la logica di gestione la può fare in HW.


anche nei chip ati il bilanciamento dei carichi è gestito in hardware. Solo la parallelizzazione è affidata al compiler; in pratica il compiler "cerca" istruzioni non indipendenti relative ad un thread, le impacchetta e le passa al thread processor. Fisicamente di questa operazione si occupa un thread generator
La differenza la possono fare applicazioni difficilmente parallelizzabili che favoriscono l'HW nvidia.


Ecco perchè ritengo che la valutazione delle performance andrebbe fatta con un bench che implichi l'uso reale delle risorse per evidenziare l'architettura meglio bilanciata (più efficiente) invece che un'ispezione particolare di ogni sottoparte. Queste analisi sono molto interessanti, ma non danno il senso di quello che è poi il risultato finale, che come in tutti i sistemi complessi (e questi sono forse la cosa più complessa che l'uomo abbia mai creato) non sono la semplice somma dei risultati parziali.


Il problema di un sw del genere è che dovrebbe essere del tutto scevro da ottimizzazioni di sorta. Il che è praticamente impossibile per diversi motivi. Se scrivi codice facilmente parallelizzabile favorisci ati, se lo scrivi con forte prevalenza di operazioni seriali nvidia, con la tessellation favorisci nvidia, con le testure ati. E basta poco a spostare l'equilibrio anche di tanto (hai visto cosa si può fare a livello di driver, soprattutto per "castrare" un chip. E non è finita. Due architetture identiche ma con differente ID (in modo che siano riconoscibili) possono comportarsi in maniera molto differente con o stesso SW. Questo perchè a livello di driver o di hal (hardware later abstraction) ho la possibilità di individuare e inibire alcune funzionalità su un chip e non s su un altro. Basta, ad esempio, agire sulla gestione degli accessi alla memoria per creare disastri (è uno dei modi più semplici per far crollare le prestazioni di un chip)



Premesso che la soluzione VLIW sia 4 volte più veloce della soluzione scalare di nvidia in alcune istruzioni, se queste però sono il 5% del totale delle istruzioni eseguite (faccio una ipotesi di quello che potrebbe essere un algoritmo generico) allora il vantaggio prestazionale non sarà evidente e si manterrà un misurabile vantaggio solo se il resto delle istruzioni vengono eseguite almeno con la stessa efficacia della concorrenza. Basta un punto che faccia da collo di bottiglia (o semplicemente il fatto che i risultati ottimali mostrati dai test non si riesca mai a ottenerli in condizioni reali) e tutta la teoria va a escort.


hai centrato il punto; dipende da come è scritto il codice. Le istruzioni assimilabili ad un vettore possono essere il 5 o il 95%. Tutto dipende dal programmatore. Si può anche aggiungere che l'architettura nvidia ha prestazioni più lineari. Ovvio che le ottimizzazioni sono importanti, ma non avrai mai picchi in negativo o in positivo che puoi avere con quella amd. Una hd5870 che elabora solo istruzioni seriali (mi limito ai soli calcoli matematici) ha l'equivalente di 320 e non più 1600 alu a 850 MHz. :D


La pratica per ora dice che le Quadro vanno il doppio delle FirePro anche se i test fin qui mostrati suggerirebbero proprio il contrario. Più difficile valutare la parte di computazione dove l'implementazione dell'algoritmo è fondamentale , ma quelli OpenCL mostrano una situazione analoga.


il fatto è che dovremmo sapere che tipo di codice elaborano quando eseguono quei test. :D


Domanda finale: e' possibile la situazione futura in cui AMD "restringe" la sua architettura VLIW (oltre a quello fatto con Cayman) mentre nvidia "espande" la sua magari a 2 unità in parallelo? O per nvidia la cosa sarebbe troppo difficoltosa e la preferenza sarebbe piuttosto quella i raddoppiare le proprie unita scalari (a discapito della logica HW necessaria a connetterli e gestirli)?

no per entrambe. AMD perderebbe il vantaggio dell'architettura vliw (architettura semplice con elevato livello di ILP. Al contrario, se nVidia punta ad un'architettura CPU-like deve avvicinarsi il più possibile ad un modello tipo MIMD (ossia molte istruzioni in ingresso per molti dati in uscita). Il modello a cui si rifà il singolo cluster è quello SIMD, ovvero, pur operando su thread differenti, ogni alu esegue lo stesso tipo di istruzione delle altre dello stesso cluster (lo stesso vale per AMD). Con g80 ogni cluster aveva 16 alu che sono diventate 24 con GT200. Con fermi si è passati a 32 per problemi di gestione nello scambio dati tra cluster (16 stream processor sono un numero considerevole (considera che io definisco stream processor un intero cluster)). Per ridurre l'impatto negativo di avere 32 alu ad eseguire lo stesso tipo di istruzione e, quindi, per ricreare una "granularità" simile a quella di g80, è stato introdotto un doppio schedule per ogni cluster.

ora è chiaro che con SW pro vengono castrate le gpu consumer (nVidia lo fa in maniera molto più pesante ma lo fa anche ati) e viceversa (guarda caso, con i giochi, le schede pro vanno sempre "un po' di meno" a parità di specifiche
Be', "finalmente", mi sembra che la questione dei driver che castravano le prestazioni la avessi già sollevata qualche post fa.
il fatto è che dovremmo sapere che tipo di codice elaborano quando eseguono quei test.
Ok, ma per le operazioni grafiche fatte dai programmi professionali come si spiegano le prestazioni doppie di Fermi? Dai test sembrerebbe che i risultati dovrebbero essere invertiti, con il Cypress che va il doppio di Fermi. Forse sarebbe utile avere gli stessi bench eseguiti su una Quadro per vedere quali sono i veri risultati che il chip non castrato può realmente eseguire.
Comunque il risultato, se ammettiamo ragionevolmente che AMD non abbia castrato in alcun modo il chip sulla FirePro, indica che le prestazioni dei due chip sono notevolmente differenti e la questione prestazioni/consumi si ribalta in favore di nvidia.

Per la parte di calcolo invece, bisognerebbe fare un test di quali algoritmi si avvantaggino delle operazioni vettoriali o "atomicamente parallelizzabile" e quanto di questo codice è rispetto al totale eseguito. Ripeto, se per ogni calcolo vettoriale/istruzioni parallelizzabili poi mi serve fare 10 operazioni scalari o bloccanti, è possibile che il vantaggio non sia in alcun modo misurabile.

rispetto a nvidia, l'unico hardware dedicato di amd è quello relativo a hull e domain shader.
Secondo le speculazioni di Beyond 3D sembra che AMD abbia HW specializzato per eseguire le operazioni atomiche, mentre nvidia si affida alle ROP che lavorano il L2 e quindi ha necessità di portare i dati lì dalla L1/shared memory con conseguente perdita di efficienza.

Indipendentemente se sia vero o meno, sembra che nvidia abbia prediletto la semplicità del percorso dati e esecuzione di rispetto alla velocità assoluta (probabilmente per come hai detto tu per via di riuscire ad avvicinarsi il più possibile ad una situazione CPU-like).

Ok, ma per le operazioni grafiche fatte dai programmi professionali come si spiegano le prestazioni doppie di Fermi? Dai test sembrerebbe che i risultati dovrebbero essere invertiti, con il Cypress che va il doppio di Fermi. Forse sarebbe utile avere gli stessi bench eseguiti su una Quadro per vedere quali sono i veri risultati che il chip non castrato può realmente eseguire.
Comunque il risultato, se ammettiamo ragionevolmente che AMD non abbia castrato in alcun modo il chip sulla FirePro, indica che le prestazioni dei due chip sono notevolmente differenti e la questione prestazioni/consumi si ribalta in favore di nvidia.


qualunque chip non può andare oltre quelli che sono i valori teorici di calcolo; le quadro, nel segmento pro, non sono "castrate" a livello di setup engine geometrico come le geforce non lo sono nel settore gaming. E' sbagliato dire che il vero potenziale di fermi lo vedi nel segmento pro perchè il vero potenziale di fermi è quello del segmento pro ma anche quello del segmento gaming (e nVidia sarebbe masochista a "tagliare le prestazioni di un chip di tipo consumer nel segmento gaming quando può farlo andare a tutta e "limitarlo" via driver solo con applicazioni pro. L'unico limite fisico dei chip di tipo consumer ma anche di quelli per grafica pro è nella capacità di calcolo in DP (che serve solo in ambito GPGPU, ossia sulle tesla che, d'altra parte, non hanno ROP's e TMU).
In quelle applicazioni dive le quadro vanno il doppio è molto probabile che si faccia largo uso di codice seriale e questo è in linea con i test sintetici. Se lancio un'applicazione fatta dal (ipotesi) il 60% di operazioni scalari dipendenti, per il 60% del tempo cypress avrà una potenza di calcolo ridotta ad 1/5 di quella teorica mentre fermi andrà a tutta (il che significa circa il doppio rispetto a cypress). Se faccio color blending con 8 bit interi per canale, annullo il vantaggio della maggior velocità d'esecuzione delle ROP's di cypress. Questo sono solo alcune delle cose che si possono fare e, in molti casi si fanno a livello di SW. Ovviamente, ho parlato solo di ciò che può penalizzare l'architettura AMD perchè in questo contesto si parla di questo.
Ripeto, la questione prestazioni è troppo legata a fattori che hanno poco o nulla di oggettivo. Carmack, non molto tempo fa, ha affermato che è possibile scrivere codice in modo da enfatizzare le prestazioni di un'architettura e abbattere quelle di un'altra. In realtà è proprio così e lui, tra l'altro, l'ha dimostrato con doom3, con cui ha fatto il miracolo di far andare nv3x quanto r3x0 (caso unico nel panorama dei SW dell'epoca). Qualunque programmatore potrebbe confermarti quanto ti sto dicendo.


Per la parte di calcolo invece, bisognerebbe fare un test di quali algoritmi si avvantaggino delle operazioni vettoriali o "atomicamente parallelizzabile" e quanto di questo codice è rispetto al totale eseguito. Ripeto, se per ogni calcolo vettoriale/istruzioni parallelizzabili poi mi serve fare 10 operazioni scalari o bloccanti, è possibile che il vantaggio non sia in alcun modo misurabile.


ci sono tanti modi per ottenere lo stesso risultato. Puoi scrivere per ps3 o x360 ed ottenere lo stesso risultato con HW molto diversi tra loro. Ovviamente il codice non è lo stesso, ma è ottimizzato per l'una o l'altra architettura.


Secondo le speculazioni di Beyond 3D sembra che AMD abbia HW specializzato per eseguire le operazioni atomiche, mentre nvidia si affida alle ROP che lavorano il L2 e quindi ha necessità di portare i dati lì dalla L1/shared memory con conseguente perdita di efficienza.


non ha hardware specializzato per l'esecuzione delle atomic ops ma per la gestione dei thread concorrenti (che nVidia, molto probabilmente, affida ai MC delle ROp's). Si tratta, in ogni caso, di logica di controllo e non di unità funzionali.


Indipendentemente se sia vero o meno, sembra che nvidia abbia prediletto la semplicità del percorso dati e esecuzione di rispetto alla velocità assoluta (probabilmente per come hai detto tu per via di riuscire ad avvicinarsi il più possibile ad una situazione CPU-like).

al contrario; l'architettura nVidia è molto più complessa proprio a livello di gestione perchè ha, all'interno, molti più circuiti di controllo, di sincronizzazioni dei clock ecc. Qui (http://www.haenni.info/thesis/presentations/noptimization_html/sld006.htm) puoi avere un'idea di massima, tenendo conto che quella di ATi non è una vliw pura ma una sorta di ibrido con il bilanciamento dei carichi di tipo dinamico. Da li si vede come la logica di controllo per ogni unità funzionale sia più complessa. Questo si traduce anche in più cicli spesi per arrivare ad eseguire la stessa operazione. I vantaggi della vliw e della superscalare sono riassunti (almeno in linea di massima) nella 4 righe riportate sotto. In particolare,la vliw ha hardware molto più semplice e sposta parte della complessità a livello di SW. Questo significa percorsi più brevi ed esecuzione più veloce. La superscalare ha un HW più complesso ma riesce a sfruttare, mediamente, in modo più efficiente le unità funzionali anche nel caso peggiore.
Le cpu hanno un rapporto tra unità di controllo e gestione ed unità funzionali ancora più sbilanciato (e anche di molto) verso le prime con un modello di programmazione che è di tipo task parallel, mentre per le gpu si può parlare di data parallel (poche istruzioni per ciclo ma con molti dati in circolazione, proprio per il fatto che i cluster sono di tipo SIMD).

Che si possa fare un SW che va meglio su una architettura e affondi 'altra credo che non vi siano dubbi.
Io parto dal presupposto che ho un problema da risolvere (che so, una convoluzione da eseguire su una immagine molto molto grande). Ora io scrivo l'algoritmo (ed essendo abituato a un codice single task seriale usando linguaggi come il C/C++) cerco di farlo al meglio perchè si adatti alle capacità della GPU (come hai detto tu, single instruction multple data). Mi aspetto che il relativo compilatore ottimizzi al meglio il mio algoritmo (per quanto possibile ovviamente). L'aspetto di come scrivere il codice perché giri meglio su una GPU piuttosto che un'altra per me dovrebbe essere trasparente (così come quando scrivo in C non mi preoccupo sui singoli aspetti della architettura su cui girerà).

L'unico limite fisico dei chip di tipo consumer ma anche di quelli per grafica pro è nella capacità di calcolo in DP (che serve solo in ambito GPGPU, ossia sulle tesla che, d'altra parte, non hanno ROP's e TMU).
Come non hanno le ROPs o TMUs? Non mi sembra che il GF100 sulle Tesla sia fisicamente differente da quello che viene prodotto per le GTX470. Sarebbe un costo non indifferente avere 2 chip diversi.

In quelle applicazioni dive le quadro vanno il doppio è molto probabile che si faccia largo uso di codice seriale e questo è in linea con i test sintetici
Ma sono "semplici" operazioni grafiche non diverse da quello che avviene con la grafica dei videogiochi, no? Perchè mai il motore di Crysis (o qualsiasi altro gioco) si adatterebbe bene all'una o l'altra architettura indipendentemente da come questi fanno il color blending, mentre con le applicazioni professionali la cosa darebbe risultati così differenti?
Usando librerie di funzioni, queste dovrebbero essere ottimizzate per ogni singola architettura.
Ritorniamo comunque alla questione posta precedentemente: quanti, quali e quanto inciderebbe l'uso di operazioni vettoriali rispetto a quelle scalari?
La differenza dovrebbe essere visibile solo per scelte più globali come preferire l'uso della computazione rispetto allo sfruttamento della banda passante, di operazioni di texturing on texture grandi piuttosto che piccole etc... o mi sfugge qualcosa?

al contrario; l'architettura nVidia è molto più complessa proprio a livello di gestione perchè ha, all'interno, molti più circuiti di controllo, di sincronizzazioni dei clock ecc
Le cpu hanno un rapporto tra unità di controllo e gestione ed unità funzionali ancora più sbilanciato (e anche di molto) verso le prime
Non mi sembrano che queste due affermazioni si contraddicano, anzi...
Quello che appare è che nvidia stia facendo una architettura general purpose usando più logica per usare HW "standard" mentre AMD si preoccupa di risolvere i singoli problemi con HW dedicato (tipo la tesselation). Nel primo caso magari si perde in prestazioni ma si guadagna notevolmente in flessibilità (pensiamo al fatto che è possibile modificare gli algoritmi un domani se necessario) mentre AMD ha la possibilità di risolvere il problema ottenendo più prestazioni al costo di aumentare la complessità del singolo HW aggiunto (dubito che il tesselatore super performante che sembra sarà inserito in Cayman avrà le stesse dimensioni e complessità di quello inserito in Cypress).
Nel caso di nvidia la potenza di elaborazione rimane proporzionale alla disponibilità dei suoi stream processors (o GPC) senza interventi ulteriori (togli un GPC hai meno capacità di tesselazone ma hai proporzionalmente anche meno capacità di elaborare i triangoli prodotti quindi tutto è bilanciato) e l'aumento della potenza di una determinata funzionalità non è semplice se non aumentando la disponibilità di tutto l'HW general purpose (più GPC) mentre ATI deve adattare l'HW aggiunto a seconda delle unità "esterne" (un tesselatore uguale a quello di Cayman non avrebbe senso su un chip del livello di Barts e sarebbe inutilmente sovradimensionato quindi richiede la sua riprogettazione).
Oltre al fatto che con un sistema "omogeneo" come quello di nvidia le possibilità di intervento suoi "sottoprodotti" delle varie fasi è più semplice mentre con l'approccio di AMD diventerebbe più complesso gestire l'output dell'HW dedicato verso le unità di elaborazione standard.

Ovviamente dove le unità fixed function fanno la differenza nvidia non ha interesse di farne a meno (facendo la fine di Intel) ma sembra che l'intenzione sia quella di rimuovere quanto più HW con funzionalità dedicate sia possibile. Questo dovrebbe semplificare il flusso operativo delle funzioni eseguite sempre sulle stesse unità, con gli stessi buffer, gli stessi registri etc... dove una logica relativamente complessa possa più facilmente ottimizzare il workflow (come detto stalli e dipendenze in questo caso sono più facilmente prevedibili) ed evitare al massimo le eccezioni favorendo quello che nvidia proclama da tempo: la trasformazione delle GPU in sistemi di calcolo general purpose che includa anche la gestione particolare della grafica 3D.

Premesso che ROPs e TMUs per ora sono irrinunciabili, sarebbe possibile in linea teorica per nvidia sostituire i GPC con unità simili alle SPU del Cell e, prestazioni a parte, non dovrebbe cambiare molto nel flusso dei dati. O sbaglio?

Che si possa fare un SW che va meglio su una architettura e affondi 'altra credo che non vi siano dubbi.
Io parto dal presupposto che ho un problema da risolvere (che so, una convoluzione da eseguire su una immagine molto molto grande). Ora io scrivo l'algoritmo (ed essendo abituato a un codice single task seriale usando linguaggi come il C/C++) cerco di farlo al meglio perchè si adatti alle capacità della GPU (come hai detto tu, single instruction multple data). Mi aspetto che il relativo compilatore ottimizzi al meglio il mio algoritmo (per quanto possibile ovviamente). L'aspetto di come scrivere il codice perché giri meglio su una GPU piuttosto che un'altra per me dovrebbe essere trasparente (così come quando scrivo in C non mi preoccupo sui singoli aspetti della architettura su cui girerà).

tu no, chi scrive SW per professione si. Conosco diversi programmatori che lavorano nel mondo dei VG o della grafica pro e tutti hanno contatti con chi progetta HW e SW. Questi contatti sono finalizzati a spiegare loro come ottimizzare il codice per una determinata architettura piuttosto che per un'altra. E, infatti, i programmatori conoscono abbastanza in dettaglio l'architettura delle gpu


Come non hanno le ROPs o TMUs? Non mi sembra che il GF100 sulle Tesla sia fisicamente differente da quello che viene prodotto per le GTX470. Sarebbe un costo non indifferente avere 2 chip diversi.


sono disabilitate con il laser; si tratta di circuiti che è inutile andare ad alimentare.


Ma sono "semplici" operazioni grafiche non diverse da quello che avviene con la grafica dei videogiochi, no? Perchè mai il motore di Crysis (o qualsiasi altro gioco) si adatterebbe bene all'una o l'altra architettura indipendentemente da come questi fanno il color blending, mentre con le applicazioni professionali la cosa darebbe risultati così differenti?
Usando librerie di funzioni, queste dovrebbero essere ottimizzate per ogni singola architettura.
Ritorniamo comunque alla questione posta precedentemente: quanti, quali e quanto inciderebbe l'uso di operazioni vettoriali rispetto a quelle scalari?
La differenza dovrebbe essere visibile solo per scelte più globali come preferire l'uso della computazione rispetto allo sfruttamento della banda passante, di operazioni di texturing on texture grandi piuttosto che piccole etc... o mi sfugge qualcosa?


anche i giochi non si adattano perfettamente all'una o l'altra architettura. Alcuni vanno meglio su ATi altri su nVidia. Con i programmi di grafica professionale,una delle differenze rispetto ai giochi è che, in molti casi, si usano come api le opengl. Queste librerie sono sviluppate da un consorzio di cui fanno parte anche nvidia è ati è contengono molte istruzioni, una volta di tipo proprietario, ora standardizzati. Ad esempio puoi trovare diverse istruzioni di tipo NVGL o ATIGL. Poiché, come ha scritto prima, i programmi sono sviluppati a stretto contatto di gomito con i progettisti di HW è poiché il mercato, in campo professionale, vede un 80% abbondante di schede grafiche con chip nvidia, è ipotizzabile che nello sviluppare il software si faccia principalmente riferimento all'architettura dei loro chip grafici. Un altro parametro di cui tener conto è che, in campo professionale, può fare la differenza è il quantitativo di ram; le schede grafiche quadro di fascia alta hanno quantitativi di memoria molto elevati mentre le firegl arrivano, al massimo, a 2 GB.
un esempio di quanto detto, nel settore videogiochi, lo ha fornito proprio Carmack con doom3. Il gioco è stato sviluppato usando le opengl, prima in versione standard, poi modificata per mascherare le carenze di nv30. Se ID avesse usato le DX9, non avrebbe ottenuto lo stesso risultato.



Non mi sembrano che queste due affermazioni si contraddicano, anzi...
Quello che appare è che nvidia stia facendo una architettura general purpose usando più logica per usare HW "standard" mentre AMD si preoccupa di risolvere i singoli problemi con HW dedicato (tipo la tesselation). Nel primo caso magari si perde in prestazioni ma si guadagna notevolmente in flessibilità (pensiamo al fatto che è possibile modificare gli algoritmi un domani se necessario) mentre AMD ha la possibilità di risolvere il problema ottenendo più prestazioni al costo di aumentare la complessità del singolo HW aggiunto (dubito che il tesselatore super performante che sembra sarà inserito in Cayman avrà le stesse dimensioni e complessità di quello inserito in Cypress).
Nel caso di nvidia la potenza di elaborazione rimane proporzionale alla disponibilità dei suoi stream processors (o GPC) senza interventi ulteriori (togli un GPC hai meno capacità di tesselazone ma hai proporzionalmente anche meno capacità di elaborare i triangoli prodotti quindi tutto è bilanciato) e l'aumento della potenza di una determinata funzionalità non è semplice se non aumentando la disponibilità di tutto l'HW general purpose (più GPC) mentre ATI deve adattare l'HW aggiunto a seconda delle unità "esterne" (un tesselatore uguale a quello di Cayman non avrebbe senso su un chip del livello di Barts e sarebbe inutilmente sovradimensionato quindi richiede la sua riprogettazione).


in realtà l'unica unità funzionale dedicata in più presente nei chip ati rispetto quelli nvidia è proprio il tessellator. Per il resto non si può neppure parlare di unità generiche vs unità dedicate. Questo discorso si sarebbe potuto fare se si fosse paragonato un chip grafico di quelli attuali con larrabee. in questo caso invece si ha a che fare con un blocco di unità programmabili, ossia lo shader core e una serie di blocchi di tipo fixed function. Il diverso approccio per l'unità di tessellation porta da un lato ad avere dell'hardware dedicato che sgrava lo shader core da parte del carico di lavoro ma che può, passando chip di fascia più bassa, risultare sovradimensionato. Dall'altra dell'hardware di tipo generico che si occupa anche delle operazioni di hull e domain shading. Questo significa che, scalando verso il basso, sia un maggior bilanciamento tra i vari blocchi di unità. L'aspetto negativo è che lo shader core deve sobbarcarsi un lavoro extra.
In quanto alla flessibilità, c'è da fare un distinguo. Un chip la cui gestione è affidata prevalentemente all'hardware ha più difficoltà ad adattarsi nel momento in cui si ha un'evoluzione delle librerie di riferimento. D'altra parte, è altrettanto vero che avere più unità dedicate a rende più difficile l'adattabilità al cambiamento di api. Nel caso specifico, da un lato l'ottimizzazione dei chip ati è più dipendente da software, dall'altro hanno qualche unità funzionale dedicata in più. Quale dei due aspetti peserà maggiormente quando si avranno nuove librerie di riferimento è molto difficile da stabilirlo oggi.
Di sicuro si può affermare che da un lato abbiamo unità funzionali in grado di eseguire gli stessi compiti in un numero inferiore di cicli, mentre dall'altro abbiamo un'architettura che risente meno, soprattutto in negativo, delle ottimizzazioni del software. Nel complesso si può affermare che nei chip ati si ha una maggiore efficienza dei singoli blocchi, mentre nei chip nvidia una maggiore efficienza a livello di architettura complessiva.


Oltre al fatto che con un sistema "omogeneo" come quello di nvidia le possibilità di intervento suoi "sottoprodotti" delle varie fasi è più semplice mentre con l'approccio di AMD diventerebbe più complesso gestire l'output dell'HW dedicato verso le unità di elaborazione standard.


da questo punto di vista non c'è alcuna differenza. Anzi, la presenza di unità dedicate sovradimensionate, garantisce la sicura eliminazione di un collo di bottiglia anche se accosto di una maggior superficie del chip. Tra uno stadio e l'altro esistono, in ogni caso, sistemi di cache e buffer atti ad annullare o ridurre le latenze introdotte da stadi di elaborazione che possono lavorare a velocità differenti.


Ovviamente dove le unità fixed function fanno la differenza nvidia non ha interesse di farne a meno (facendo la fine di Intel) ma sembra che l'intenzione sia quella di rimuovere quanto più HW con funzionalità dedicate sia possibile. Questo dovrebbe semplificare il flusso operativo delle funzioni eseguite sempre sulle stesse unità, con gli stessi buffer, gli stessi registri etc... dove una logica relativamente complessa possa più facilmente ottimizzare il workflow (come detto stalli e dipendenze in questo caso sono più facilmente prevedibili) ed evitare al massimo le eccezioni favorendo quello che nvidia proclama da tempo: la trasformazione delle GPU in sistemi di calcolo general purpose che includa anche la gestione particolare della grafica 3D.


se prendi l'esempio della tessellator, il percorso è, in ogni caso, lo stesso. In fermi i dati geometrici in ingresso passano attraverso i VS, quindi sono elaborati dagli HS (la cui funzione è svolta sempre dai VS), poi passano all'unità di tessellation che è di tipo fixed function ed è all'interno del polymorph engine. quindi passano ai DS, cioè tornano nello shader core e infine nei GS. Nei chip amd, i dati entrano nei VS, quindi all'interno dello shader core, poi passano agli HS che sono unità dedicate fuori dallo shader core; da lì proseguono verso il tessellator e quindi verso i DS. il percorso attraverso queste tre unità è del tutto lineare ed avviene al di fuori dello shader core. Al termine, tornano verso lo shader core per essere elaborati dai GS.
Come vedi in entrambi i casi il percorso che compiono i dati da e verso lo shader core è lo stesso. Quello che cambia è che in fermi questo avviene durante l'operazione di tessellation, mentre in cypress all'inizio e alla fine della stessa.


Premesso che ROPs e TMUs per ora sono irrinunciabili, sarebbe possibile in linea teorica per nvidia sostituire i GPC con unità simili alle SPU del Cell e, prestazioni a parte, non dovrebbe cambiare molto nel flusso dei dati. O sbaglio?

non avrebbe nessun vantaggio nel farlo per diverse ragioni. La prima è che neppure i SPE del cell sono unità di tipo general purpose. La seconda è che i SPE sono in order e single threaded. Questo li rende del tutto inadatti a svolgere funzioni da chip grafico che non si limitino ad operazioni di post processing è relative all'illuminazione. Il cell stesso non è una cpu di tipo general purpose. Imoltre, le SPE del cell hanno alu vect4.
La gestione dei dati è molto simile in quanto si tratta sempre di sistemi multiprocessore.

E, infatti, i programmatori conoscono abbastanza in dettaglio l'architettura delle gpu/quote]
e questo sicuramente è necessario. Ma alla fine lo sfruttamento di tali GPU si avvale dell'uso di librarie che ogni casa ottimizza personalmente per la propria architettura, no?
Cioè, se devo creare e riempire dei triangoli userò le funzioni delle librerie OpenGL? Ovviamente le implementazioni di queste librarie saranno completamente differenti, ma dovrebbero essere fatte per usare il 100% delle potenzialità delle GPU.

I motori dei videogiochi funzionano meglio su una o l'altra architettura, ma alla fine le differenze non sono così enormi come nel campo professionale. Pochi punti percentuali.

[quote]se prendi l'esempio della tessellator, il percorso è, in ogni caso, lo stesso.
mmm.... se non erro però nvidia non è costretta alla serializzazione totale della funzionalità di tesselation dal momento che i dati sono trattati localmente nei vari GPC dove possono girare più thread contemporaneamente, mentre ATI che ha il tesselizzatore unico esterno è costretta prima a calcolarsi tutti i punti/triangoli, metterli nei buffer e poi a distribuirli agli shaders a valle di tutta la procedura di tesselizzazione. E' una procedura che non usa lo stesso workflow delle altre, mi sembra.

La prima è che neppure i SPE del cell sono unità di tipo general purpose.
Ho detto SPE del cell solo come esempio, non necessariamente con le stesse funzionalità. Quello che intendevo era una unità semi-specializzata (ovviamente non ha senso avere una unità general purpose che possa anche gestire un OS con tutta la complessità architetturale del questo caso, al max si potrebbe pensare ad un sistema tipo Cell con una unità General Purpose di gestione esterna alle unità di elaborazione vere e proprie) diversa dal GPC così come è formato ora.
Mettiamo anche una SPE con molteplici unità di calcolo vettoriale vect4 generiche, mentre il resto delle istruzioni viene eseguita da una unità centrale di questo GPC in modo che il codice possa essere meno SIMD. Quanto cambierebbe dell'architettura esterna?
Quello che intendo è, quanto è possibile che un domani questa architettura completamente inefficiente a gestire codice generico possa invece essere trasformata in qualcosa che sia quasi indipendente dalla CPU dalla quale potrebbe ricevere giusto un blocco di codice da eseguire poi in maniera del tutto autonoma?
Oggi, a quanto sembra, che fa da collo di bottiglia è proprio la comunicazione tra GPU e CPU.
L'esempio dell'architettura del Cell però è illuminante proprio per la capacità di rendere indipendenti le sotto unità. Potrebbe essere applicata a più livelli all'interno della GPU (o delle molteplici GPU) in modo da scalare linearmente?
Esempio: una CPU general purpose che gestisce un numero variabile di GPC, le quali a loro volta hanno una unità general purpose che gestisce unità di calcolo più specializzate (magari diverse tra di loro)?
Fermo restando che ROPs e TMUs sarebbero sempre lì magari proprio come unità SPE particolari.

Scusa, ho sbagliato a creare il primo quote.

e questo sicuramente è necessario. Ma alla fine lo sfruttamento di tali GPU si avvale dell'uso di librarie che ogni casa ottimizza personalmente per la propria architettura, no?
Cioè, se devo creare e riempire dei triangoli userò le funzioni delle librerie OpenGL? Ovviamente le implementazioni di queste librarie saranno completamente differenti, ma dovrebbero essere fatte per usare il 100% delle potenzialità delle GPU.


parti dal principio che non riuscirai mai a sfruttare al 100% un'architettura (qualunque essa sia). In secondo luogo, se hai un'applicazione pensate per un workflow di tipo seriale, riuscire ad ottimizzarla su un'architettura il cui funzionamento ottimale lo si ha quando un thread prevede il ricorso a tante operazioni in parallelo risulterà sempre penalizzata e, in quel caso, non c'è driver che tenga. Infine, faccio una considerazione partendo dalle due architetture. In entrambe, ogni singola alu si occupa di un thread. La differenza sta nel fatto che una alu di un chip ati è composta da più "vie". Fai conto che un thread sia composto da 8 istruzioni, tutte indipendenti tra loro o, almeno, tali che si possano raggruppare ad esempio in due gruppi di 5 e 3 istruzioni indipendenti. Su un chip con alu 5-way vliw avrai un primo ciclo in cui passa l'intero gruppo da 5 istruzioni e un secondo ciclo in cui hai il gruppo da 3 istruzioni e 2 NOP per quelle che restano inattive (non operation), poichè tutte le vie devono avere una istruzione (e la NOP è un'istruzione che lascia in idle l'unità). Su un chip nvidia, lo stesso thread impiegherà 8 cicli ad essere portato a termine. Questo è un chiaro esempio in cui ati è in netto vantaggio. Se, però, le 8 istruzioni non sono indipendenti o lo sono in minima parte, allora anche la alu del chip ati dovrà compiere più cicli per portarlo a termine. Se, ad esempio (caso estremo in negativo) non esistono 2 istruzioni indipendenti tra le 8, anche l'alu vliw avrà bisogno di 8 cicli (e 32 NOP :D ) per completare il thread. In questo caso, ad essere in netto vantaggio è nvidia. Nel primo caso, il chjip nvidia è sicuramente meno efficiente ma ha, comunque, le alu occupate per la maggior parte del tempo (anche se necessitano di più cicli). Nel secondo caso, il chip ati ha anch'esso le alu occupate per la maggior parte del tempo, ma ad 1/5 della loro velocità teorica possibile. Nel primo caso, a livello di driver, puoi tentare di gestire gli accessi alla memoria (anche li nvidia preferisce l'approccio seriale), nel secondo caso puoi fare altrettanto per gli accessi alla memoria ma non per il fatto che hai buona parte delle unità funzionali in idle.




mmm.... se non erro però nvidia non è costretta alla serializzazione totale della funzionalità di tesselation dal momento che i dati sono trattati localmente nei vari GPC dove possono girare più thread contemporaneamente, mentre ATI che ha il tesselizzatore unico esterno è costretta prima a calcolarsi tutti i punti/triangoli, metterli nei buffer e poi a distribuirli agli shaders a valle di tutta la procedura di tesselizzazione. E' una procedura che non usa lo stesso workflow delle altre, mi sembra.


I passaggi da un'unità all'altra non sono istantanei ma richiedono sempre lo stazionamento all'interno di un registro o di un buffer, soprattutto quando si passa da uno stadio al'altro. Nel caso di nvidia, una volta passati attraverso il triangle setup engine, i vertici entrano nello shader core dove vengono eseguite, dai vertex shader, operazioni come il cambio di coordinate, la trasformazione da object space a world space ecc; quindi restano all'interno dello shader core per essere processati dagli HS. Dopo di che, le coordinate dei control point ricavati, soon inviate al tessllator (nel polymorph engine) che si occupa di eseguire la vera e propria tessellation.I valori ottenuti passano di nuovo nello shader core, ai domain shader che hanno, nel frattempo, ricevuto informazioni sul tipo di patch da applicare. Questo perchè l'output degli HS è di 2 tipi: fixed function (coordinate dei control point da fornire al tessellator) e programmabile (informazioni sul tipo di curva, fa passare direttamente ai domain shader). L'unica reale differenza nel workflow è che in fermi, poichè HS e DS sono eseguiti nello shader core, ad essere esportati sono solo i control point; in cypress, invece, sono esportate anche le informazioni relative alla curva. Poi, ovviamente, c'è da aggiungere che in fermi si hanno 4 flussi in ingresso dalla vertex cache al triangle setup engine e n flussi 8fino a 16) in parallelo da e verso il poymorph engine. Il primo costituisce un vantaggio di gran lunga superiore al secondo. Un rovescio della medaglia, però, esiste. Ogni SM ha 32 alu divise in 2 gruppi da 16 con un warp scheduler ciascuno. Questo significa che ogni gruppo di 16 alu può eseguire un solo tipo di istruzione per ciclo (anche se può averne di più tipi diversi contemporaneamente in circolo (come in tutte le gpu :D ); ovvero, se stanno facendo vertex shading non possono fare hull shading nello stesso ciclo e, durante un'elaborazione, solo relativamente alle operazioni geometriche, si può fare VS, HS, DS e GS. Avere unità dedicate alla seconda e terza di queste operazioni, permette di scaricare il 50% dei carichi di lavoro dallo shader core. Insomma, è la riproposizione in chiave tecnologica della coperta corta :D
Sicuramente un vantaggio, invece, la possibilità di avere 4 raster engine di classe dx10 (da 16 vertici ciascuno) ocntro uno di classe dx10.1/dx11 (da 32 vertici) di cypress. In questo modo, raddoppiano rispetto alla concorrenza (lo quadruplicano rispetto ai chip dx10 e dx9), il numero di coordinate geometriche che, ad ogni ciclo, si possono caricare sulla gpu.
Direi che la possibilità di lavorare n parallelo dia più vantaggio in questo campo che non nelle operazioni di tessellation.


Ho detto SPE del cell solo come esempio, non necessariamente con le stesse funzionalità. Quello che intendevo era una unità semi-specializzata (ovviamente non ha senso avere una unità general purpose che possa anche gestire un OS con tutta la complessità architetturale del questo caso, al max si potrebbe pensare ad un sistema tipo Cell con una unità General Purpose di gestione esterna alle unità di elaborazione vere e proprie) diversa dal GPC così come è formato ora.


intendi una sorta di SoC (system on chip) di tipo asimmetrico con processori di diverso tipo e con compiti differenti nello stesso die (il cell ha un PPE di tipo GP e 8 SPE assimilabili a dei DSP e, comunque, di tipo special purpose)? E' fattibile, ma se rinunci al SIMD perdi capacità di calcolo (anche i SPE sono SIMD). Il vantaggio della SIMD è proprio nel fatto che con ogni istruzione puoi far eseguire decine o centinaia di operazioni in parallelo. All'opposto, un modello architetturale MIMD come le cpu, è più flessibile ma enormemente meno potente; in quel caso dovresti replicare la logica di controllo presente in ogni SIMD, per ogni singola alu, il che significherebbe tanbto spazio sul die da dedicarle. In una gpu le unità funzionali occupano buona parte della superficie del chip, in una cpu una parte piccolissima.




Mettiamo anche una SPE con molteplici unità di calcolo vettoriale vect4 generiche, mentre il resto delle istruzioni viene eseguita da una unità centrale di questo GPC in modo che il codice possa essere meno SIMD. Quanto cambierebbe dell'architettura esterna?


tutto; stai proponendo un'architettura tipo quella di amd con un thread processor che gestisce unità SIMD assimilabili ad unità vettoriali. Al contrario, nVidia ha un TP con unità scalari all'interno di un SIMD. Al limite, si potrebbe pensare di ridurre ulteriormente la granularità dei SIMD, magari passando a 8 alu per cluster. In quel caso, però, il problema si sposterebbe sulla complessità del bus che dovrebbe mettere in comunicazione 128 cluster di tipo SIMD (mantenendo sempre 512 alu con in gf1x0), Senza contare che la complessità dei circuiti logici, di controllo, di sincronizzazione, rispetto al caso di 16 SIMD, aumenterebbe di almeno un fattore 8: tanto spazio n meno per le unità funzionali o, volendo mantenere lo stesso numero di alu, die molto più grande (ora hai capito perchè i chip nvidia sono delle mattonelle ma, se non si fosse cercato un compromesso, sarebbero potuti essere ancora più grandi?). La scelta è tra flessibilità e potenza di calcolo e non è affatto semplice

Ti ringrazio per le delucidazioni ai punti precedenti.

Il vantaggio della SIMD è proprio nel fatto che con ogni istruzione puoi far eseguire decine o centinaia di operazioni in parallelo.
Si, ma ha l'immenso svantaggio che non ha la flessibilità di una pipeline come quelle di una "CPU normale".

stai proponendo un'architettura tipo quella di amd con un thread processor che gestisce unità SIMD assimilabili ad unità vettoriali
Sì e no. Una architettura dove le unità di calcolo non sono esattamente tutte uguali ma sono gestite localmente da una logica simil-CPU. In soldoni una serie di Cell dove ogni GPC è un simil-Cell formato da una unità di controllo super flessibile (ma poco efficiente e fare i conti) e una schiera di SPE specializzate anche diverse tra loro che eseguono i calcoli. Più complesse però degli attuali shader. Ognuna con una piccola memoria locale e indipendente dalle altre (ogni unità può, anche se non necessariamente, eseguire una serie di istruzioni diverse, quindi una architettura non più strettamente SIMD).
A monte di questa mostruosità una qualsiasi architettura CPU-like che gestisca i thread da inviare ai singoli GPC. Credo che così si avrebbe una architettura localmente super veloce (tutti i dati starebbero nella SPE o nel GPC per molto più tempo dato che l'unità è in grado di fare molti più calcoli indipendenti prima di restituire il risultato ad un buffer globale).
Quello che ipotizzo è una architettura realizzabile da IBM (o Intel, o Toshiba o STM o ARM o chiunque altro sappia fare delle unità di calcolo MIMD efficienti) che sia diversa da quelle ora esistenti ma che potrebbe realmente garantire una potenza di calcolo enorme insieme a una sufficiente flessibilità di programmazione.
Considerando che tutto completo il Cell ha qualcosa come 300milioni di transistor, un Fermi potrebbe contenerne 10 di queste unità (più o meno). In puro calcolo teoricamente il Cell (8i, revisione di IBM) è in grado di eseguire più di 100GFlops in DP (contro i 12 della versione Sony nella PS3). Moltiplicando per 10 e dividendo per 2 per tenere conto della diversa frequenza a cui girerebbe sarebbero circa 500GFlops teorici, che per una architettura simile risultano anche quasi reali (vedere l'efficienza del Cell con il benchmark Linpack). I numeri sono spannometrici ma dovrebbero dare un'idea della possibilità delle capacità di calcolo ottenibili anche con una architettura non SIMD.

Ti ringrazio per le delucidazioni ai punti precedenti.


figurati :)





Si, ma ha l'immenso svantaggio che non ha la flessibilità di una pipeline come quelle di una "CPU normale".



vero, infatti una cpu, ad esempio x86, è un chip di tipo general purpose mentre una gpu non lo è. D'altra parte, il modello di programmazione è del tutto differente: le cpu privilegiano il multitasking le gpu il multithreading (le prime hanno poche unità che lavorano su ciascun task e, di conseguenza, la loro capacità di eseguire velocemente calcoli in parallelo è molto limitata ma hanno il vantaggio di poter lavorare con più applicazioni in contemporanea; le seconde, al contrario, lavorano su una sola applicazione o su un numero molto limitato di applicazioni ma hanno la capacità di eseguire tanti calcoli in parallelo). Le cpu hanno un modello di programmazione che, proprio per la loro ridotta capacità di eseguire più thread in parallelo ,si preoccupa di nascondere le latenze (2 o 3 livelli di cache interne molto più ampie di quelle della gpu) mentre le gpu hanno un modello di calcolo che prevede la possibilità di mascherare le latenze grazie alla possibilità di eseguire tanti thread in contemporanea. Se ti avvicini ad uno dei due modelli, sei costretto ad allontanarti necessariamente dall'altro (non puoi avere una cpu con la capacità di calcolo di una gpu a meno che non ritieni accettabile avere chip delle dimensioni di una piastrella 20x20, per lo più occupati da circuiti logici e da cache :D



Sì e no. Una architettura dove le unità di calcolo non sono esattamente tutte uguali ma sono gestite localmente da una logica simil-CPU. In soldoni una serie di Cell dove ogni GPC è un simil-Cell formato da una unità di controllo super flessibile (ma poco efficiente e fare i conti) e una schiera di SPE specializzate anche diverse tra loro che eseguono i calcoli. Più complesse però degli attuali shader. Ognuna con una piccola memoria locale e indipendente dalle altre (ogni unità può, anche se non necessariamente, eseguire una serie di istruzioni diverse, quindi una architettura non più strettamente SIMD).
A monte di questa mostruosità una qualsiasi architettura CPU-like che gestisca i thread da inviare ai singoli GPC. Credo che così si avrebbe una architettura localmente super veloce (tutti i dati starebbero nella SPE o nel GPC per molto più tempo dato che l'unità è in grado di fare molti più calcoli indipendenti prima di restituire il risultato ad un buffer globale).
Quello che ipotizzo è una architettura realizzabile da IBM (o Intel, o Toshiba o STM o ARM o chiunque altro sappia fare delle unità di calcolo MIMD efficienti) che sia diversa da quelle ora esistenti ma che potrebbe realmente garantire una potenza di calcolo enorme insieme a una sufficiente flessibilità di programmazione.
Considerando che tutto completo il Cell ha qualcosa come 300milioni di transistor, un Fermi potrebbe contenerne 10 di queste unità (più o meno). In puro calcolo teoricamente il Cell (8i, revisione di IBM) è in grado di eseguire più di 100GFlops in DP (contro i 12 della versione Sony nella PS3). Moltiplicando per 10 e dividendo per 2 per tenere conto della diversa frequenza a cui girerebbe sarebbero circa 500GFlops teorici, che per una architettura simile risultano anche quasi reali (vedere l'efficienza del Cell con il benchmark Linpack). I numeri sono spannometrici ma dovrebbero dare un'idea della possibilità delle capacità di calcolo ottenibili anche con una architettura non SIMD.

intel, con larrabee, voleva realizzare qualcosa del genere (e il progetto terascale prevede chip composti da più unità interne ognuna assimilabile ad una cpu con una o più pipeline scalari di tipo x86 e una unità SIMD. La differenza è che nel progetto larrabee (ma, da quello che so, anche nei chip della famiglia terascale in generale) non si ha un'unità che gestisce il funzionamento delle varie cpu, ma il tutto è ottimizzato dal compilatore. Però considera che nè la famiglia terascale, né larrabee, nè lo stesso cell, sono cpu di tipo GP. Innanzitutto nascono come cpu e, di conseguenza, non hanno la stessa capacità di multithreading delle gpu; in secondo luogo sono di tipo in order, il che le rende molto più semplici a livello circuitale. L?aspetto negativo è che non le rende particolarmente flessibili. Il progetto terascale, infatti, è indirizzato al calcolo scientifico e non a sostituire cpu di tipo consumer e lo stesso cell non lo vedrai mai su un pc.
Dal canto suo, nVidia ha esperienza di gpu e parte da ciò che sa fare meglio. se punta al gpgpu, allora, per forza di cose, finirà con l'abbandonare il mercato dei chip grafici (tesla è un adattamento di un'architettura nata per fare grafica e si troverebbe a competere con chip progettati esclusivamente per il calcolo scientifico). Al momento non può farlo in ogni caso, perchè il suo mercato di gran lunga più redditizio è sempre quello dei chip grafici (geforce in primo luogo ma anche quadro). Solo che questo mercato è a rischio, soprattutto nel segmento consumer di fascia media e bassa, a causa delle soluzioni integrate cpu+gpu. Per questo sta spingendo perchè prenda piede il gpgpu e la contrapposizione non è tanto con le firestream di amd (che anzi potrebbero potenziali alleate) quanto con soluzioni tipo knight ferry di intel o con fusion nel momento in cui amd deciderà di utilizzare SoC cpu+gpu per il calcolo scientifico.
D'altro canto, le spese di R&D per due chip diversi, entrambi di fascia alta, uno per la grafica ed uno per il gpgpu, sarebbero insostenibili. Al momento, neppure intel si può permettere di portare avanti una cosa del genere