Quest’oggi vi propongo una riflessione in merito ad un fenomeno che sta prendendo piede nell’ambito della programmazione GPGPU e che proprio in questi giorni, nel corso della GPU Technology Conference tenutasi in questi giorni a San Jose, conferma l’interesse suscitato nell’ambito dello sviluppo di software di calcolo raccogliendo diversi consensi.
Parlo di CUDA, l’API per lo sviluppo di applicazioni mediante GPGPU, sviluppata da NVIDIA al fine di promuovere i propri processori grafici come piattaforma di riferimento per il GPGPU computing, cioè essenzialmente per l’uso delle GPU non solo per le elaborazioni della grafica in tempo reale così come la vediamo nei videogames, ma più in generale per la programmazione di un più ampio spettro di applicazioni.
Naturalmente le caratteristiche intrinseche dell’hardware di una GPU, la rendono particolarmente adatta ad alcune tipologie di elaborazioni e meno adatta ad altre. In generale si può ragionevolmente affermare che l’enorme molte di unità di calcolo in parallelo presenti in un processore grafico di ultima generazione ben si sposa con le elaborazioni massive di tipo SIMD, cioè Single Instruction Multiple Data.
Nel corso della GPU Technology Conference NVIDIA ha annunciato il supporto a CUDA da parte di nomi importanti nel mondo software come Matlab e Amber, oltre che 3D Studio Max per il rendering via ray tracing mediante mental ray iray. Inutile riportare che l’uso delle GPU Fermi in tutti questi ambiti, rispetto a workstation basate solo su classici processori x86, ha portato a un incremento di performance spesso sbalorditivo.
Alla luce del successo di CUDA, la questione che pongo personalmente è la seguente: quanto futuro può avere un’API proprietaria sviluppata per semplificare e accelerare lo sviluppo di applicazioni che utilizzano il GPGPU computing, considerando che esistono almeno due altri produttori hardware interessati al medesimo mercato?
Per meglio esprimere il mio punto di vista vi propongo due parallelismi con il passato: Glide e Cg. Non so quanti dei lettori conoscono la storia della gloriosa 3dfx Interactive, tuttavia indipendentemente da ciò che ha rappresentato quest’azienda per gli appassionati di videogames su PC negli anni 90, uno dei suoi principali punti di forza furono sicuramente le Glide.
Queste erano librerie proprietarie per l’accelerazione in hardware della grafica tridimensionale che ebbero un enorme successo all’epoca per almeno due ragioni. La prima è che erano state sviluppate come un sottoinsieme di OpenGL (ma che non aveva nulla a che fare ufficialmente con quest’ultimo) il che le rese molto più semplici e malleabili della mastodontica libreria utilizzata in ambito professionale. La seconda è che all’epoca la concorrenza di Microsoft con le sue DirectX era abbastanza scarna, in quanto queste ultime proponevano (parliamo della versione 3) un’API meno intuitiva e matura per lo sviluppo di motori grafici.
L’API Glide, essenzialmente uno standard de facto nella seconda metà degli anni 90, fu tuttavia soggetto di un rapido declino nel momento in cui emerse la sua più grande limitazione: era una libreria proprietaria e, in quanto tale, sviluppare un titolo usando esclusivamente le Glide significava renderlo incompatibile con il parco hardware di computer che possedevano una scheda video con chip non 3dfx.
Ci furono naturalmente delle concause: Microsoft mostrò gli artigli con le DirectX versione 5 e superiori, così come diversi titoli basati sui motori grafici Id Software preferirono adottare OpenGL. L’utilizzo di API non proprietarie di un produttore hardware da parte dei videogames fu, quindi, la soluzione preferita dal mercato sul lungo periodo.
Passiamo adesso al Cg anche denominato C for Graphics. Si tratta di un linguaggio di programmazione ad alto livello per lo sviluppo di vertex, geometry e pixel shader. La peculiarità di questo prodotto, sviluppato da NVIDIA, fu quella di introdurre per primo un linguaggio di programmazione degli shader ad alto livello per OpenGL, caratteristica che personalmente me lo fece adottare nello sviluppo del mio primo motore grafico in C++ :-).
In sintesi, il runtime del Cg non è altro che una libreria che compila il linguaggio Cg nell’equivalente HLSL – High Level Shader Language, per DirectX, e GLSL – OpenGL Shader Language, per OpenGL.
Dal momento in cui è stato introdotto (inizio del secolo) ad oggi, non si può affermare che il Cg abbia ricevuto un enorme successo commerciale per ragioni che risultano essere abbastanza comprensibili. Innanzitutto è raro trovare videogame che supportino sia OpenGL, che DirectX e, se viene meno questo requisito, allora tanto vale utilizzare direttamente il linguaggio della libreria prescelta. Inoltre esistono leciti dubbi sull’imparzialità del compilatore Cg, cioè sulla sua capacità di compilare gli shader in maniera ottimale anche per GPU non NVIDIA.
Queste due piccole retrospettive sono un esempio di come le librerie e le API sviluppate da un produttore di hardware che rendono le applicazioni che le utilizzano incompatibili o scarsamente ottimizzate per le altre piattaforme hardware, raramente hanno raggiunto un successo duraturo nel tempo e curiosamente i due esempi che vi ho riportato, in modalità differenti, trovano spazio proprio nel passato di NVIDIA.
Sicuramente CUDA rappresenta per NVIDIA più di una semplice scommessa visto che è in gioco il futuro della sua supremazia in ambito GPGPU e giustamente sta facendo tutto quanto è in suo potere per supportare la propria piattaforma hardware con uno strumento software estremamente valido e, al momento, ben recepito dal mercato.
Restano comunque le mie perplessità sulla longevità di CUDA: benché OpenCL e DirectCompute siano più a basso livello e non altrettanto ben supportati dagli altri produttori hardware, restano pur sempre le uniche API disponibili per lo sviluppo di software che voglia sfruttare le capacità di calcolo di qualsiasi GPU compatibile, e non solo con un logo verde marchiato sopra.
Restano comunque le mie perplessità sulla longevità di CUDA: benché OpenCL e DirectCompute siano più a basso livello e non altrettanto ben supportati dagli altri produttori hardware, restano pur sempre le uniche API disponibili per lo sviluppo di software che voglia sfruttare le capacità di calcolo di qualsiasi GPU compatibile, e non solo con un logo verde marchiato sopra.
Concordo!uno dei motivi per cui non comprerò nvidia nel breve futuro.
Mi sembra quasi la storia dei compilatori intel….
Nell’ambito del calcolo parallelo bisogna considerare che ogni MFlops/sec guadagnato è più utile e redditizio rispetto ad uno shader che supporta un determinato effetto con Cg o GLSL. CUDA ha la caratteristica di adottare immediatamente determinate features rispetto ad OpenCL (vedi 64 bit) che spesso si riflettono in immediate aumenti di prestazioni. OpenCL ci arriva sempre dopo. Inoltre la NVIDIA sta facendo un ottimo lavoro con gli strumenti di sviluppo. E poi parliamoci chiaro la NVIDIA sta investendo milioni di dollari in ricerca e sviluppo (non mi sembra che AMD stia facendo lo stesso) è anche giusto che ne tragga qualche beneficio personale. In ultimo la NVIDIA ha “inventato” il GPGPU.
nvidia ha la CUDA di paglia!
a me è bastato quello scherzo sulla fisica per le gpu, quando hanno scoperto che il codice è scritto apposta per andare PIANO sul processore..
@Alex: tutto giusto, ma a me sviluppatore gpgpu interessa di più avere un codice cross-gpu, che sia portabile su gpu nvidia, amd, ecc…
se proprio nvidia vuole può benissimo dare una mano nella definizione delle specifiche di opencl
opencl è arrivato dopo perchè il gpgpu si può dire che l’ha inventato nvidia e ha sfruttato il fatto di essere arrivata per prima….ma la situazione non sarà così per sempre
già oggi con llvm puoi generare binari ottimizzati partendo da codice opencl e infatti apple usa llvm estensivamente in macos, ma la stessa nvidia ha un compilatore opencl basato su opencl e amd idem ed è usato pure in gallium
l’api cuda veramente non ha senso nel lungo periodo
Per quanto il dubbio sia pertinente bisogna tenere anche in considerazione i mercati di riferimento che sono ben diversi, mentre gli esempi del passato fanno riferimento ad un pubblico (i videogiocatori) che sono molto eterogenei per ciò che concerne HW il discorso cambia leggermente quando si parla di utilizzi professionali specifici come nel caso di CUDA pertanto finchè non arriverà un equivalente che funziona sia su Nvidia che su AMD la situazione difficilmente cambierà.
@Luke76
I mercati sono ben diversi perché ad oggi si è intravista una potenzialità delle applicazioni GPGPU nel mercato professionale. Ma chi vieta, per esempio, alla componente di Windows che esegue la preview delle immagini in explorer di utilizzare la potenza della scheda video per eseguire la decodifica? Al momento almeno due cose: il parco hardware delle schede video che nella maggioranza dei casi non supporta il GPGPU computing (specie quelle integrate) e un sistema per l’implementazione software di queste funzionalità semplice da utilizzare quanto lo è farlo per le CPU.
Chiaramente il mio è solo un esempio, ma parecchi sono i campi in cui le GPU possono dare una mano, praticamente quasi tutti quelli in cui vengono usati le istruzioni SSE dei processori.
E’ solo questione di tempo, ma quando l’overhead dovuto alle chiamate alla GPU diventerà trascurabile e, quindi, il loro uso conveniente anche per eseguire operazioni su moli di dati non enormi come quelle dell’ambito professionale, allora sarà necessario usare un’API cross-GPU compatibile.
P.S. Resta comunque il fatto che anche AMD è nel settore delle schede video in ambito workstation. Per carità, è più indietro di NVIDIA, ma anche questo rapporto di forza prima o poi cambierà. La supremazia in un campo non è per sempre.
@collione :-)
Ma infatti se sei interessato alla portabilità puoi tranquillamente usare OpenCL. Oltretutto la NVIDIA è nel comitato che supporta OpenCL e l’esperienza di CUDA viene prima o poi inserita all’interno di OpenCL. Se invece vuoi features “fresche” che non possono essere inserite dentro OpenCL oppure provare features sperimentali puoi usare CUDA. Non credo affatto che la NVIDIA abbia interesse ad azzoppare OpenCL. La NVIDIA ha sempre ragionato in questi termini, se vuoi usare subito nuove features usa i nostri strumenti e le nostre schede altrimenti aspetta che siano standardizzati (cosa che purtroppo non può avvenire subito).
articolo molto interessante, complimenti per il tema scelto.
volevo porre qualche domanda agli esperti qui presenti:
1- mi pare di capire che in un futuro più o meno prossimo la potenza delle gpu potrebbe assumere sempre maggior rilevanza nell’esecuzione di codice. probabilmente è una domanda alla quale per rispondere bisogna avere la sfera di cristallo, ma secondo voi fino a dove ci si potrà spingere? mi sembra di capire che siamo di fronte ad una sorta di cisc vs risc atto secondo, solo che questa volta possono coesistere
2- conosco un pò cuda, e per il motivo citato dall’articolo mi sono interessato anche a directcompute ma non sono riuscito a trovare nessuna guida decente e soprattutto da quel poco che ho letto mi sembra che solo per inizializzare la chiamata alla gpu servano 10 righe di codice, quando su cuda ne serve una. ora, per fare un paragone, mi pare che negli ultimi anni programmare sia diventato più alla portata di “tutti” utilizzando linguaggi come C# preferendoli a C++/C (nonostante le differenze in termini di prestazioni suppongo si facciano ancora sentire), non potrebbe prospettarsi uno scenario in cui (mantenendo fuori il discorso chiusura di cuda rispetto ad altre aziende) directcompute ed opencl soddisfino un’utenza altamente professionale, mentre cuda o qualche framework sviluppato su di essa vada a rispondere alle richieste dei programmatori incapaci come me?
3- premetto di opencl ho giusto letto la pagina su wikipedia, ma rispetto a directcompute è più maneggevole?
4- visto che opencl, directcompute (e anche cuda) sono sostenuti da colossi dell’industria informatica, sul quale a parer vostro converrebbe orientarsi?
OpenCL dovrebbe essere meglio supportato. Considera che esistono binding sia per .NET (http://www.opentk.com) che per Java e quindi è possibile utilizzarlo serenamente senza entrare nei meandri nelle chiamate C++.
Non so onestamente fin dove si spingeranno. A mio parere la diffusione del GPGPU computing dipende essenzialmente dalle prestazioni delle API e dalla loro facilità d’uso. Se questi obiettivi verranno raggiunti, si potrà integrare queste chiamate a molte operazioni oggi delegate alla CPU. Considera anche che stanno arrivando sul mercato CPU con GPU integrata :)
@n0v0: non è corretto quello che riporti.
E’ vero che Physix utilizza la vecchia FPU x87 in assenza di GPU nVidia, ma questo si verifica perché il codice NON è mai stato portato sulle SSE.
Per quanto riguarda l’articolo, conosco CUDA, ma non mi piace. Lo trovo troppo complicato. Poi è legato mani e piedi a nVidia, per cui non lo vedo bene.
Su OpenCL e DirectCompute mi astengo, non avendo modo di documentarmi.
P.S. Io preferisco lavorare con le estensioni SIMD “tradizionali”.
appunto, quindi – correggi se sbaglio – è scritto ah hoc per fare faville sulle gpu, infischiandosene della cpu. Usano due pesi e due misure. Se l’ avessero ottimizzato anche per i processori, magari avrebbero perso comunque ma con molto meno distacco..
non è corretto. Anch’io sono più veloce di Cipollini se vado in discesa e lui in salita, non so se mi spiego.. ;-)
nVidia collabora tantissimo con le software house nella programmazione, perchè è suo interesse che si diffonda molto visto che cosi incassa solo lei;
di certo non ha lo stesso interesse di foraggiare OpenCL visto che ne gioverebbe anche ATI.
In campo professionale OpenCL non è che sia poi cosi utile, visto che il 90 % del mercato è QUADRO,visto che le schede professionali ATI non sono all’altezza della controparte, e visto che ATI non investe quasi nulla nel professionale.
uno standard open posiamo anche usarlo come carta igenica se non è supportato, e CUDA sicuramente per ora rappresenta una garanzia; voglio dire basta guardare i programmi piu importanti su cosa si sono appoggiati, es. Mental Ray e Adobe
un mio piccolo contributo alla discussione: http://www.dbfinformatica.com/index.php?option=com_content&view=article&id=154:le-gpu-nel-mercato-dellutile-e-del-dilettevole&catid=44:blog&Itemid=58
cmq sia prima di mental ray sarebbe il caso di considerare Octane
Suppongo che i vertici di Nvidia sperino di rendere CUDA uno standard de facto, da rendere implementabile anche su schede concorrenti (possibilmente con prestazioni inferiori) se il mercato richiederà insistentemente il codice multipiattaforma! Che poi ci riescano, è tutt’un altro paio di maniche…
Mah non sono troppo convinto. Cuda è un grosso investimento per NVIDIA ma anche OpenCL potrebbe andare bene alla casa di Santa Clara purché venga venduto il loro hardware grafico.
Se guardiamo al mercato professionale, l’87.5% delle schede è NVIDIA. Anche cambiassero le API, se lo scenario fosse lo stesso non sarebbe affatto un dramma per la società.
Chiaramente l’esperienza ci insegna che le cose possono ribaltarsi nel giro di pochi anni ma AMD non sta affatto investendo in OpenCL come dovrebbe mentre NVIDIA fa parte del consorzio che lo sviluppa dall’inizio (prima di ATI).
Siamo davvero sicuro che OpenCL sia l’opposto di CUDA. Non sono affatto d’accordo. Penso piuttosto che abbiamo uan società con scarse capacità di manovra negli investimenti (AMD) che si sta trincerando nei settori tradizionali. Perché deve recuperare competitività anche lì. Ma AMD sta lasciando l’ultramobile a NVIDIA e Intel… per non parlare del professionale, anche se pare che si stiano impegnando più del passato.
Se NVIDIA rimane sola nel mondo del GPGPU può sviluppare le sue API proprietarie o forse buttarle nel bidone e continuare con OpenCL, se manterrà il predominio saranno comunque soldi spesi bene.
Conclusioni sbagliate.
Il codice Physx che gira su CPU è stato acquistato da NVIDIA da AGEIA e poi lo ha convertito per farlo girare su GPU. Non credo che abbia mai messo mano al codice x86 della libreria, sebbene Physx sia stato implementato anche per le console.
Non capisco questo astio nei confronti di una azienda che spende più nello sviluppo di SW a supporto dei propri prodotti che nell’HW stesso e praticamente ha costruito il GPGPU da zero. Dovrebbe regalare i propri milionari investimenti ai concorrenti che fanno solo finta di essere interessati alla cosa dato che richiede tempo e denaro per ottenere lo stesso risultato?
Perchè mai un laboratorio che ordina un super computer dovrebbe essere interessato ad un linguaggio open invece che a un linguaggio proprietario? Spesso i laboratori e i centri di ricerca si autocostruiscono i software, e visto che GPGPU è Nvidia non vedo perchè dovrebbero lamentarsi di CUDA..
Non conosco nessuno studio professionale che faccia CAD 3D, analisi ad Elementi finiti, simulazioni numeriche che non monti una quadro… Nvidia sta spingendo su un mercato che ha grandi potenzialità, istituti di ricerca, studi di progettazione, centri di calcolo. Del calcolo distribuito tra la gente comune non gliene frega niente, nè degli utenti che usano il PC per fare mille cose… Avete idea di cosa voglia dire in termini economici e di ricerca poter fare in un giorno una simulazione che prima richiedeva due settimane?
Sono d’accordo con Aldo, OpenCL puo’ avere senso ad esempio per Microsoft e per chi vuole raggiungere il massimo bacino di utenti, ma per applciazioni professionali / supercomputer la cosa e’ molto diversa. Se sono un centro di ricerca e ho appena speso 300 milioni di dollari per comprare un nuovo supercomputer con qualche decina di migliaia di CPU e GPU, e spendero’ 20 milioni di dollari l’anno di boletta di elettricita’, mi frega abbastanza poco di sviluppare un software “portabile su diverse piattaforme”, voglio scrivere qualcosa di superottimizzato per spremere l’ultimo watt dal mio sistema.
E se il 90% del mercato professionale e’ in mano a Quadro, se fossi Adobe non mi preoccuperei troppo di ottimizzare Photoshop “solo” per CUDA (cosi’ come ha fatto Autocad).
Un centro di ricerca che spende una barca di soldi per un supercomputer non si fa neanche il problema del cross-platform. Scrive il codice per quella macchina, lo testa su quella macchina e lo ottimizza su quella macchina. Se poi la macchina muore il codice viene riscritto per girare su un’altra macchina. Purtroppo però non esistono solo quelli, e non è vero neanche che tutto il mercato professionale è in mano alle Quadro, conosco parecchie persone che su computer da lavoro montano schede di tipo gaming, per il semplicissimo motivo che usano software che girano esclusivamente su CPU. Spendere 4000 euro per una scheda video professionale su un computer sul quale girerà un software FEM o un software di analisi fluidodinamica non ha senso. Ed è su questi computer che si deve giocare la partita. Se dovessi scrivere un software FEM che gira su GPU, secondo voi converrebbe scriverlo in CUDA, giocandosi la possibilità di installarlo su un parco hardware rosso, oppure in OpenCL, in modo da poterlo utilizzare (ipoteticamente) anche su GPU Intel?
Per questo preferisco nettamente Open CL a CUDA, anche se ho i miei dubbi che potrà mai prevalere, visto che l’unica casa che ha interesse a premere è la Apple; MS ha il suo Direct Compute, Nvidia ha CUDA, AMD non ha i soldi, per Intel è peggio di Satana, alla fine non ci sono molti colossi che hanno interesse a spingere sul prodotto Open.
mettiamo il caso però che dopo qualche anno devi cambiare il tuo super computer con il tuo super spftware super ottimizzato ed il nuovo super computer 100 volte più potente non è più compatibile con CUDA. ti tocca ricominciare da capo a programmare il tuo super software super ottimizzato ed addio a bei tanti miliono di dollaroni.
x Nessuno
non ce l’ ho con nvidia ma con chi bara
http://www.tomshw.it/cont/news/physx-a-marce-ridotte-con-la-cpu-nvidia-bara/26145/1.html
chiamala pubblicità fasulla o come ti pare… a me dà fastidio. E mi fà riflettere anche sulla qualità del prodotto in sé: se è già buono perchè truccare la carte? Oppure fosse che è una bella fumata negli occhi, giusto per vendere un po’ di più?
Quando cambi un computer del genere comunque per forza devi riscrivere un sacco di roba. L’hardware e’ tutto diverso, e’ difficile chiedere compatiblita’ a quei livelli. Ad esempio, se tra 10 anni lo cambiano con un qualcosa che non esiste nemmeno oggi? Magari ci saranno chip con manycore eterogenei e hai bisogno di un nuovo paradigma di programmazione. Non puoi dire “scrivo in OpenCL che cosi’ e’ compatibile, e se le prestazioni peggiorano fa niente”, perche’ quei supercomputer le prestazioni sono tutto.
Infatti oggi un po’ di supercomputer cominciano a impiegare massicciamente GPU e roba scritta in CUDA e non si lamentano. Quando Intel mandera’ fuori il Larrabee per HPC, dovranno comunque riscrivere il codice per quello — non c’e’ verso che Intel si pieghi a implementare CUDA o OpenCL per la loro roba, anche perche’ Larrabee ha un’architettura diversa.
@n0v0: continui a non voler capire. Non c’è nessuno che bara.
Come ti avevo già detto, quando nVidia ha comprato Ageia ha soltanto aggiunto il supporto alle sue CPU, lasciando il resto del codice com’era.
Barare è un’altra cosa. Lo avresti potuto dire se avesse appositamente aggiunto codice per boicottare le altre GPU. Cosa che NON ha fatto.
Lo strumento è suo, perché l’ha pagato profumatamente. Non puoi pretendere che aggiunga anche il supporto ad altre GPU o altre CPU, perché questo ha un costo, e tra l’altro gli si ritorcerebbe contro.
Mi sembra un parallelelismo forzato, le api Glide erano destinate ad un mercato orizzontale, CUDA benché molto affascinante e promettente è indirizzato principalmente a un target verticale. Può essere affascinante per un utente consumer poter comprimere un video full-hd in pochi secondi o minuti utilizzando la potenza della scheda video, ma non è determinante.
Non baserà su questo i criteri principali della scelta dell’hardware.
Diversamente, un’azienda che ha bisogno di soluzioni computazionali proprietari e ad-hoc, si potrà dotare di un sistema nvidia oppure ibm oppure sun o cazzoneso, dove il sistema è composto da hw e sw ad-hoc, e nvidia la sua bomba da sparare ce l’ha: rapporto prezzo/prestazioni/consumi imbattibile.
Quando il mercato consumer sarà pronto per il gpgpu verrà fuori qualche standard.
Purtroppo non è così semplice come si crede. Tutte le critiche relative al fatto che CUDA sia proprietario vengono da gente che è limitata a pensare che il mercato professionale e in particolare quello scientifico/industriale sia uguale a quello dei videogiochi.
Lo sviluppo di certe applicazioni non richiede la compatibilità tra architetture diverse. Pensate a quello che viene sviluppato per i super computer CPU-only. Perché mai uno dovrebbe sviluppare per il RoadRunner che è un “accrocchio” basato su architetture x86 e Cell? Eppure c’è chi lo fa. E sa benissimo che la sua applicazione anche se scritta in ANSI C super portabile su tutte le architetture del mondo in verità non potrà mai funzionare su nessuna altra macchina.
Avere un “standard” non basta. Serve che in primis lo standard garantisca performance adeguate su tutte le architetture su cui gira (in verità richiede che tutte le architetture disponibile abbiano delle prestazioni accettabili per la propria applicazione, ma questo è un discorso diverso) e sopratutto richiede un supporto più che adeguato per lo sviluppo dell’applicazione.
Non crediate che gli applicativi che costano milioni di euro per essere sviluppati e che richiedono che i risultati forniti siano “sicuri” siano sviluppati in maniera indipendente senza il supporto di colui che fornisce il sistema di sviluppo. Ora, mettiamo anche che OpenGL diventi sufficientemente maturo da rivaleggiare con CUDA (prima o poi lo diventerà comunque). Chi lo adotterebbe per lo sviluppo di una applicazione HPC quando parallelamente viene offerto un supporto completo tramite CUDA? Voi direte, ma NVIDIA può dare supporto ad entrambi. Giusto. Ma se mi devo rivolgere ad NVIDIA per forza (dato che per ora non ‘è una controparte della concorrenza) siamo punto e a capo. Userò necessariamente l’HW NVIDIA che NVIDIA mi farà sfruttare al max ottimizzando i miei algoritmi per tale architettura. E quindi, dove è il vantaggio di OpenGL?
OpenGL sarà un “tappa buchi” per il GPGPU commerciale, quello che useranno applicazioni come codec o per montaggi video ed elaborazione di immagine generica, dove le performance per Watt non contano.
Per il mercato HPC, quello vero, che CUDA sia chiuso, aperto, uno standard o meno non può interessare di meno. Al max la preoccupazione è che CUDA sia e rimanga compatibile con le architetture future proposte da NVIDIA stessa onde evitare problemi in caso di aggiornamenti (G200->Fermi per esempio). Ovviamente, anche un upgrade ad una architettura nuova richiede l’aggiornamento del codice perchè sfrutti meglio le nuove caratteristiche e potenzialità offerte. E qui si ritorna a chiedere aiuto al supporto del fornitore del sistema di sviluppo/HW per ottenere il max rapporto prestazioni/Watt. Che è l’unica cosa che conta.
Non tutti i centri di ricerca si possono permettere supercomputer “in casa” e quindi si stanno sempre più affidando al calcolo distribuito (pure il CERN). E per il calcolo distribuito il must è OpenCl, che può girare su una varietà di hw differente. Un esempio?
http://boinc.fzk.de/poem/ . Hanno un codice per cpu che stanno travasando in OpenCL per girare, un domani, anche su GPU.
Nvidia già 3 anni fa mando’ i suoi evangelist presso tutti i centri di calcolo d’europa o quasi che “convinsero” ad acquistare un sistema tesla…il bello è che una volta acquistato chiedano altri soldi per lo sviluppo e l’ottimizzazione delle applicazioni che sta a significare che per veder girare un algoritmo devi cacciare i soldi, perchè se no il compilatore continuava a darti errori o semplicemente il software andava in loop sulla scheda senza il benchè minimo messaggio d’errore…
alcuni centri di ricerca hanno sborsato diverse decine dimigliaia di euro per vedere funzionare in maniera decente e comunque lontana dalle prospettive paventate da nvidia…
chi non ha sborsato i soldi si è trovato un bel soprammobile di nome tesla o poco piu’…
adesso nvidia finalmente ha prodotto un compilatore CUDA x86 che se permetterà la completa portabilità del codice su scheda tesla potrà finalmente dopo 3 anni mantenere almeno in parte le promesse sperate…in caso contrario sarà l’ennesima azione di marketing.
per quanto riguarda le OpenCL sono librerie che di fatto non hanno un buon supporto hardware ed il cui sviluppo ha uno stato embrionale sia per quanto riguarda le specifiche sia per l’implementazione…
un accenno a chi paventava i render engine che si basavano su GPGPU, volevo dire le nuove tecnologie consentono di calcolare qualunque immagine di qualunque complessita in base esclusivamente alla risoluzione dell’immagine finale…
essenzialmente 1 poligono per ogni pixel dell’immagine renderizzare quindi un’immagine 1000×1000 pixel serve 1 milione di poligoni, in quanto il preprocessing della scena fa il resto….si tratta di sistemi di approssimazione della diffusione dei segnali elettromagnetici nello spazio che sembrano funzionare bene per le applicazioni grafiche ed in parte sono implementati in alcuni render engine, quindi il vantaggio prestazionale non è solo imputabile alle prestazioni delle GPGPU ma anche ai nuovi algoritmi di calcolo…
x Cesare di Mauro
si, il senso è chiaro. Io la vedo da un lato leggermente diverso, ma tant’ è..
Se AMD fosse davvero interessato al GPGPU potrebbe tranquillamente puntare su OpenCL ed iniziare a tirarsela con la NVIDIA. Basterebbe far vedere che OpenCL su AMD è più performante sulle proprie schede video. Insomma come si fa con OpenGL o DirectX. Questo basterebbe a NVIDIA per mettergli un pò di pepe nel popò ed a mollare CUDA. Se AMD non lo fa forse non è interessata.
Secondo me la supremaza di nvidia nel mercato professionale avrà vista breve. AMD portarà fusion anche negli opteron e Intel non starà a guardare, avere tutto integrato nella cpu porterà in svantaggio Nvidia su performance/watt e quindi ad un mercato più eterogeneo.
Scusatemi la franchezza, ma il commento di Castaldo è una delle poche cose sensate dette in tutto il tread: “Supermazia” “L’ha fatta prima Nvidia” etc sono concetti assolutamente risibili.
Davvero Nvidia ha inventato il GPGPU?
Non penso affatto.
Già su Amiga operazioni standard erano spesse affidate al chipset invece che al Motorola 600×0 di turno.
Il concetto di relegare ad altri “coprocessori” una parte del lavoro prima svolto dalla sola GP CPU è vecchio come la nascita dei processori stessi.
Nvidia ha solo puntato denaro ed investimenti in un mercato che in questi anni la sta vedendo leader.
Anche la Xerox lo aveva fatto con l’interfaccia Point & click … e conta qualcosa nell’ambito degli OS con interfaccia a, scusatemi lo sfottò, “windows” ?
Attualmente l’unica realtà è che Nvidia ha solo quel segmento di mercato su cui puntare ed avere margini di guadagno interessanti in rapporto agli investimenti: Intel ed AMD no.
Poi che delle società utilizzino software proprietario per un certo periodo è assolutamente normale, ergo CUDA andrà avanti ancora per un bel pò.
Ma, come sempre, quando uno standard multiplatform e più open raggiunge un certo tetto di maturità, la componente closed viene in prima istanza scartata: è il mercato ed andrà sempre così. Una cosa è trovare ed assumere dei programmatori che conoscono le DirectX e che vedono Direct Compute come una naturale componente dell’ambiente MS, altro è cercare dei programmatori legati allo sviluppo di una soluzione proprietaria e chiusa utilizzabile su HW di una sola compagnia, che dopo il flop della serie Fermi solo 6 mesi fa era data sukk’orlo della bancarotta.
Già oggi è noiosissimo districarsi tra 300 linguaggi, librerie, API etc … figurarsi se un programmatore si butta su un ambiente legato all’hardware di una sola società: lo farà finchè quella società lo finanzia e lo supporta (cosa che Nvidia fa proprio per questo … altrimenti qui non staremmo proprio a discutere … non è che Nvidia supporta gli sviluppatori su CUDA e Physix just for fun, lo fa sempre in un’ottica di guadagno)
My 2 cents
Una osa è programmare per piattaforme cunsumer, un’altra è per sistemi industriali dove la cross portabilità non ha alcun senso.
Pernsa semplicemente di dover progettare una macchina per l’analisi delle immagini di una risonanza magnetica. Credi che ci si ponga il dubbio sul fatto che il SW debba girare indistintamente su GPU NVIDIA o AMD? Il SW è fatto e pensato per un HW fatto e finito e quello dovrà essere per gli anni a venire (salvo aggiornamenti) ma che il SW debba adeguarsi ad un futuro HW non ha propri senso. Il mercato industriale, come quello scientifico non vivono su Windows e le DirextX. Vivono su un prodotto fatto e finito che deve necessariamente fare al meglio il proprio dovere per lungo tempo.
Poi che nvidia fosse sull’orlo del fallimento per via del ritardo di Fermi non so dove tu l’abbia sentita. Credo sia la barzelletta più divertente che sia stata presa come fatto. E solo uno sprovveduto può prendere la cosa per buona. Dovresti solo dare uno sguardo ai conti di NVIDIA vs quelli di AMD per verificare che se la seconda non è ancora fallita, la prima non potrà farlo per parecchio tempo a venire.
Solo per chiarirti la situazione, NVIDIA in un trimestre non proprio felice per via del ritardo ha fatto un debito di 200 milioni di dollari. Che non son pochi, ma tenendo conto del periodo sfortunato non sono certo un dramma per un’azienda che ha in cassa qualche miliardo di dollari da investire in nuovi progetti.
AMD nel suo miglior periodo di vendite con 6 mesi di vantaggio sull’avversaria ha fatto oltre 120 milioni di debiti. Il reparto grafico, sebbene abbia goduto di prezzi gonfiati e concorrenza zero ha avuto un utile di, pensa un po’, 100 milioni di dollari! L’azienda ha 3 miliardi e rotti di dollari di debiti da pagare. Se nel periodo migliore fa questi numeri, non oso pensare appena la situazione si normalizza.
Se c’è una azienda su cui non sperare di avere del supporto nel futuro, quella certamente non è NVIDIA. E l’HPC non se ne fa niente delle GPU integrate nei processori. SI parla di ordini di capacità di elaborazione molto diversi. SOlo prodotti commerciali possono prendere in considerazione l’uso di OpenCL per essere cross platform compatibile. Sempre che la cosa abbia un senso in un mercato che per il 90% è dominato da HW NVIDIA con prestazioni più che doppie rispetto alla concorrenza (che per ora si preoccupa solo del mercato dei videogiochi).
Secondo me comunque il mio intervento e il discorso GPGPU/Cuda non va visto nell’ottica dello sviluppo di sistemi custom destinati magari ad elaborazioni particolari come ad esempio i vari super computer. E’ evidente che in questi particolari ambiti la cross-compatibilità dell’API a livello hardware non interessa a nessuno perché si allestisce un sistema, si sviluppo il software che girerà solo su quel sistema e amen.
Il punto è che tra quanto ho appena detto e il mondo prettamente consumer, esiste il mondo dei professionisti che fanno uso di software assolutamente commerciale come, ad esempio, Photoshop, 3DStudio Max, Maya, ecc… e in questi ambiti lo sviluppo usando Cuda che non è compatibile con hardware diverso da NVIDIA è inevitabilmente un punto debole che è destinato a far preferire API come OpenCL e DirectCompute. Anche il fatto che NVIDIA abbiamo il 90% del mercato professionale è poco rilevante: anche 3dfx aveva la stragrande maggioranza del mercato dei videogamer e il 99% dei giochi usavano Glide, ma ciò non ha impedito alle software house di adottare anche altre API (e poi solo queste ultime) quando è diventato maturo Direct3D.
Il futuro di cuda è sicuramente molto più roseo di opencl: cuda è legato ad una azienda economicamente potentissima, che a meno che l’economia non si affossi totalmente ritornando al medioevo non fallirà di certo nei prossimi anni, e continuerà a sostenere cuda e le sue schede, che prevedono una garanzia di 10 anni con assicurazione di reperibilità di schede sostitutive nel giro di 24 ore, questo significa che se ti affidi ad nvidia sei praticamente sicuro di poter portare avanti il tuo progetto per diversi anni almeno. Opencl è solo uno standard, nulla dice che ati tra uno o due anni esca definitivamente dal mercato professionale e opencl muoia con lei, sebbene le schede nvidia supportino anche opencl, quindi scegliere opencl non è per nulla più lungimirante o rassicurante.
Il raffronto con 3dfx non regge: se fai un gioco e i videogiocatori hanno computer con diverse schede grafiche è chiaro che hai interesse ad adottare un linguaggio open, in maniera che il tuo videogioco giri bene su tutti i pc. Se fai un programma per un laboratorio di calcolo che si occupa di previsioni del tempo o scrivi un programma per il puntamento dei missili di un caccia o dei cannoni di una nave da guerra non è che quel software lo devi vendere a qualcun altro, quindi se chi te lo commissiona usa schede nvidia è logico usare cuda.
Probabilmente nei prossimi anni si arriverà a un monopolio di fatto, con ati che rimarrà l’unica a produrre schede video per videogiochi e nvidia che si concentrerà solo sul settore professionale, che già costituisce i due terzi del suo (enorme) fatturato, ormai le due compagnie non hanno più interesse a concentrarsi in ambiti che gli rendono sempre meno e in cui il gap con gli avversari si allunga sempre di più e si avvicina a diventare quasi incolmabile.
Per rispondere all’ultimo commento: a nvidia del mercato professionale per così dire di “basso livello”, cioè di chi usa photoshop o maya, interessa poco. I clienti che rendono veramente sono i laboratori di ricerca e le commissioni statali per la fabbricazione di armi: sono commissioni nell’ordine delle decine o centinaia di milioni di dollari, l’importante per nvidia è poter firmare questo tipo di contratti, il fatto che poi i programmi di grafica e di editing video supportino le sue schede è certamente una cosa in più, ma se anche dovesse dividere quel mercato a metà con ati non sarebbe una grossa perdita economica. E probabilmente in quell’ambito in futuro succederà proprio questo, ma alla fine non credo che nemmeno questo colpirà così fortemente cuda, alla fine aziende come adobe e autodesk hanno l’interesse e le risorse per supportare pienamente due diversi tipi di schede e di linguaggi, quindi probabilmente cuda non sarà abbandonato ma sarà implementato nei prossimi anni anche supporto per le altre gpu.
Volevo solo far porre l’attenzione alla questione “open” vs “portabile”. Glide non stata sostituita con una libreria open, le DirectX non lo sono di certo, ma con una libreria disponibile indifferentemente su più HW diversi in modo da coprire un mercato più vasto.
In questo caso siamo nella stessa situazione: abbiamo una libreria “chiusa” ma che copre il 100% del mercato HPC, il 90% di quello professionale e il 50% di quello consumer.
Prima che ciò possa accadere è però necessario che sul mercato sia disponibile HW dalle capacità uguali o superiori ai prodotti NVIDIA. Il limite delle Glide non era certo il fatto che funzionassero solo su HW 3Dfx (in verità erano anche emulate sulle schede NVIDIA) ma che la concorrenza era già passata ai 32bit nel 3D quando ancora 3Dfx era ferma ai 16bit (io ho avuto una Voodoo3000 e la qualità non era certo pari a quella disponibile con la TNT2 sua diretta concorrente).
Io ho delle perplessità a riguardo dell’uso delle GPU come GPGPU.
Ho letto più di un commento, da parte di esperti di vari settori dell’informatica (hardware e software),che sostenevano che le attuali cpu dispongono di tutta la potenza neccessaria per svolgere la stragrande maggioranza delle applicazioni, e in ambito “home” sono anzi quasi sempre sottoutilizzate.
A riguardo vorrei riportare la risposta di “Vasik Rajlich” (programmatore di Rybka, software campione del mondo) alla mia domanda su un possibile utilizzo di CUDA per scrivere e potenziare un programma di scacchi: “i processori di oggi offrono tutta la potenza neccessaria. La tua idea richiederebbe un’enorme mole di lavoro per ottenere un’ininfluente aumento di potenza di gioco”. Un’altro guru della programmazione, sosteneva che secondo lui i processori di oggi avevano tutte le potenzialità neccessarie e usare le GPU per compiti non grafici, e che CUDA fosse alla fine solo un modo di cercare di vendere più GPU.
Poi dovreste sottolineare di più, che le GPU possono essere utili non per tutte le applicazioni in parallelo, ma rendono su elaborazioni con poche istruzioni o poco complesse ma ripetute in enormi quantità.