Jump to content
papafoxtrot

Elaborazioni Gp-gpu

Recommended Posts

No, no, non fraintendiamo, il compilatore rilasciato assieme a CUDA Toolkit è il compilatore che ti serve per scrivere un programmino C che usa CUDA, è utile se non hai visual studio o non vuoi usare il compilatore GNU (che è molto più grosso e completo).

Il programma CUDA vero e proprio (il kernel) viene compilato da un compilatore interno alla libreria, funziona ne più ne meno come si compila una shader in openGL.

Carichi il codice del sorgente, lo passi alla funzione della libreria che lo compila e questa ritorna un oggetto che puoi eseguire.

Stessa cosa fa openCL.

In tutto questo pappiello lunghissimo non ho mai detto di essere un grosso fan di CUDA, e penso pure io che andrà a sparire se non verrà implementato almeno in maniera parziale anche su ATI. L'ho scritto nel messaggio che non hai finto di leggere. :D

Anche se penso sia una possibilità molto remota, lo dimostra questo piccolo evento:

La gente scopre che mettendo una ATI per la grafica e una GeForce per la fisica si ottengono cose mirabolanti.

nVidia disabilita l'accelerazione HW nel caso sia presente una ATI adducendo motivazioni discutibili.

-_-

Per il discorso della libreria sì, libreria no. Una libreria è un pezzo di codice messo da qualche parte che il tuo programma usa. Con questa definizione ogni pezzo di codice sul computer è una libreria. Il pezzo di codice che un programma usa per usare openGL risiede principalmente nel driver, per questo openGL non viene inteso come una libreria. Il pezzo di codice che linki non fa altro che da ponte per le openGL vere.

Ci sono cascato pure io la prima volta, openGL è una "libreria" molto anomala.

Da wikipedia:

"OpenGL (Open Graphics Library) è una specifica che definisce una API per più linguaggi e per più piattaforme per scrivere applicazioni che producono computer grafica 2D e 3D."

Comunque alla fine è soltanto un tecnicismo, chiamala pure libreria se vuoi, il 99% della gente non troverà niente da ridire. :)

CUDA e openCL sono librerie a tutti gli effetti anche se usano pesantemente il driver, ma il discorso è ben diverso.

Da wikipedia:

"OpenCL (Open Computing Language) è una libreria basata sul linguaggio di programmazione C99"

La confusione che stai facendo tra linguaggio/compilatore/libreria ecc.. è che in realtà openCL è una specifica, cioè se tu che produci delle schede e vuoi dire che supportano openCL allora assieme alla tua scheda devi rilasciare una libreria che supporta un set di istruzioni (per caricare dati, compilare il kernel e bla bla bla) e deve compilare un programma secondo determinare regole. Cioè si deve attenere alle specifiche rilasciate da Khronos. Tra le altre cose si paga 10.000$ se vuoi il certificato di Khronos e se vuoi usare il nome openCL.

openCL non è una libreria che scarichi, ma un insieme di regole (se vai sul sito della khronos non ci sono librerie, solo un PDF e degli header). Sì puoi scaricare una libreria che ti permette di fare programmi che usano openCL ma non è quello openCL, di librerie simili ne puoi trovare più di una.

CUDA non è una specifica, o meglio ha la sua specifica ma è fatta solo da nVidia e un altro anche volendo non può rilasciare una libreria che prende un kernel scritto in CUDA e lo esegue su HW. Ci sarebbero sia ripercussioni legali e poi se vuoi mantenere la compatibilità il tuo HW sarebbe irrimediabilmente legato alle decisioni di nVidia.

Share this post


Link to post
Share on other sites
No, no, non fraintendiamo, il compilatore rilasciato assieme a CUDA Toolkit è il compilatore che ti serve per scrivere un programmino C che usa CUDA, è utile se non hai visual studio o non vuoi usare il compilatore GNU (che è molto più grosso e completo).

Il programma CUDA vero e proprio (il kernel) viene compilato da un compilatore interno alla libreria, funziona ne più ne meno come si compila una shader in openGL.

Carichi il codice del sorgente, lo passi alla funzione della libreria che lo compila e questa ritorna un oggetto che puoi eseguire.

Stessa cosa fa openCL.

Intanto ti ringrazio per le info che dai, se hai fatto caso non èc he siamo qui da giugno a scrivere su CUDA e openCL...questo thread è più una raccolta di link...

In tutto questo pappiello lunghissimo non ho mai detto di essere un grosso fan di CUDA, e penso pure io che andrà a sparire se non verrà implementato almeno in maniera parziale anche su ATI. L'ho scritto nel messaggio che non hai finto di leggere. :D

Anche se penso sia una possibilità molto remota, lo dimostra questo piccolo evento:

La gente scopre che mettendo una ATI per la grafica e una GeForce per la fisica si ottengono cose mirabolanti.

nVidia disabilita l'accelerazione HW nel caso sia presente una ATI adducendo motivazioni discutibili.

-_-

Non è che non ho finito di leggere... è che sto dicendo il contrario di ciò che dici tu... io non credo che cuda sparirà...Che io sappia si può programmare in cuda usando openCL dunque scrivendo software compatibile con tutte le schede (e le cpu) che supportino openCL, non cuda.

I link che dai invece non riguardano cuda, ma bensì physX... E' physX che è una libreria compatibile solo con le schede nvidia, e dunque il codice scritto usando physX può essere eseguito solo da vga nvidia.

Dopodiché certo, windows 7 consentiva di installare due schede video con driver diversi, e siccome era diventato possibile usare una ati per giocare e una nvidia per la fisica, Nvidia ha pensato bene di togliere il supporto a physX per le schede video qualora la scheda usata per il video sia una ATI...

COsì da una parte cercano di proteggere la loro produzione, vantando cartatteristiche superiori grazie al supporto a physX esclusivo.

Dall'altra secondo me perdono una possibilità di infilare PhysX nei giochi, perché finché non sarà fruibile su tutte le macchine le software houses non rinunceranno alla fetta di utenti con vga ati, per altro in aumento...

Per il discorso della libreria sì, libreria no. Una libreria è un pezzo di codice messo da qualche parte che il tuo programma usa. Con questa definizione ogni pezzo di codice sul computer è una libreria. Il pezzo di codice che un programma usa per usare openGL risiede principalmente nel driver, per questo openGL non viene inteso come una libreria. Il pezzo di codice che linki non fa altro che da ponte per le openGL vere.

Ci sono cascato pure io la prima volta, openGL è una "libreria" molto anomala.

Da wikipedia:

"OpenGL (Open Graphics Library) è una specifica che definisce una API per più linguaggi e per più piattaforme per scrivere applicazioni che producono computer grafica 2D e 3D."

Comunque alla fine è soltanto un tecnicismo, chiamala pure libreria se vuoi, il 99% della gente non troverà niente da ridire. :)

CUDA e openCL sono librerie a tutti gli effetti anche se usano pesantemente il driver, ma il discorso è ben diverso.

Da wikipedia:

"OpenCL (Open Computing Language) è una libreria basata sul linguaggio di programmazione C99"

La confusione che stai facendo tra linguaggio/compilatore/libreria ecc.. è che in realtà openCL è una specifica, cioè se tu che produci delle schede e vuoi dire che supportano openCL allora assieme alla tua scheda devi rilasciare una libreria che supporta un set di istruzioni (per caricare dati, compilare il kernel e bla bla bla) e deve compilare un programma secondo determinare regole. Cioè si deve attenere alle specifiche rilasciate da Khronos. Tra le altre cose si paga 10.000$ se vuoi il certificato di Khronos e se vuoi usare il nome openCL.

openCL non è una libreria che scarichi, ma un insieme di regole (se vai sul sito della khronos non ci sono librerie, solo un PDF e degli header). Sì puoi scaricare una libreria che ti permette di fare programmi che usano openCL ma non è quello openCL, di librerie simili ne puoi trovare più di una.

CUDA non è una specifica, o meglio ha la sua specifica ma è fatta solo da nVidia e un altro anche volendo non può rilasciare una libreria che prende un kernel scritto in CUDA e lo esegue su HW. Ci sarebbero sia ripercussioni legali e poi se vuoi mantenere la compatibilità il tuo HW sarebbe irrimediabilmente legato alle decisioni di nVidia.

Ok credo di aver inteso la differenza. Ma ad ogni modo, con openCL posso usare compilatori diversi o sbaglio?


Edited by papafoxtrot

Share this post


Link to post
Share on other sites
Ok credo di aver inteso la differenza. Ma ad ogni modo, con openCL posso usare compilatori diversi o sbaglio?

openCL come ti ho detto ha il suo compilatore interno per compilare il kernel e quello non lo puoi cambiare. Poi per produrre programmi che usano openCL puoi usare qualsiasi compilatore (Visual studio, G++, ecc...). Tra le altre cose ancora prima che uscissero le SDK pubbliche di nVidia erano già stati fatti diversi porting verso altri linguaggi (Java, Phyton, Scala, ecc...).

Mi sembra di essere ripetitivo, ma la stessa cosa era stata fatta anche per CUDA.

Share this post


Link to post
Share on other sites

Occapito.

Ma allora com'è che nvidia parlava di implementare le openCL tramite cuda? Non intende dire che si può scrivere codice in cuda che usi openCL? Ci vuole comunque un ambiente a parte?

O non è possibile e non ci ho capito nulla/era una sparata?

Share this post


Link to post
Share on other sites
Occapito.

Ma allora com'è che nvidia parlava di implementare le openCL tramite cuda? Non intende dire che si può scrivere codice in cuda che usi openCL? Ci vuole comunque un ambiente a parte?

O non è possibile e non ci ho capito nulla/era una sparata?

Le istruzioni assembler delle schede video nVidia sono le stesse sia se stai usando CUDA, sia se stai usando openCL. Quando la libreria openCL chiede al driver nVidia di compilare il kernel questo usa un metalinguaggio intermedio e poi converte tutto in assembly.

Questo linguaggio intermedio dovrebbe essere comune sia a CUDA che openCL.

Se ti interessa il metalinguaggio si chiama LLVM, è usato un po' ovunque, per esempio viene usato da apple per compilare l'object C in codice per l'iPhone.

Presumo che il procedimento debba essere grosso modo così:

La libreria openCL chiede al driver di compilare il programma, questo viene tradotto in LLVM e il compilatore LLVM integrato nel driver lo traduce in codice macchina.

Anche CUDA quando deve tradurre il kernel traduce il programma in LLVM, da li in poi il percorso è comune.

Cerca nVidia in questa pagina.

http://llvm.org/Users.html

Share this post


Link to post
Share on other sites

Dipende da come si evolve, altrimenti si rischia di fare la fine di quelli che a fine anni '80dicevano che AMIGA avrebbe dominato il mercato dei computer. :D

In tutto lo scenario avete trascurato DirectX 11 che include i Compute shader.

Da una parte c'è nVidia che investe sul calcolo parallelo su GPU. non bisogna trascurare che nVidia ha dalla sua mental ray, quindi penso che nel ambito del 3D cinematografico sentiremo parlare sempre più di nVidia, CUDA e iRay.

Da un altra parte abbiamo Microsoft e DirectX11 e la quasi totalità del mercato dei video giochi (a parte ID software e altri temerari) lo useranno per i prossimi videogame, quindi Compute shader avranno una grossa fetta del mercato.

openCL... per adesso abbiamo parlato sempre di 3D e calcoli scientifici, ma l'accelerazione hardware può essere usata anche per molte altre cose. Un campo in cui sembra interessante l'uso delle GPU sono i database, se questa cosa si evolve openCL la farà quasi sicuramente da padrone.

La situazione per adesso è ancora troppo caotica per fare previsioni e ho la sfera di cristallo dal meccanico.

Share this post


Link to post
Share on other sites

Beh, il directx computing lo abbiamo trascurato semplicemente per via del fatto che probabilmente si affermerà, ma solo in ambito videoludico. Perché ad esempio non è cross-platform...

Per quanto riguarda mental ray... si nvidia lo ha dalla sua parte, ma io credo che alla fine sarà preferita la possibilità di farlo girare su tutti i computer, in vista anche di eventuali schede video larrabee, che non supporteranno di certo cuda.

Insomma cuda sarebbe la via più facile per nvidia per implementare mental ray, ma potrebbe limitare l'0adozione del prodotto...

Sui database te credo! :D Le query sono certamente procedure molto molto parallelizzabili!


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

MENTAL RAY 3.8 E IRAY

Come avrete saputo da questa news , che risale ormai a ottobre 2009, mental images, da alcuni anni di proprietà di NVIDIA, si appresta a presentare la nuova versione 3.8 del motore di render Mental ray.

Mental ray 3,8 sarà disponibile a partire dal 31 gennaio 2010 e la maggiore novità che porterà sarà probabilmente il supporto al render su scheda video, ottenuto tramite l'engine interno Iray.

Iray è un motore di render ray tracing in grado di eseguire una simulazione fisicamente corretta della luce sviluppato attraverso Nvidia CUDA. In presenza di schede video NVIDIA che supportino CUDA l'elaborazione sarà dunque eseguita via GPU.

In assenza di un tale hardware l'elaborazione sarà possibile, ricorrendo alla CPU, ma molto probabilmente risulterà più lenta rispetto ad un normale render mental ray.

Le schede video attualmente disponibili in grado di supportare NVIDIA CUDA sono le geforce 8x00, 9x00, gt1x0, gt2x0, le quadro fx-570, fx-1700, fx3700, fx4600, fx-5600, fx-580, fx-1800, fx-3800, fx-4800, fx5800, nonché tutte le schede NVIDIA Tesla.

Nel corso del primo semestre 2010 saranno inoltre presentate le schede video dotate di chip NVIDIA GT300, noto con il nome di Fermi.

Le prime schede ad uscire potrebbero essere le schede dedicate al segmento professionale, Tesla ed eventualmente Quadro di fascia alta, e a seguire sono attese le schede Geforce di fascia alta. L'uscita è attesa per il primo trimestre 2010 (1° trimestre fiscale = fine gennaio - fine aprile). A seguire, nel corso della primavera e dell'estate, dovrebbero uscire anche modelli di fascia mainstream (media) e performance (medio-alta).

Le schede basate su architettura Fermi miglioreranno in particolar modo le prestazioni nellle elaborazioni in doppia precisione, tallone d'achille del chip gt200 di precedente generazione.

A quanto si apprende da questa FAQ, le caratteristiche di Iray, per quanto riguarda l'hardware supportato dovrebbero essere le seguenti:

- supporto a schede video NVIDIA Geforce, Quadro e Tesla che supportino NVIDIA CUDA.

- mancato supporto a schede video di generazione rpecedenti e a schede video concorrenti (ATI/intel).

- possibilità di esecuzione via CPU in assenza di VGA adatte.

- Non sono previste versioni funzionanti via OpenCL: non è quindi previsto il supporto a schede video concorrenti.

- Necessità di un elevato quantitativo di memoria RAM video.

- Supporto a configurazioni multi GPU SLI con scalabilità quasi lineare con il numero di GPU installate.

- Supporto al render in rete via GPU con scalabilità meno che lineare con il numero di GPU a disposizione nella rete.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites
- possibilità di esecuzione via CPU in assenza di schede video adatte (credo che in tal caso sai meglio evitare l'uso di Iray però).

iray lo si può usare come preview, le prime fasi, anche con la cpu, sono piuttosto veloci

il risultato non è esattamente indentico a mental ray, ma in genere c'è una buona corrispondenza

Share this post


Link to post
Share on other sites
E come velocità quando gira su CPU è più o meno veloce di mental ray?

non è una domanda con un' unica risposta, dipende cosa intendi: 

- è più veloce di mental ray ottimizzato? no, è un metodo brute force e come tale è più lento di un metodo interpolato (vale per tutti i motori brute force ovviamente)

- è più veloce di mental ray impostato ad cazzum, oppure di mental ray utilizzato come brute force o pseudo brute foce (FG force/ IP non interpolata)? sì, in maniera particolare su alcuni tipi di scene, o su scene in cui è presente un gran numero di effetti complessi (dof/glossy e via dicendo)

tenete presente che per ora iray non ha nessun limite di bounces o ottimizzazioni di questo tipo, quindi non è neanche semplicissimo fare dei raffronti

purtroppo non posso scendere in ulteriori dettagli, ma penso che arriveranno dei bench anche per quanto riguarda le gpu, ovviamente le quadro saranno più veloci delle normali geforce, anche se hanno supporto cuda (tutta questione di driver, suppongo)

Share this post


Link to post
Share on other sites

Innanzitutto ti ringrazio per la risposta. A questo punto edito il mio riassunto.

Ora ti chiedo... porca miseria, davvero anche qui si farà in modo che le quaadro siano più veloci??

A ivello driver cosa può cambiare per quanto riguarda il semplice supproto a CUDA? Ho l'impressione che anche qui si tratterà di un semplice freno per le geforce.

Non è che la differenza sia imputabile alla quantità di ram, per caso?

Share this post


Link to post
Share on other sites
Innanzitutto ti ringrazio per la risposta. A questo punto edito il mio riassunto.

Ora ti chiedo... porca miseria, davvero anche qui si farà in modo che le quaadro siano più veloci??

A ivello driver cosa può cambiare per quanto riguarda il semplice supproto a CUDA? Ho l'impressione che anche qui si tratterà di un semplice freno per le geforce.

Non è che la differenza sia imputabile alla quantità di ram, per caso?

l'informazione prendila con le pinze perché non ha niente di ufficiale, quando ho chiesto che gpu acquistare mi hanno dato i riferimenti alle quadro, però è possibile che sia soltanto una mia congettura, da quello che hanno detto dovrebbero cmq rilasciare a breve tutte le info e (se non ho capito male) i bench

Share this post


Link to post
Share on other sites

Volevo segnalare che a Natale la ATI ha rilasciato il nuovo ATI Stream 2.0: per il terzo anno consecutivo dunque, dicembre si conferma come il mese delle novità per il gpu-computing. Questo fatto è estremamente importante poiché ATI nel 2007 aveva rilasciato il pacchetto 1.0 basato su una variante ottimizzata di C per il calcolo massivo su stream, chiamato Brook+. Non vorrei mettere il dito nella piaga, ma di certo le scelte di ATI degli ultimi anni non sono mai state particolarmente lungimiranti, tant'è che di fatto il mondo gpgpu oggi è quasi esclusivamente CUDA di nVidia. Ora però le cose potrebbero cambiare perché il codice è stato riscritto su OpenCL 1.0: è bene sottolineare l'importanza di questa scelta, poiché anche nVidia con CUDA 2.0 e successive ha lavorato appieno sul supporto del framework OCL, e questo significa che in futuro sarà sempre più facile scrivere applicazioni supportate da entrambi i due mondi, al netto diciamo delle ottimizzazioni di cui poi ogni scheda ha bisogno affinché venga sfruttata a pieno la sua potenza. Vale la pena aggiungere che con il chip R8 (quindi Radeon HD5xxx) la compatibilità con OCL è hardware, e non emulata come nel chip R7 (quindi Radeon HD4xxx), che pur dunque essendo compatibile soffrirà un grosso calo di prestazioni, molto più elevato di quanto dica la potenza della gpu.

Questo potrebbe segnare una svolta importante soprattutto nei tanti progetti di calcolo distribuito BOINC e similari, la cui differenza prestazionale tra cpu e gpu è più che netta. Mentre in campo grafico c'è ancora da attendere un po' affinché si affermi uno standard di sviluppo in tal senso.

Qui maggiori informazioni e tutte le compatibilità:

http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx#two

Share this post


Link to post
Share on other sites

Vediamo...

Io credo che con hd6000 ATI cambierà architettura, verso una più ottimizzata per il GPU-computing, cioè più efficiente in DP e più parallelizzabile. Fin'ora se ne è rimasta nel campo videoludico, perché in sostanza è li che si fanno i soldi. Quest'anno vedremo qualche bella innovazione e l'anno prossimo io credo che le schede video si inizieranno ad usare intensamente...Comunque è arrivato il nuovo stream, sono arrivati i driver openCL per GPU e CPU... insomma si sta mettendo in riga.

Unica cosa che non capisco è la faccenda openCL su rv770... a quanto ne avevo capito la differenza non è hardware vs software (anzi, non credo si possa definire una simile differenza in campo GPU). rv770 dovrebbe richiedere delle ottimizzazioni del codice particolari per girare bene (non mi ricordo chi avesse fatto dei test a riguardo). Il problema potrebbe essere risolto con aggiornamenti specifici dei driver, ma ATI sembra avere intenzione di non curarsi troppo del problema... peccato.

Share this post


Link to post
Share on other sites

Concordo sul fatto che il 2010-2011 saranno i due anni centrali per la diffusione del gpu-computing a livello di calcolo massivo, non solo in campo grafico o scientifico, ma anche in campo home/office (tipo presentazioni futuristiche o anche la semplice scansione dei programmi di sicurezza). È un bene che ATI, che tanto ha sostenuto OCL per altro, abbia lavorato sodo quest'anno per rilasciare i propri nuovi stream. L'unica cosa purtroppo è che mentre nVidia fa partire il suo CUDA dalle schede ad architettura unificata (G80), ATI ha compatibilità soltanto con gli ultimi 2 chip, lasciando fuori HD2 e HD3 che mi pareva fossero compatibili con Stream 1.0. Su RV7 neanche io ho capito bene la cosa, ho però letto che richiede una emulazione via software di OCL, piuttosto che essere pienamente compatibile a livello di calcoli hardware: cioè appunto il fatto che mentre su RV7 serve un codice apposito per far girare quel tipo di applicazioni, su RV8 questo non diventa più necessario. Almeno così l'ho intesa io leggendo un po' di documenti in giro: se poi il termine "emulazione" non è il più appropriato, tuttavia mi sembrava il più giusto per rendere l'idea di quello che dicevo... Purtroppo non sono molto ferrato in campo ATI development, storicamente mi interesso più di nVidia Quadro (penso si sia capito :hello: ).

Ora cmq provo BOINC, ho visto che è uscita la release compatibile con gpu ATI, cercherò poi un po' di confronti in rete con nVidia e le nuove HD5... Se trovo qualcosa di interessante posto un po' di dati...

Share this post


Link to post
Share on other sites

Credo che richieda un emulazione in mancanza di specifiche ottimizzazioni. ;Ma l'esecuzione è hardware per definizione. Se fosse emulata via software la farebbe la CPU...

Le hd2000 e hd3000 erano compatibili solo con una prima release di stream e delle OpenCL, perché nate prima del completamento dello standard.

Anche le schede nvidia forniscono supporto a openCL solo a partire da gt200 (che peraltro nonn fornisc un supporto totale).

CUDA invece sarebbe compatibile con tutte le versioni da G80 in poi (è proprietario ed è nato ancora ai tempi di g80) ma anche qui, solo le ultime schede supportano cuda 2.1... specifiche che ad esempio sono richieste per eseguire Iray su GPU...

Allo stesso modo il format proprietario di ATI (close to metal se non ricordo male) è compatibile a partire dalle hd2000 (e in parte può essere eseguito anche su x1900 se non ricordo male, dalle quali erano derivate le prime firestream).. ma non so in realtà se il linguaggio supportato fosse lo stesso).

