Link alla notizia: http://www.hwupgrade.it/news/skvideo/nvidia-cuda-una-serie-di-annunci-per-il-supporto-gpu_33817.html

NVIDIA continua a spingere lo sviluppo di CUDA e lo conferma, in occasione del keynote di apertura, con alcuni importanti annunci

Click sul link per visualizzare la notizia.

Ridicoli.. cuda fara la fine di Cg: dimenticato da tutti, e usato solo in applicazioni legacy.


Il futuro e' open, cross platform, e cross hardware. Uscite le api OpenCL, ormai non ha senso usare CUDA

(tanto piu che opencl la roba della news gia' la fa : ))

Ridicoli.. cuda fara la fine di Cg: dimenticato da tutti, e usato solo in applicazioni legacy.


Il futuro e' open, cross platform, e cross hardware. Uscite le api OpenCL, ormai non ha senso usare CUDA

(tanto piu che opencl la roba della news gia' la fa : ))

di ricolo c'è solo il commento tuo.

Se tu sapessi qualcosa di OpenCL sapresti anche che è DECISAMENTE indietro rispetto a CUDA.

Tornando in topi, gli ultimi 2 paragrafi della news indicano una bella sterzata rispetto al passato...

Ridicoli.. cuda fara la fine di Cg: dimenticato da tutti, e usato solo in applicazioni legacy.


Il futuro e' open, cross platform, e cross hardware. Uscite le api OpenCL, ormai non ha senso usare CUDA

(tanto piu che opencl la roba della news gia' la fa : ))

lo dicevano anche 3 anni fà...

Ridicoli.. cuda fara la fine di Cg: dimenticato da tutti, e usato solo in applicazioni legacy.


Il futuro e' open, cross platform, e cross hardware. Uscite le api OpenCL, ormai non ha senso usare CUDA

(tanto piu che opencl la roba della news gia' la fa : ))Dlin Dlon
Avviso di servizio

NVIDIA fa da pioniere nel supporto OpenCL, tant'è che vi siede anche nel direttivo, è la funzionalità è garantita per tutte le sue ultime VGA da anni a questa parte

I suoi tool di sviluppo CUDA sono strumenti ancora più flessibili per aiutare lo sviluppatore in quello che dovrebbe essere il suo fine ultimo: implementare degnamente del codice in modo facile e veloce (possibilmente senza accedere alla strutture I/O di base dell'architettura come per la concorrenza)

Dlin Dlon
Fine Avviso

Riporto una breve scheda tecnica su CUDA (potrebbe essere non aggiornata)

Scheda Tecnica
Sviluppatore NVIDIA Corporation
Ultima Release Stabile 3.0 / 19 Marzo, 2010;
OS Windows 7, Windows Vista, Windows XP, Windows Server 2008, Windows Server 2003, Linux, Mac OS X
Genere GPGPU
Licenza Proprietario, Freeware
Sito Nvidia's CUDA

mi correggo : lo dicevano 4 anni fà che cuda sarebbe morta come tecnologia...
BAH...

Pensa un po' che le librerie cuda e OpenCL le uso ogni giorno

:muro:

di ricolo c'è solo il commento tuo.

Se tu sapessi qualcosa di OpenCL sapresti anche che è DECISAMENTE indietro rispetto a CUDA.

Tornando in topi, gli ultimi 2 paragrafi della news indicano una bella sterzata rispetto al passato...

non ci posso credere!
finalmente dopo 1 anno dalle mie preghiere e dopo averli mandati a quel paese, hanno prodotto un compilatore CUDA basato su x86! ora si che gli sviluppatori potranno produrre software adeguato!
vi rendete conto di quanto questo sia importante per il debug delle applicazioni?, ora finalmente le applicazioni cuda fioccheranno. possiamo tirar fuor dall'armadio il server tesla...sperando che la portabilità sia diretta a livello di sorgente....

Ridicoli.. cuda fara la fine di Cg: dimenticato da tutti, e usato solo in applicazioni legacy.


:doh:


Il futuro e' open, cross platform, e cross hardware. Uscite le api OpenCL, ormai non ha senso usare CUDA


E si, come no, nei sogni di molti ...
Ma dove vivi ?

Pensa un po' che le librerie cuda e OpenCL le uso ogni giorno

:muro:

allora cambia lavoro :Prrr:

Qui maggiori dettagli:

http://www.pgroup.com/resources/cudafortran.htm

P.S.: è una società della STMicroelectronics

Di certo voi siete tutti esperti qua per parlare..
Non sarete certo quelli che leggono cuda su PC professionale e vengono qua a commentare, vero? ;)

:doh:



E si, come no, nei sogni di molti ...
Ma dove vivi ?



allora cambia lavoro :Prrr:

Ora è un fatto che si usi CUDA più dell'OpenCL.
Nel momento in cui gli sviluppatori mostreranno maggiore propensione per quest'ultimo, staremo a vedere quale sarà la società che meglio fornirà strumenti e soprattutto supporto.
Vista la situazione passata e presente, io un'idea me la sono fatta :)

Io non so come vi possa piacere lavorare su un framework totalmente chiuso e legato a filo doppio ad una casa produttrice. Supponiamo che domani AMD tiri fuori schede che vadano dieci volte meglio delle Nvidia e che il mercato diventi per il 99,99% in mano ad AMD, vi farebbe piacere riscrivere tutto il software in OpenCL?
Nel mio piccolo (ma piccolo piccolo) cerco di scrivere in OpenCL, perché il mio software deve poter girare anche su quei computer dove è installata una FirePro o una FireStream o una Radeon.

raga forse nessuno di voi ha compreso l'importanza di avere un compilatore CUDA per x86, se qualcuno di voi avessere realmente sviluppato su CUDA comprenderebbe quello che intendo....
voi fate la gara tra CUDA e OPENCL...bene le OPENCL sono ancora in uno stato embrionale come sviluppo...non vi rendete conto di questo perchè evidentemente non le programmate....inoltre serve un compilatore OPENCL che giri su CPU e non su GPGPU in quanto al momento le GPU non hanno la possibilità essere gestite da un debug...inoltre le schede nvidia adesso hanno introdotto 2 funzioni importantissime, la prima è quella di ottenere via software il controllo esclusivo di una GPU la cosa non è di poco conto in quanto in sistemi multitread capitava di avere 2 tread di processi diversi che accedevano alle stesse risorse bloccando di fattto il sistema, oggi invece si puo' evitare prendendo il controllo esclusivo della GPU e quindi gli altri tread aspettano...l'altra introduzione importante è quella di una serie di interrupt su PCIEX che permetteranno di comprendere lo stato della GPU in real time....questa cosa attualmente non è supportata da nessun software e credo neppure dal compilatore x86 ma sarà importante in futuro, quanto oggi i passaggi per ricevere i risultati dei calcoli della gpu sono alquanto contorti...
come ho scritto prima la prox settimana tiro fuori dall'armadio il server tesla e vediamo che aria tira...

credo che intel sta iniziando a tremare....

@Homero
Visto che tu programmi OpenCL invece, sicuramente ci saprai spiegare l'embrionalita' del loro stato.
Il compilatore OpenCL x86 c'e', ed e' quello AMD.
Tanto piu che essendo openCL praticamente C, fai in fretta a debuggare, basta che fai copia incolla in un sorgente e lo compili/esegui come codice C

@maumau138
Ma che stai dicendo?
Forse tu usi le GPU per fare dei giochini. Chi invece usa le GPU per fare i calcoli in maniera serie vuole essenzialmente una cosa: potenza per watt per euro.
Se sviluppare in OpenCL vuol dire che le prestazioni calano, il fatto che tale SW sia portabile su una possibile ed immaginaria architettura tra 10 anni non ha alcun senso tenerne conto. Mettiamo che domani invece AMD fallisca (perchè è più probabile che fallisca visti i bilanci che riesca a fare una scheda professionale che va meglio di quelle NVIDIA) che te ne fai del tuo codice compatibile ma poco efficiente?
Sarebbe come dire che oggi è stupido usare i sistemi di sviluppo della Microsoft .NET (che sono chiusi e legati ad una unica architettura, quella Intel) perchè se domani il PippoOS prende il 99.9% del mercato e MS fallisce le tue applicazioni non funzioneranno più. O se ARM sbaragliasse Intel nella produzione di processori per Desktop/Workstation.
Quando domani OpenCL mostrerà di avere le stesse potenzialità di CUDA e avere la stessa capacità nel supportare lo sviluppo, allora ci si potrà fare questa domanda. Anche se parlare di CUDA vs OpenCL è sbagliato, perché OpenCL nell'implementazione NVIDIA gira proprio sul framework CUDA.

Oggi la concorrenza non è proprio presente nel mercato del GPGPU. I migliori strumenti da diversi anni li ha presentati NVIDIA e questo gap che si è formato sarà difficile da ricoprire in tempi brevi. Inutile speculare su cosa sarà domani perché ogni direzione è possibile quando non c'è niente all'orizzonte.
AMD deve ancora presentare una architettura che faccia qualcosa di più che rasterizzare poligoni a velocità della luce e sopratutto dimostrare di avere la forza di sostenere gli sviluppatori (che non sono i videogiocatori che investono 200 euro in una scheda grafica) con qualità.
Per ora non si vede niente di tutto questo ed è davvero infondato la critica a chiunque investa il proprio futuro (in termini di tempo e risultati ottenuti) in un qualcosa di certo come lo sviluppo per CUDA.

L'intero concetto di OpenCL vs. CUDA non ha senso, in quanto sono due cose diverse... openCL è una libreria, CUDA è un framework, il quale tra l'altro si basa su opencl per funzionare.

Trasponendo l'esempio nel mondo videoludico, con qualche licenza, sarebbe come dire "DirectX fa schifo, molto meglio l'unreal engine" o viceversa.

Al limite, il confronto è da fare tra CUDA,Stream e applicazioni che non usano alcun framework condiviso.

il quale tra l'altro si basa su opencl per funzionare
Huh? Prego rielaborare. Il framework CUDA esiste da qualche tempo prima che OpenCL venisse persino ideato. Dubito assai che il framework abbia bisogno di OpenCL per funzionare.
E' l'implementazione OpenCL di NVIDIA che usa CUDA per funzionare, semmai.

ottima notizia cuda su matlab

Se CUDA funziona solo su schede nVidiose non ha molto senso di esistere visto che essendo basato su OpenCL potrebbe funzionare su qualsiasi altra scheda video. Indubbiamente in campo professionale le schede verdi sono quelle più usate ma in campo non professionale AMD mi sembra che vada di più.
OpenCL sarà anche più complicato ma per gli sviluppatori CUDA non è molto utile visto che se vogliono fare un applicazione che vada con diverse GPU con CUDA non possono farlo.
Poi quanto sarà efficiente CUDA con gli x86? Rimane ancora tutto da vedere...

CUDA non è basato su OpenCL. Ma dove le prendete queste notizie?
CUDA è una cosa completamente diversa da OpenCL. CUDA è il framework .NET e OpenCL è lo C#, per fare un parallelo con lo sviluppo per CPU.
CUDA ha senso di esistere perchè per ora è l'unica soluzione professionale che permette di ottenere certi risultati con la programmazione delle GPU. Tutto il resto per ora è a livello amatoriale.
Che AMD vada di più nel campo non professionale non ha alcun senso in questo discorso. Pensa che Intel vende tante schede video quante NVIDIA e AMD messe insieme. Eppure la sua architettura non è neppure presa in considerazione in questi discorsi.. chissà perchè.
Ad alcuni sfugge che nel così detto professionale NVIDIA ha il 90% del mercato (e quindi che il SW giri su FireStream e FireGL poco importa a chi nel settore opera, vedi Adobe) e nel GPGPU praticamente è l'unico operatore presente (avendo creato il mercato proprio loro).

Huh? Prego rielaborare. Il framework CUDA esiste da qualche tempo prima che OpenCL venisse persino ideato. Dubito assai che il framework abbia bisogno di OpenCL per funzionare.
E' l'implementazione OpenCL di NVIDIA che usa CUDA per funzionare, semmai.

Mea culpa, sviluppando qualche applicazione per CUDA ho visto che nelle sue librerie ha opencl, e ho assunto che la usasse per dialogare verso la scheda. Approfondendo, vedo invece che tale libreria fornisce una API compatibile opencl per il programmatore, in pratica ne è l'implementazione.

Ribadisco, comunque, che CUDA e OpenCL sono concetti diversi, e non ha molto senso compararli direttamente.

Sono comparabili nel senso che sono comunque due strumenti che sono utilizzati per programmare la GPU. Diversi tra loro, ma che fanno la stessa cosa.
E per ora uno dei due è anni luce indietro all'altro e quello che non ha senso è quello di prenderlo in considerazione per fare un progetto più serio di un Hello World su GPU solo sul pensiero che forse, magari, nel caso che, magicamente una soluzione concorrente ancora non esistente possa essere presa in considerazione.

@Someone

Visto che tu chiaramente ti occupi di progetti complessi, facci un esempio pratico di dove CUDA fa faville, mentre OpenCL non puo' nemmeno essere preso in considerazione.
Altrimenti qua di chiacchiere ci siamo stancati. Puoi scrivere quanto vuoi "CUDA e' anni luce avanti", ma finche' non porti esempi, le tue parole non servono a niente

CUDA è in sviluppo da oltre 3 anni ed ha una serie di librerie certificate che permettono di dirimere una serie di problemi nella programmazione multi threading. OpenCL è già tanto se fa quello che deve, visto che entrambe le implementazioni di NVIDIA e sopratutto AMD sono bacate. Quest'ultima è talmente mal messa che coloro che sviluppano la libreria fisica Bullets hanno pubblicamente dichiarato che devono usare il sistema di sviluppo OpenCL di NVIDIA perchè con quello AMD non è ancora possibile ottenere nulla di funzionante. Parole loro dette quasi un anno fa.
E chiunque deve decidere di investire in un progetto di calcolo che deve fare qualcosa di serio, certamente queste cose le prende in considerazione. D'altronde è come chiedersi perchè esistono server con architetture diverse da quella x86. Che senso ha sviluppare applicazioni per Power/Cell quando con x86 si può fare tutto con costi di sviluppo minori.
Per certi progetti dove l'ottimizzazione delle risorse (performance per watt) facilmente ripaga del maggior investimento nello sviluppo, l'uso di sistemi "proprietari" o comunque diversi da quelli standard è più che giustificabile. E nessuno si pone la domanda "Ma se IBM smette di fare processori Power?". E consumano 1/3 delle soluzioni x86 based con le stesse performance.
Per cui un ipotetico ospedale che deve creare una macchina per l'analisi delle immagini della Risonanza Magnetica poco gliene potrà importare che il proprio applicativo tra 5 anni potrebbe anche girare su una macchina diversa da quella che ha ora a disposizione. Crea e sviluppa per tale macchina in modo da sfruttarne al massimo le potenzialità ed evitando di dover installare il doppio delle GPU per ottenere gli stessi risultati. E il triplo del tempo di sviluppo per una soluzione che non si sa oggi se alla fine sarà sufficientemente matura.

Tra x anni quando OpenCL disporrà della stessa maturità di CUDA, allora vedremo come le cose evolveranno. Ma tenendo conto del fatto che NVIDIA investirà il minimo indispensabile in OpenCL e tutto il carico è posto nelle mani di AMD credo che non si arriverà mai nemmeno ad un pareggio. AMD non ha ancora presentato una architettura che sia ottimizzata per l'HPC, figuriamoci se ha la capacità/volontà di fare in modo che OpenCL possa diventare lo standard per la programmazione su tali architetture. Anche perchè rischia di non ottenere molto di più del fatto che gli sviluppatori useranno OpenCL per programmare ma poi useranno sempre e comunque schede NVIDIA per i calcoli, almeno finché AMD non avrà un prodotto in grado di eguagliare la soluzione della concorrenza. E come prodotto non indico solo l'HW, ma anche tutto l'apparato di assistenza che ci sta dietro.

Ad alcuni non è nemmeno noto che NVIDIA investe di più in SW che in HW, e quindi per AMD la cosa è davvero difficile. Invertendo la frittata, OpenCL non offre nulla di più di quello che offre CUDA e non c'è una vera speranza che lo sia in tempi brevi. E forse nemmeno medi.
Ecco perchè la gente continua ad usare CUDA e NVIDIA ad investirci capitali superiori a tutti quelli che AMD mette nello sviluppo delle proprie schede da gioco.

@Someone

Ok, da quello che hai scritto posso capire che parli per sentito dire senza aver mai usato ne' provato nulla.
Non hai portato un singolo esempio dove OpenCL non sia adeguata (solo che l'implementazione AMD era bacata, e si sapeva d'altra parte).
Hai scritto che l'implementazione di nVIDIA e' bacata e non mi risulta. forse parli della versione 1.1 compliant, che non e' ancora nemmeno pubblica ma disponibile solo per gli sviluppatori.
Purtroppo molti altri qui commentano per sentito dire..

figurarsi se alla AMD sono capaci di scrivere un software che funga bene :D
per loro se la ventola della tua vga funge, e i giochi vanno a cannone colle schede di max 2 anni fa( LOL ), è già grasso che cola...

0 supporto per le vecchie vga...
0 supporto per ambienti diversi da win32 (e ce ne sono tanti)
0 supporto per il gpgpu...

annamo bene :asd:

Mah, sto cazzo di forum, sta diventando peggio di punto informatico...

Qualcuno sa quanto si dovrà aspettare per un implementazione trasparente delle funzioni di base di calcolo ingegneristico per cuda? Ho visto diversi articoli in giro che parlano di implementazioni embrionali in ambito fem, ma niente di abbordabile all'umano medio.

Cmq per quel che mi hanno detto allo stand di nvidia le funzioni di matlab che sfruttano cuda sono pochissime e limitate all'analisi dei segnali tipo fft e qualche altra chicca... La più grande evoluzione sarebbe la disponibilità delle librerie LAPACK per cuda in formato open, almeno x quel che mi riguarda...
Queste librerie gestiscono il calcolo matriciale a una velocità pazzesca, ma sono ottimizzate per il calcolo seriale, quindi nn sono sicuro abbia molto senso, forse si farebbe prima a riscriverle daccapo.

xTedturb0

OpenCL x86 non è portabile direttamente su scheda GPGPU...nel senso che tu scrivi il tuo bel programmino in C che sfrutta le openCL per una determinata scheda diciamo x86...allora speri di poter ricompilarlo e farlo funzionare tale e quale su una radeon ad esempio o su una nvidia...
bene questo non è possibile, o meglio non funziona nel 95% dei casi...
se questo non è uno stato embrionale....non so proprio quale sia...lasciando stare i vari bugs e rallentamenti....

vedi tedturb0 il compilatore CUDA x86 si dovrebbe intendere un vero e proprio emulatore GPGPU per il compilatore C...ossia si dovrebbe comportare tale e quale come la scheda video...quindi se il software funziona sul compilatore x86 pari pari dovrebbe funzionare sulla scheda video...questo sopratutto quando la scheda supporta le ultime funzioni sul bus pciEX e quelle per ottenere il controllo esclusivo del GPGPU...

quindi oggi le OPENCL sono ancora un incubo per il programmatore, tanto che lo dicono gli stessi sviluppatori che sono librerie immature...
...cuda in questo è avanti perchè nvidia ha già tutti i sistemi di sviluppo per sfruttare le sue gpgpu soltanto che non le rende disponibili a tutti almeno fino ad ora speriamo che questo nuovo compilatore sia la vera svolta....

inoltre non esiste un hardware openCL compliant...ossia programmare opencl su x86 è niente piu' niente meno che programare con qualunque altra libreria in C...il problema è la portatilità del codice che è praticamente nulla...perchè ogni hardware la interpreta a modo suo sia per funzionalità che per prestazioni che per debugging...

@Tedturb0
Dicci tu che sei più informato il perchè, oggi, uno che deve sviluppare una applicazione GPGPU debba scegliere OpenCL invece di CUDA. A parte la questione della portabilità che comunque non esiste (architetture diverse richiedono comunque approcci differenti al problema per migliorare l'efficienza), quali sono i motivi oggettivi per scegliere OpenCL.
Mettiti nei panni di uno che deve investire un paio di milioni di euro per sviluppare una applicazione CHE FUZIONI e che poi porti degli introiti per ripagare l'investimento fatto.

Quello che sviluppo io funziona, con opencl, usando sdk NVIDIA, ma funziona anche con l'implementazione apple. Per AMD non ho mai provato, so che la loro implementazione ha problemi (quella per GPU intendo) ma non avendo hardware a disposizione non abbiamo provato.
Per il resto, con OpenCL fai tutto quello che fai con CUDA, e il discorso non e' portabile perche' le ottimizzazioni sono diverse non tiene. Intanto e' portabile, e i kernel bene o male funzionano dappertutto.
Certo, con CUDA questo problema non ce l'hai, visto che devi ottimizzare solo per nVIDIA (che poi anche li, dipende da che architettura usi, voglio vedere come un kernel CUDA ottimizzato per FERMI gira su G80), ma questo puoi farlo anche con OpenCL, visto che nel caso nVIDIA e' ne' piu ne' meno che un wrapper per CUDA ( mi fanno morire quelli che dicono OpenCL e' un API, CUDA e' un framework... hahaha )

Ma la questione della portabilità è inesistente nel campo HPC. Quando si fa un SW lo si fa perchè funzioni su una determinata architettura e la sfrutti al max. Al più ci si pone il problema se la architettura successiva sia sfruttabile in altrettanta maniera nel caso di aggiornamento dell'HW, non certo se la propria applicazione debba funzionare indistintamente su G80 o Fermi.
E' come dire che volendo realizzare un motore di raytracing in tempo reale lo faccio un Java così sono sicuro che funziona sia sulla Workstation con 4 CPU da 12 core l'una sia sul telefonino. Se stai sviluppando qualcosa per uno scopo ben preciso, la portabilità tra sistemi diversi non ha alcun senso prenderla in considerazione.
E' proprio quel "e' portabile e il kernel funziona bene o male" che non ha senso. Se uno compra un server con 20 Tesla vuole che le perfomance per Watt che sputa fuori siano le più alte possibili, come per l'acquisto di un normale server, e quindi ci fa una applicazione ad hoc, non vuole che l'applicazione funzioni "più o meno bene".
Nel campo professionale vale anche il discorso che NVIDIA ha il 90% del mercato, per cui sviluppare solo per tali architetture non comporta alcun problema, anzi, quindi a che pro usare OpenCL?

Parlando del nuovo compilatore io credo che l'annuncio sia potenzialmente interessante ma per come immagino sarà portato avanti il progetto rischia di essere meno appetibile.
In sostanza immagino che il nuovo compilatore sarà closed source e non free.
In particolare l'aspetto della conversione semi-automatica del codice Cuda in codice ottimizzato per l'esecuzione nelle Cpu, chiaramente con performance notevolmente inferiori, se inserito in un progetto open-source avrebbe permesso il fiorire di una community open source più attiva verso questo produttore di hardware, nonostante rimane l'ostacolo del suo mancato supporto a driver open (ma almeno i suoi driver proprietari, pure in linux, non sono male).

Ma la questione della portabilità è inesistente nel campo HPC. Quando si fa un SW lo si fa perchè funzioni su una determinata architettura e la sfrutti al max. Al più ci si pone il problema se la architettura successiva sia sfruttabile in altrettanta maniera nel caso di aggiornamento dell'HW, non certo se la propria applicazione debba funzionare indistintamente su G80 o Fermi.
E' come dire che volendo realizzare un motore di raytracing in tempo reale lo faccio un Java così sono sicuro che funziona sia sulla Workstation con 4 CPU da 12 core l'una sia sul telefonino. Se stai sviluppando qualcosa per uno scopo ben preciso, la portabilità tra sistemi diversi non ha alcun senso prenderla in considerazione.
E' proprio quel "e' portabile e il kernel funziona bene o male" che non ha senso. Se uno compra un server con 20 Tesla vuole che le perfomance per Watt che sputa fuori siano le più alte possibili, come per l'acquisto di un normale server, e quindi ci fa una applicazione ad hoc, non vuole che l'applicazione funzioni "più o meno bene".
Nel campo professionale vale anche il discorso che NVIDIA ha il 90% del mercato, per cui sviluppare solo per tali architetture non comporta alcun problema, anzi, quindi a che pro usare OpenCL?

ma anche no, il gpgpu viene comodo in svariati ambiti es cfd,fem ecc ecc e il vantaggio di avere un software che giri su svariate piattaforme si vede subito.

il gpgpu non viene solo utilizzato per sistemi custom ma anche per lo sviluppo di applicativi dove non si ha la certezza della macchina presente (a meno di proporre sw certificato solo su determinate piattaforme)