PDA

View Full Version : CUDA notizie ?


Albitexm
19-06-2008, 20:41
Sono interessato al nuovo linguaggio di programmazione delle GPU NVidia : "CUDA".
In particolare vorrei provare a scrivere un codice per usare la GPU per aumentare le prestazioni dei chess engines .
Qualcuno conosce qualcosa di CUDA ? :help:

eVuGEGA
19-06-2008, 20:49
Cuda non e' propriamente un linguaggio di programmazione, e piu' un sdk basato su C ma con delle estensioni.

Tutto cio' di cui hai bisogno lo puoi trovare qui (http://www.nvidia.com/object/cuda_home.html)

Personalmente ho implemetato anche un crivello di eratostene sotto CUDA, ma adesso non c'e' l'ho sotto mano (anche se la mia implementazione e' orribile)

marco.r
19-06-2008, 23:10
L'idea e' molto interessante (soprattutto dal lato performance), anche se effettivamente non e' banale programmarci. Al lavoro ce la stiamo comunque studiando un po'.

banryu79
20-06-2008, 10:11
E c'è perfino la possibilità di accedere alle API da Python... [PyCuda]
Certo che la biscia è dappertutto.

cdimauro
20-06-2008, 12:42
SLURP! CUDA lo seguo da tempo, ma proprio perché troppo legato al C, non l'avevo nemmeno studiato.

Adesso il discorso cambia. :cool:

banryu79
20-06-2008, 12:55
cut...

Bang!
Beccato :D

@EDIT:

eh, ma i kernel vanno sempre scritti in cuda .

Sisi, a me interessava solo "seccare" cdimauro :D

marco.r
20-06-2008, 13:07
E c'è perfino la possibilità di accedere alle API da Python... [PyCuda]
Certo che la biscia è dappertutto.

eh, ma i kernel vanno sempre scritti in cuda :p.

marco.r
20-06-2008, 13:55
Bang!
Sisi, a me interessava solo "seccare" cdimauro :D
:asd:

Albitexm
20-06-2008, 20:59
L'idea e' molto interessante (soprattutto dal lato performance), anche se effettivamente non e' banale programmarci. Al lavoro ce la stiamo comunque studiando un po'.

Certo che modificare un codice nativo di un engine , per farlo lavorare con CUDA non è propio facilissimo .
Si potrebbe anche cercare, di velocizzare le istruzioni generalmente più usate da tutti gli engines . Ma anche questo non è la cosa più banale .
Il fatto è, che io ho ricevuto un post da Vasik Rajlich (l'autore di Rybka), sul suo forum , in cui dichiarava che : " l'imponente mole di lavoro , neccessaria a realizzare la mia idea , non giustifica l'esiguo aumento di elo del motore che si otterebbe". Ma io non sono molto convinto di questa affermazione :muro: , e comunque vorrei sperimentare . Potrebbe essere in ogni caso un modo per imparare a usare CUDA .

Albitexm
20-06-2008, 21:06
Cuda non e' propriamente un linguaggio di programmazione, e piu' un sdk basato su C ma con delle estensioni.

Tutto cio' di cui hai bisogno lo puoi trovare qui (http://www.nvidia.com/object/cuda_home.html)

Personalmente ho implemetato anche un crivello di eratostene sotto CUDA, ma adesso non c'e' l'ho sotto mano (anche se la mia implementazione e' orribile)

Grazie per il link .
Secondo la tua esperienza , con questo CUDA si riesce a spremere queste GPU ?