Share this post


Link to post
Share on other sites

Si infatti proprio quello intendevo: emulazione in assenza di codice ottimizzato... Stream cmq dovrebbe partire da HD2, non so se c'è qualcosa che riesce a girare sotto X1900, mentre questa specifica versione, al di là di OCL, parte proprio da HD4 se non ho capito male. Per nVidia è vero, speriamo che questa storia di CUDA e del gpu non diventi peggio del socket Intel: ogni nuova generazione tocca cambiare scheda perché diventa incompatibile con il vecchio standard. Sarebbe una seccatura, soprattutto perché il vecchio hardware diventerebbe di fatto inutilizzabile all'aggiornamento dei programmi...

Di CUDA 2.2 e 2.3 come compatibilità sai niente?

Share this post


Link to post
Share on other sites

No, di cuda 2.2 non credo si sappia nulla... Ad ogni modo credo che una volta messa a punto la tecnologia la questione compatibilità si asseseti... Insomma, le specifiche in questo periodo di "novità" cambiano anche radicalmente e diventa impossibile farle rispettare ad un vecchio hardware.

Al momento cuda 1.0 è supportato a partire da g80, mentre openCL e cuda 2.1 a partire da gt200. opencl e stream nonsoché sono supportati da hd4000 e stream 1.0 anche su hd2000 e hd3000. Sul vecchio chip r580 non so cosa girasse, ma credo che avesse una versione di stream apposita e "primordiale".

Comunque vediamo perché nvidia non è che abbia dato un contributo a openCL... ne fornisce il supporto perché le sue schede video non restino fuori dei giochi in caso di software sviluppato per OCL, ma sembra del tutto intenzionata a promuovere il solo CUDA...

Io credo comunque che la diffusione delle Tesla potrà iniziare con gt300... gt200 aveva una potenza in DP troppo ridotta e vicina a quella delle CPU perché anche le grosse realtà pensassero di fare il salto.

Alle openCL comunque daranno una grande spinta le comunità opensource, se anche gli sviluppatori pensassero di orientarsi verso CUDA trascurando gli utenti ATI...

Share this post


Link to post
Share on other sites

Non ho avuto tempo di leggere, ma siamo a CUDA 3.0beta:

http://forums.nvidia.com/index.php?showtopic=149959

In ogni caso è Stream 2.0+OCL 1.0, quello appena uscito, ad essere compatibile con HD4... ;)

A proposito, secondo BOINC una wu di Milkyway con la sola cpu @3,4Ghz ci mette un paio d'ore o qualcosa del genere (forse meno, non ho completato la task, ho fatto solo il cpu-bench), se passo al gpu-computing con la ATI a 550Mhz (frequenza per impostare la ventola al 45%, silenziandola, oltre il quale infatti fa troppo rumore), circa 5 minuti... :D

Da quello che so, le ATI sono migliori delle nVidia in questo tipo di applicazioni, la qual cosa probabilmente è dovuta alla sua architettura piuttosto che ai driver...

Share this post


Link to post
Share on other sites

BAH... è dovuta al fatto che nominalmente le hd4870 facevano 1,2TF in single precision, le hd4890 1,35TF se non sbaglio... Le NVIDIA erano attorno al teraflop... Per cui dove si riesce ad avere un ottima scalabilità sugli shader a 5 vie si ottengono prestazioni elevatissime...

Non so cosa si ivnenterà ATI in futuro, am secondo me, fotrse mantenendo gli shader a 5 vie attuali, passerà ad un architettura MIMD, con scheduler per ogni cluster (80 ALU a cluster - 16 shader) e cache dedicata... Una cosa simile a quella che sta facendo NVIDIA insomma... Io penso che il giorno che esce GT300 intanto compare hd5890, e poi si inizia a parlare di hd6000


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

Volete sapere e capire cosa si cela dietro il gpgpu? Eccovi accontentati dal buon yossarian:

http://www.appuntidigitali.it/6350/gpu-unita-dedicate-o-unita-generiche/

La cosa ci riguarda direttamente in quanto, in fondo all'art., si legge:

Nelle prossime puntate di questa mini serie, approfondiremo alcuni aspetti delle architetture dei chip menzionati in questo articolo cercando, nei limiti del possibile, di scoprire quali saranno le prospettive future della grafica 3D e del GPU computing.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...