variabilepippo
20-06-2008, 21:19
Non so quanto siano attendibili ed in che modo siano stati calcolati i miglioramenti, ma in questa pagina (http://www.nvidia.com/object/cuda_home.html) (sito Nvidia) vengono riportati gli speed-up per alcuni progetti, si va dal 2x al 270x. :eek:

cdimauro
21-06-2008, 09:25
Bang!
Beccato :D

@EDIT:

Sisi, a me interessava solo "seccare" cdimauro :D
eh, ma i kernel vanno sempre scritti in cuda :p.
:asd:
Cattiviiiii!!! :cry:

Comunque, quando ho studiato elaborazione delle immagini all'università (una dozzina d'anni fa, come minimo :asd:) per "kernel" il professore soleva indicare la matrice di convoluzione da applicare all'immagine.
Se così fosse, non capirei il perché ciò non sia fattibile con Python, che offre classi adeguate per rappresentare array di dati omogenei e "standard", ma ho il non vago sospetto che qui per "kernel" intendano qualcosa di diverso.
Certo che modificare un codice nativo di un engine , per farlo lavorare con CUDA non è propio facilissimo .
Si potrebbe anche cercare, di velocizzare le istruzioni generalmente più usate da tutti gli engines . Ma anche questo non è la cosa più banale .
Il fatto è, che io ho ricevuto un post da Vasik Rajlich (l'autore di Rybka), sul suo forum , in cui dichiarava che : " l'imponente mole di lavoro , neccessaria a realizzare la mia idea , non giustifica l'esiguo aumento di elo del motore che si otterebbe". Ma io non sono molto convinto di questa affermazione :muro: , e comunque vorrei sperimentare . Potrebbe essere in ogni caso un modo per imparare a usare CUDA .
A me dei giochi non frega nulla: è da quando sono nati gli shader che le GPU m'interessano per poterci fare qualcosa di diverso dal renderizzare immagini. :D

Magari questa è l'occasione buona per farlo in maniera semplice, finalmente. :)

marco.r
21-06-2008, 10:32
Certo che modificare un codice nativo di un engine , per farlo lavorare con CUDA non è propio facilissimo . z
Si potrebbe anche cercare, di velocizzare le istruzioni generalmente più usate da tutti gli engines . Ma anche questo non è la cosa più banale .
Il fatto è, che io ho ricevuto un post da Vasik Rajlich (l'autore di Rybka), sul suo forum , in cui dichiarava che : " l'imponente mole di lavoro , neccessaria a realizzare la mia idea , non giustifica l'esiguo aumento di elo del motore che si otterebbe". Ma io non sono molto convinto di questa affermazione :muro: , e comunque vorrei sperimentare . Potrebbe essere in ogni caso un modo per imparare a usare CUDA .

Sull'entita' dell'aumento e' difficile dire. Finche' sono micro-benchmark e' facile far pompare operazioni alla GPU, quando gli algoritmi sono piu' complessi il discorso puo' essere diverso. Sull'imponente mole di lavoro ha ragione l'autore. Proprio per la struttura di CUDA per ottenere buone performance bisogna spesso ristrutturare profondamente il codice, e partendo da una base preesistente puo' essere difficile.

Tommo
21-06-2008, 10:42
Col CUDA, sarebbe possibile bypassare DirectX e OpenGL e far girare il proprio motore grafico al livello di GPU?
Ho letto che Epic vuole implementare un render di questo tipo, a loro detta un passo avanti enorme per flessibilità e velocità...
sarà vero?

Il Fek ha detto che non è possibile, dato che al contrario i developers puntano all'astrazione.
Ma se facesse guadagnare anche solo un 10% di prestazioni credo che in ricavi converrebbe :D

marco.r
21-06-2008, 11:01
Cattiviiiii!!! :cry:

Comunque, quando ho studiato elaborazione delle immagini all'università (una dozzina d'anni fa, come minimo :asd:) per "kernel" il professore soleva indicare la matrice di convoluzione da applicare all'immagine.
Se così fosse, non capirei il perché ciò non sia fattibile con Python, che offre classi adeguate per rappresentare array di dati omogenei e "standard", ma ho il non vago sospetto che qui per "kernel" intendano qualcosa di diverso.


Nel caso di CUDA con kernel si intende un elemento di computazione che va poi eseguito in parallelo sulla GPU. Ad esempio se volessi effettuare una somma di vettori in parallelo (la cosa piu' banale che mi viene in mente :p) bisogna scrivere prima un kernel piu' o meno nel modo seguente

__global__ void sum( float* u, float* v, float* w )
{
int bs = blockDim.x;
int bx = blockIdx.x;
int tx = threadIdx.x;

w[ bz*bs + tx ] = u[ bx*bs + tx ] + v[ bx*bs + tx ];
}

In pratica ad ogni elemento processore viene assegnato un indice diverso su cui operare, e quando dalla macchina si esegue sum(u,v,w) e' il driver della scheda video che provvede a schedulare opportunamente le esecuzioni in parallelo/sequenza.
Il motivo di tutti quegli indici strani e' che l'esecuzione dell'intera operazione viene suddivisa in blocchi i quali a loro volta vengono suddivisi in thread (che sono gli elementi che eseguono in parallelo). Il motivo di questa suddivisione e' data dal fatto che thread appartenenti allo stesso blocco condividono della memoria (chiamata shared appunto) locale molto piu' veloce di quella globale.
La gestione degli accessi alla memoria e' probabilmente uno degli elementi piu' cruciali per le performance in CUDA. Devi non solo minimizzare quelli alla memoria globale, ma pure organizzare gli accessi da parte di thread differenti in modo opportuno: se thread "vicini" (come indice) leggono usano locazioni di memoria in modo opportuno la scheda grafica riesce ad effettuare diverse letture in batch, ottimizzando la banda.
Spero che come riassunto offerto da un profano (ho cominciato a giocare con CUDA il mese scorso a tempo perso) possa essere abbastanza chiaro :p.
Come puoi ben capire scrivere i kernel e' un'operazione cruciale, tediosa (nel senso che il modo di procedere e' abbastanza chiaro) e che genera codice illeggibile (secondo me) a causa della marea di indici presenti :D, ed e' per questo che prima mi lamentavo che i kernel bisogna scriverseli :P. Idealmente io vorrei essere in grado di scriver equalcosa del genere

cudamap( lambda x,y,z : z = x + y, u,v,w)

Visto che tutte le informazioni necessarie per generare il codice piu' sopra ci sono. Ovviamente in python e' un lavoraccio improponibile, pero' in altri linguaggi dotati di macro potrebbe essere gia' piu' ragionevole (noi stiamo facendo delle prove con CL).
Ho volutamente tralasciato il problema di piu' alto livello, ovvero di come organizzare l'algoritmo in modo parallelo, ma e' un argomento che merita molto piu' spazio e su cui non mi espongo :D :p.

cdimauro
21-06-2008, 11:06
Sei stato chiarissimo, grazie.

A questo punto....
del CUDA
per me. :p

marco.r
21-06-2008, 11:07
Col CUDA, sarebbe possibile bypassare DirectX e OpenGL e far girare il proprio motore grafico al livello di GPU?
Ho letto che Epic vuole implementare un render di questo tipo, a loro detta un passo avanti enorme per flessibilità e velocità...
sarà vero?

Il Fek ha detto che non è possibile, dato che al contrario i developers puntano all'astrazione.
Ma se facesse guadagnare anche solo un 10% di prestazioni credo che in ricavi converrebbe :D
In un modo o nell'altro devi passare per un libreria grafica per visualizzare i risultati per cui bene o male una delle due devi continuare ad usare, almeno per buttare a video una texture col risultato. Resta poi da vedere se ha un senso reimplementare software gia' collaudato e probabilmente ottimizzato da chi ne sa molto di piu'... a meno che non si tratti di portare in GPU codice che le DirectX/OpenGL eseguono sull'host.
Visto che e' del settore e sicuramente ne sa piu' di me, tendo a fidarmi di quel che dice Fek :p.

Albitexm
21-06-2008, 12:41
Non so quanto siano attendibili ed in che modo siano stati calcolati i miglioramenti, ma in questa pagina (http://www.nvidia.com/object/cuda_home.html) (sito Nvidia) vengono riportati gli speed-up per alcuni progetti, si va dal 2x al 270x. :eek:

Dal materiale nel link da te segnalato , sembra propio di avere un aumento considerevole di prestazioni , in gran parte delle apllicazioni .
Ora la domanda nasce spontanea : ma perchè la NVdia, invece che diffondere al pubblico il codice dell'ambiente di sviluppo delle sue GPU , non ha prodotto
o fatto produrre degli applicativi specifici ?
Comunque credo che l'unica modo , (come la maggior parte delle volte in questi casi) sia sperimentare . Ovvero comprare una GPU , scrivere un codice per l'applicazione che interessa e verificare i risultati , facendo diversi tentativi . Eih.. ma cosa sto facendo ? :confused: Lavoro gratis per la Nv.. ?

marco.r
21-06-2008, 13:13
Dal materiale nel link da te segnalato , sembra propio di avere un aumento considerevole di prestazioni , in gran parte delle apllicazioni .
Ora la domanda nasce spontanea : ma perchè la NVdia, invece che diffondere al pubblico il codice dell'ambiente di sviluppo delle sue GPU , non ha prodotto
o fatto produrre degli applicativi specifici ?
Comunque credo che l'unica modo , (come la maggior parte delle volte in questi casi) sia sperimentare . Ovvero comprare una GPU , scrivere un codice per l'applicazione che interessa e verificare i risultati , facendo diversi tentativi . Eih.. ma cosa sto facendo ? :confused: Lavoro gratis per la Nv.. ?
Perche' l'nvidia produce hardware, non software. A lei interessa venderti un prodotto che ti permetta di scrivere codice piu' veloce, e ti da gli strumenti per farlo (codice, documentazione, compilatore ... ). Sarebbe un po' come chiedere all'intel di produrre il software per le proprie cpu...

Tommo
23-06-2008, 08:03
Perche' l'nvidia produce hardware, non software. A lei interessa venderti un prodotto che ti permetta di scrivere codice piu' veloce, e ti da gli strumenti per farlo (codice, documentazione, compilatore ... ). Sarebbe un po' come chiedere all'intel di produrre il software per le proprie cpu...

Ma c'è la differenza che Intel crea processori che eseguono qualsiasi codice x86/64...
Invece Nvidia crea GPU che eseguono solo shaders e CUDA, che è un linguaggio proprietario e assolutamente incompatibile con la concorrenza.

Quindi dovranno inventare qualcosa per convincere gli sviluppatori a trascurare tutti gli utenti AMD no?:rolleyes:

Per ora stanno rendendo il codice eseguibile anche su CPU x86... IMHO vogliono porre CUDA come standard nella programmazione "manycore"...

marco.r
23-06-2008, 14:08
Ma c'è la differenza che Intel crea processori che eseguono qualsiasi codice x86/64...
Invece Nvidia crea GPU che eseguono solo shaders e CUDA, che è un linguaggio proprietario e assolutamente incompatibile con la concorrenza.

Non e' cosi' monolitica la questione. Il compilatore di file CUDA genera un assembler di alto livello (chiamato PTX, Parallel Thread Execution) che poi viene trasformato nel codice nativo della gpu. Nessuno ti vieta di generare direttamente codice PTX da un altro linguaggio (e' l'approccio di cui parlavo sopra). Similmente nessuno di vieta di generare un backend diverso per hardware particolare, come GPU ATI (se non sbaglio lo stanno gia' facendo) o cpu "tradizionali". Anche per queste ultime mi sembra qualcuno avesse generato un backend opportuno con buoni risultati.


Quindi dovranno inventare qualcosa per convincere gli sviluppatori a trascurare tutti gli utenti AMD no?:rolleyes:

Dipende da che ambito parli. Al di la' di quanto sopra detto, mentre per software orizzontale come videogiochi il problema c'e', quando si parla di programmazione scientifica molto spesso si compera l'hardware in base al software che vuoi svilupparci sopra, non il contrario.

Albitexm
27-06-2008, 19:12
Perche' l'nvidia produce hardware, non software. A lei interessa venderti un prodotto che ti permetta di scrivere codice piu' veloce, e ti da gli strumenti per farlo (codice, documentazione, compilatore ... ). Sarebbe un po' come chiedere all'intel di produrre il software per le proprie cpu...

L'Intel produce (o fa' produrre) , codice per le sue CPU. Guarda un po' il suo sito e vai nella sezione download. Troverai decine di tools e applicativi . Alcuni free , molti a pagamento. Senza contare il discorso che lavora in concerto con la Microsoft .
Il mio discorso era un'altro . Ovvero , il senso della mia domanda è accostabile alla seguente : in televisione e sui giornali c'è spesso pubblicità di sedicenti maghi che prometto in cambio di denaro di offrirti i numeri al lotto o sistemi per la schedina . Ma perchè non li giocano loro ?

marco.r
27-06-2008, 20:48
L'Intel produce (o fa' produrre) , codice per le sue CPU. Guarda un po' il suo sito e vai nella sezione download. Troverai decine di tools e applicativi . Alcuni free , molti a pagamento. Senza contare il discorso che lavora in concerto con la Microsoft .
Il mio discorso era un'altro . Ovvero , il senso della mia domanda è accostabile alla seguente : in televisione e sui giornali c'è spesso pubblicità di sedicenti maghi che prometto in cambio di denaro di offrirti i numeri al lotto o sistemi per la schedina . Ma perchè non li giocano loro ?
sorry, continuo a non capire la questione. Invidia produce e vende hw. Tutto il software che scrive e' fatto col fine di aumentare le vendite di hw. Quando si sono accorti che la gente usava le GPU anche per calcoli paralleli oltre che per i videogiochi, hanno pensato di renderne piu' diretto l'uso fornendo un'interfaccia di programmazione piu' immediata, CUDA appunto (d'altra parte AMD non si sta comportando tanto diversamente). Certo potrebbe mettersi pure ad usarlo (probabilmente gia' lo fa internamente), questo non toglie che il suo campo sono le GPU, non il software scientifico. Non e' come nel lotto dove basta sborsare la grana, non ci si improvvisa azienda software (soprattutto di un certo tipo di software e ad un certo livello) da un giorno all'altro.

svip
31-03-2009, 22:18
Nel caso di CUDA con kernel si intende un elemento di computazione che va poi eseguito in parallelo sulla GPU. Ad esempio se volessi effettuare una somma di vettori in parallelo (la cosa piu' banale che mi viene in mente :p) bisogna scrivere prima un kernel piu' o meno nel modo seguente

__global__ void sum( float* u, float* v, float* w )
{
int bs = blockDim.x;
int bx = blockIdx.x;
int tx = threadIdx.x;

w[ bz*bs + tx ] = u[ bx*bs + tx ] + v[ bx*bs + tx ];
}

In pratica ad ogni elemento processore viene assegnato un indice diverso su cui operare, e quando dalla macchina si esegue sum(u,v,w) e' il driver della scheda video che provvede a schedulare opportunamente le esecuzioni in parallelo/sequenza.
Il motivo di tutti quegli indici strani e' che l'esecuzione dell'intera operazione viene suddivisa in blocchi i quali a loro volta vengono suddivisi in thread (che sono gli elementi che eseguono in parallelo). Il motivo di questa suddivisione e' data dal fatto che thread appartenenti allo stesso blocco condividono della memoria (chiamata shared appunto) locale molto piu' veloce di quella globale.
La gestione degli accessi alla memoria e' probabilmente uno degli elementi piu' cruciali per le performance in CUDA. Devi non solo minimizzare quelli alla memoria globale, ma pure organizzare gli accessi da parte di thread differenti in modo opportuno: se thread "vicini" (come indice) leggono usano locazioni di memoria in modo opportuno la scheda grafica riesce ad effettuare diverse letture in batch, ottimizzando la banda.
Spero che come riassunto offerto da un profano (ho cominciato a giocare con CUDA il mese scorso a tempo perso) possa essere abbastanza chiaro :p.
Come puoi ben capire scrivere i kernel e' un'operazione cruciale, tediosa (nel senso che il modo di procedere e' abbastanza chiaro) e che genera codice illeggibile (secondo me) a causa della marea di indici presenti :D, ed e' per questo che prima mi lamentavo che i kernel bisogna scriverseli :P. Idealmente io vorrei essere in grado di scriver equalcosa del genere

cudamap( lambda x,y,z : z = x + y, u,v,w)

Visto che tutte le informazioni necessarie per generare il codice piu' sopra ci sono. Ovviamente in python e' un lavoraccio improponibile, pero' in altri linguaggi dotati di macro potrebbe essere gia' piu' ragionevole (noi stiamo facendo delle prove con CL).
Ho volutamente tralasciato il problema di piu' alto livello, ovvero di come organizzare l'algoritmo in modo parallelo, ma e' un argomento che merita molto piu' spazio e su cui non mi espongo :D :p.


La programmazione in c non è il mio forte ma ho la fortuna di avere una tesla tra le mani e sto iniziando a fare qualcosa grazie per questo intervento.

Albitexm
01-04-2009, 20:23
La programmazione in c non è il mio forte ma ho la fortuna di avere una tesla tra le mani e sto iniziando a fare qualcosa grazie per questo intervento.

è molto cara una "Tesla" ?

svip
28-04-2009, 20:29
è molto cara una "Tesla" ?

crdo sia stata pagata sui 1700 euro ma non ne sono certo

shinya
29-04-2009, 08:35
Similmente nessuno di vieta di generare un backend diverso per hardware particolare, come GPU ATI (se non sbaglio lo stanno gia' facendo) o cpu "tradizionali"
Yo dawg! I heard u like CUDA, so I did a backend to program you cpu while you program your gpu with your cpu! :stordita:

Tommo
29-04-2009, 20:15
What?

Cmq segnalo che Nvidia ha rilasciato il primo driver prebeta (che sarebbe poi alpha) con supporto OpenCL... a quanto pare son pronti ad abbandonare CUDA, basta che vendono schede :D

Non mi sbilancio a metterlo però.

Albitexm
29-04-2009, 21:33
What?

Cmq segnalo che Nvidia ha rilasciato il primo driver prebeta (che sarebbe poi alpha) con supporto OpenCL... a quanto pare son pronti ad abbandonare CUDA, basta che vendono schede :D

Non mi sbilancio a metterlo però.

Io comunque continuo a non vedere in giro applicazioni o piattaforme che usano CUDA. Poi sembra che non habbia una grande considerazione tra gli sviluppatori, e ancora meno tra gli hardwaristi, che sembra siano inclini a utlizzizare soluzioni multi-cpu invece che GPU per aumentare le prestazioni.
Ma, mi sa "na sola"

!k-0t1c!
29-04-2009, 22:56
I problemi principali di CUDA sono tali da renderne l'adozione svantaggiosa nella maggior parte dei casi.
Basta considerare i seguenti punti:

Basato sul C (almeno un buon supporto al C++ sarebbe debito)
I dati su cui deve lavorare la GPU vanno trasferiti dalla RAM alla memoria della scheda video e se la mole di dati non è grossa o l'elaborazione non è molto lunga può bastare questo a rendere l'uso della GPU inutile
La GPU è lentissima in tutte le operazioni di flow control tipo salti, salti condizionali etc. E' dunque inadatta all'esecuzione di algoritmi completi, e si presta bene solo a calcoli matematici (per lo più sui float, meno sugli int) su un elevato numero di input
La API CUDA è tutto meno che intuitiva per chi non ha nozioni del funzionamento di una GPU (nonostante abbia nozioni di parallelismo etc) e dallo sguardo che ho dato ad OpenCL si direbbe che le cose non stiano cambiando


In ultima istanza penso di poter affermare serenamente che un motore di scacchi si presterebbe meglio ad essere ottimizzato per FPGA che per far uso di GPGPU, quindi al limite meglio spendere 99€ per una scheda FPGA entry level e giocare con quella...E' anche più facile (e credo più economico) aumentare eventualmente la potenza a disposizione, che anche nel caso degli FPGA si traduce spesso in un aumento lineare delle prestazioni.

shinya
30-04-2009, 08:25
What?
http://knowyourmeme.com/memes/xzibit-yo-dawg

Tommo
30-04-2009, 09:58
I problemi principali di CUDA sono tali da renderne l'adozione svantaggiosa nella maggior parte dei casi.
Basta considerare i seguenti punti:

Basato sul C (almeno un buon supporto al C++ sarebbe debito)
I dati su cui deve lavorare la GPU vanno trasferiti dalla RAM alla memoria della scheda video e se la mole di dati non è grossa o l'elaborazione non è molto lunga può bastare questo a rendere l'uso della GPU inutile
La GPU è lentissima in tutte le operazioni di flow control tipo salti, salti condizionali etc. E' dunque inadatta all'esecuzione di algoritmi completi, e si presta bene solo a calcoli matematici (per lo più sui float, meno sugli int) su un elevato numero di input
La API CUDA è tutto meno che intuitiva per chi non ha nozioni del funzionamento di una GPU (nonostante abbia nozioni di parallelismo etc) e dallo sguardo che ho dato ad OpenCL si direbbe che le cose non stiano cambiando


In ultima istanza penso di poter affermare serenamente che un motore di scacchi si presterebbe meglio ad essere ottimizzato per FPGA che per far uso di GPGPU, quindi al limite meglio spendere 99€ per una scheda FPGA entry level e giocare con quella...E' anche più facile (e credo più economico) aumentare eventualmente la potenza a disposizione, che anche nel caso degli FPGA si traduce spesso in un aumento lineare delle prestazioni.

E' vero che spesso è inutile, il GPGPU non è certo un "silver bullet"... però devi considerare che i primi 3 svantaggi sono facce della stessa medaglia:

-senza C (per quanto C++ sarebbe dovuto nel 2009) non si potrebbe accedere abbastanza a basso livello e trarre profitto dal GPGPU
-se te hai un'applicazione che trasferisce dati in maniera continua, probabilmente è poco adatta ad essere resa parallelizzabile... infatti un algoritmo parallelo ha un set più grande possibile di memoria in in ed in out.
-idem, se un algoritmo necessita molto flow control per definizione è inadatto alla GPU, o come minimo è impostato male... le ultime GPU cmq supportano abbastanza flow control, il problema è che fa divergere i threads.
-d'accordo sul fatto che è ancora poca teoria e molta conoscenza dell'hardware, ma il GPGPU serve esattamente ad astrarre l'hardware, proprio come hanno fatto i processori tanti anni fa.
E' comunque un passo avanti dagli shaders, no?

Cmq credo che ci sia un sacco di roba che si adatta al il GPGPU apparte simulazioni e giochi...
"pochi e grandi trasferimenti di memoria" e "non necessita di flow control" sono caratteristiche che presentano moltissimi algoritmi se li si rielabora. Ovvio che a prima vista sono pochi, l'intera cultura informatica è basata sulle CPU e sequenze di if...
infatti IMHO il problema è che pochi immaginano cosa ci si potrebbe fare con una GPGPU.:stordita: