[openCL/Stream/Cuda] Qualcuno interessato?

[giova22]

Salve,

Volevo cominciare a fare qualcosa usando le GPU. Pensavo di usare OpenCL così che il tutto funzioni su gpu nvidia e ati...

C'è qualcun altro interessato? Magari potremmo riunire qui suggerimenti e consigli, e cominciare a fare qualcosa, più che altro per imparare....

Se interessa a qualcuno si faccia avanti...

[giova22]

Dunque, correggo ciò che ho scritto sopra... Per OpenCL non ci sono ancora implementazioni da parte di ATI e Nvidia...

Comunque ho dato un'occhiata alla documentazione di STREAM/BROOK+ e mi sembra ben fatta. CUDA non l'ho ancora guardato, anche perchè ora ho una scheda ATI.

Mi piacerebbe comunque scrivere qualcosa in italiano, visto che il materiale a riguardo è praticamente inesistente... Se siete a conoscenza di link a tutorial/esempi, ecc (anche in inglese ovviamente) postate e link...

Mi piacerebbe fare una guida che introduca questi affascianti nuovi modi di programmare.

[Tommo]

Io son molto interesato a CUDA, tanto che stavo provando a farci un rasterizer software...

Tuttavia non ti aspettare grosso interesse in assoluto, la tecnologia è nuova, poco diffusa, e la maggior parte degli "informatici" va poco oltre il Java.
Per cui amministrare 2 tipi di memoria di cui una n-dimensionale in un contesto massivamente multithreaded esula parecchio dalle competenze generiche.

Cmq se sei interessato a provare qualcosa subito io ti consiglierei CUDA, come semplicità mi sembra notevolmente migliore dello Stream di AMD:
Il primo è un tentativo di portare C/C++ su GPU, il secondo tenta di adattare la GPU a C.
Infatti, mentre CUDA gira nativo, Brook alla fine della storia mappa la roba su shader, textures e buffers.
Le differenze si vedono, e anche le limitazioni imho... tant'è che della guida di Stream non ho capito una mazza

Le implementazioni di OpenCL dovrebbero uscire per giugno, invece.

Per quanto riguarda i tutorial, il materiale scarseggia bel pò anche in inglese... io sto andando avanti a forza di reference manual e codice dei sample, fortuna che è molto più facile di quello che sembra

Un mio rant su CUDA: non c'è modo di mostrare un immagine prodotta dalla scheda video se non passandola a DX, OGL, o al processore.
Il che mi pare un leggero controsenso dato che la device che sto usando sta attaccata ad un monitor

[giova22]

finalmente qualcuno a cui interessi...

Vorrei provare anche CUDA, ma non ho una scheda nvidia, quindi presumo che non funzioni giusto? Almeno dal sito nvidia ho capito questo

[Tommo]

Ovvio.
Cmq provare non costa più di tanto... una 8600gt davvero scrausa (ma che supporta cuda1.1) viene una 50ina di euro ora.
Se sei abbastanza interessato al GPGPU penso che sia possibile metterla come seconda scheda, il CUDA dovrebbe essere in grado di manovrarla lo stesso

Sennò aspetta OpenCL, ma "non tratterrei il respiro"
Prima release a giugno significa che si può usare davvero dall'anno prossimo, temo.

[Wing_Zero]

io invece interessato ad ati stream...per forza di cose avendo una 4850...xD
Anche se credo che
1) vista la potenza di calcolo dell'R700, con ati stream si puo' riuscire ad effettuare operazioni piu' pesanti rispetto alla controparte nvidia

2) Buttarsi ora su Stream/CUDA, da una parte e' darsi uan zappata sui piedi da soli, visto che saranno supportato tra non molto ed in maniera ufficiale sia da parte di ati che di nvidia le opencl...quindi...

[giova22]

in effetti forse la cosa migliore è aspettare opencl.... Se qualcuno ha fatto delle prove puo postare un po di sorgente.... Così intanto cominciamo a dare un occhiata a tutto quanto...

Sia cuda che stream

[Tommo]

Beh ma Nvidia ha detto che la loro Opencl sarà sviluppata con le loro librerie PTX su cui si basa anche CUDA, quindi sarà o allo stesso livello o sotto.
Nel secondo caso sarà possibile compilare il cuda in opencl, credo.

Cmq si, se si va oltre la mera sperimentazione usare CUDA potrebbe essere inutile... ma in caso contrario credo che non ci sia nessun problema.
I concetti sono al 99% quelli, cambia solo (a volte) come vanno espressi.

[Wing_Zero]

ehm...mi vergogno a chiederlo...ma qualcusa sa dove cavolo si trovano i binary del compilatore Brook per ati stream?
Ho installato l'sdk, guardato sull doc ufficiale ma non lo trovo!!!!
(vergognati...e sei pure laureato in ing. informatica...-.-")

[giova22]

incredibile. Sono 3 giorni che giro in internet ,ma non trovo nulla.

Nessun esempio, nessun programma open source, nessun tutorial...

Neppure su amazon ho trovato libri che parlino di questi argomenti.... Forse tutti aspettano opencl

[Tommo]

Beh si, molti aspettano opencl perchè non vogliono legarsi a Nvidia... o più in generale si aspetta e spera:

-è troppo difficile per molti
-il mercato è decisamente ristretto (Nvidia G80)
-la tecnologia è ancora acerba
-tutti aspettano che gli altri facciano il primo passo, perchè manca la "massa critica"

Che poi è anche vero che all'utente comune sta roba non serve a nulla, perchè non fa nulla di computazionalmente pesante.

[!k-0t1c!]

Non sono d'accordo sull'inutilità per l'utente comune. Basta pensare a Badaboom, che converte un video in H.264 compatibile con iPod e iPhone in un decimo del tempo che servirebbe usando solo una CPU (di fascia alta).
Ad ogni modo finché questa tecnologia è accessibile solo dal C io, e credo molti altri, me ne lavo le mani. Non dovrebbe costare granché fare un compilatore in grado di convertire alcune espressioni (semplici) da linguaggi gestiti - C# usando LINQ e il tipo Expression, F# usando le quotations - a HLSL, e da li il salto è piccolo. Il problema per cui il GPGPU non è ancora mainstream è che non è accessibile e facilmente integrabile. Credo che anche se avessi un programma in C sarei scettico a provare CUDA per la scarsa integrazione (Visual Studio etc.)
Esistono progetti curiosi come i Data Parallel Arrays di Microsoft e Brahma, ma sono entrambi obsoleti e mentre il primo offre buone performance ed API orribili, il secondo offre cattive performance e un modello di programmazione stupendo...Se qualcuno si interessa di compilatori e capisce qualcosa di HLSL potrebbe dare un'occhiata al codice di Brahma e vedere se/quanto si può migliorare, magari aggiungendo anche un sistema di caching per evitare che l'espressione venga compilata più volte...
Ma tornando al punto principale, è difficile che qualcuno voglia moltiplicare per un fattore elevato il tempo di sviluppo, la complessità del codice e la probabilità di bugs associati al C a fronte di un incremento di performance di cui molti utenti possono fare a meno.

[Tommo]

Già, il C oggi è davvero troppo di basso livello... non tanto come istruzioni, quanto come modello di programmazione... io per esempio mi ci trovo molto poco, e in effetti le funzioni CUDA le wrappo in C++:
L'applicazione non accede a CUDA se non tramite un metodo di una classe che chiama direttamente il kernel.

Cmq a mio parere chiedere che la GPU faccia girare linguaggi managed da CPU è ridicolo, dato che distruggerebbe qualsiasi utilità delle pipeline vettoriali a causa dell'intasamento del bus dovuto alla quantità di micro-accessi alla memoria (comuni a tutti i linguaggi managed).
La GPU lavora a batches, più grandi sono meglio è... solo pensare ad un garbage collector su GPU fa capire quanto il programmatore comune non abbia i mezzi per sfruttare questo tipo di paradigma...

Al massimo, si potrebbe fare un linguaggio managed per la GPU. Ma sicuro non a breve. E sicuro non a costo 0.

[BrutPitt]

Originariamente inviato da !k-0t1c!

Non sono d'accordo sull'inutilità per l'utente comune. Basta pensare a Badaboom, che converte un video in H.264 compatibile con iPod e iPhone in un decimo del tempo che servirebbe usando solo una CPU (di fascia alta).
Ad ogni modo finché questa tecnologia è accessibile solo dal C io, e credo molti altri, me ne lavo le mani. Non dovrebbe costare granché fare un compilatore in grado di convertire alcune espressioni (semplici) da linguaggi gestiti - C# usando LINQ e il tipo Expression, F# usando le quotations - a HLSL, e da li il salto è piccolo. Il problema per cui il GPGPU non è ancora mainstream è che non è accessibile e facilmente integrabile. Credo che anche se avessi un programma in C sarei scettico a provare CUDA per la scarsa integrazione (Visual Studio etc.)
... tralascio ...
Ma tornando al punto principale, è difficile che qualcuno voglia moltiplicare per un fattore elevato il tempo di sviluppo, la complessità del codice e la probabilità di bugs associati al C a fronte di un incremento di performance di cui molti utenti possono fare a meno.

Be', personalmente vedo gia' "grasso che cola" l'uso di un liguaggio C-like per la programmazione delle GPU, rispetto al semlice uso dell'assembler che si usava con i primi shaders.
Poi, piu' si sale di livello e si "umanizza" il linguaggio, e piu' si perde in "finezza" nelle ottimizzazioni del codice, mentre i compilatori nvcc o cgc (usato per la creazione del nVidia GPU-assembler da sorgenti CG, GLSL e HLSL) producono ottimizzazioni molto vicine all'utilizzo dello stesso GPU-assembler.

Ma anche i programmi di conversione video (giusto per citare il tuo esempio) che utilizzano la sola CPU, si appoggiano a librerie in assembler (o inline assembler) per sfruttare le peculiarita' MMX, 3DNOW, SSE, SSE2/4... etc. delle diverse CPU. (possono essere anche librerie condivise o DLL sotto Windows)

Insomma e' difficile vedere, anche sulla CPU, un "core di calcolo ottimizzato" che utlizzi un linguaggio ad alto livello: il programma lo fai con il linguaggio che piu' t'aggrada, per il "core" elaborativo vedi tu: se ti serve piu' potenza cercherai la modalita' idonea... anche a costo di spenderci del tempo.
Cosi' se vuoi usare Cuda con VB o C#, basta che con la procedura in questione ci fai una DLL... relegando al minimo quella che tu definisci "la complessità del codice e la probabilità di bugs associati al C":

(sto scrivendo a getto spero di non dire/fare castronerie... guardatelo come un metalinguaggio-C )


__declspec(dllexport) void __stdcall miaRoutineGPU();

__global__ void mioKernelCuda(listaParametriKernel)
{
return;
}

void __stdcall miaRoutineGPU() //con opzionale lista paramentri
{
dim3 dimGrid(x);
dim3 dimBlocks(y);
// x e y sono le dimensioni della griglia e dei blocchi di elaborazione

mioKernelCuda<<<dimGrid,dimBlocks>>>(listaParametriKernel);
return;
}

e dal tuo programma chiami la funzione miaRoutineGPU() nelle modalita' richieste dal tuo linguaggio di programmazione.

[mux85]

ciao a tutti, anche io sono interessato alla programmazione GPGPU e pensavo di aspettare l'implementazione di OpenCL, tanto non è che al momento non abbia nulla da fare (esami a gogo ). si sa qualcosa di + riguardo a quando dovrebbe essere disponibile?

[Tommo]

Beh che io sappia, è già disponibile il driver pre-beta (qualunque cosa voglia dire ) di Nvidia...
però mi sa che ci vuole un bel coraggio a metterlo

[mux85]

si ma oltre al driver servirà un sdk, un compilatore o qualcosa del genere

[Tommo]

Mah probabilmente ci sta questa roba, cmq non oserei provare qualcosa prima pure della versione beta...
mancano pure la documentazione e gli esempi!

A me basta già il cuda che è alla versione 2.2 e tanto sa dire solo "unknown error"

[BrutPitt]

Originariamente inviato da mux85

si ma oltre al driver servirà un sdk, un compilatore o qualcosa del genere

Si' infatti, sempre da NVidia, oltre al driver e' anche disponibile l'SDK di OpenCL, ma ancora in pre BETA e solo per gli sviluppatori iscritti al circuito GPGPU (CUDA).

http://www.nvidia.com/object/io_1240224603372.html

Originariamente inviato da Tommo

Mah probabilmente ci sta questa roba, cmq non oserei provare qualcosa prima pure della versione beta...
mancano pure la documentazione e gli esempi!

A me basta già il cuda che è alla versione 2.2 e tanto sa dire solo "unknown error"

Per quanto riguardo la documentazione qualcosa in giro s'inizia a trovare.

Per chi avesse voglia di iniziare a dare un'occhiata alle differenze tra CUDA e OpenCL e' gia' disponibile, per tutti, una JumpStartGuide da NVidia:

http://developer.download.nvidia.com...tart_Guide.pdf

Oppure ci si puo' scaricare da KRONOS la QuickReferenceCard, e se si ha un po' di familiarita' con CUDA ci si riesce a raccapezzare:

http://www.khronos.org/files/opencl-...rence-card.pdf

Invece chi ha un'idiosincrasia atavica verso il semplice C, sara' lieto di sapere che alcuni membri dell'OpenCL group stanno lavorando ad un binding C++, anche se ancora in embrione.... documentazione e headers qui:

http://www.khronos.org/registry/cl/

[mux85]

Originariamente inviato da Tommo

Mah probabilmente ci sta questa roba, cmq non oserei provare qualcosa prima pure della versione beta...
mancano pure la documentazione e gli esempi!

A me basta già il cuda che è alla versione 2.2 e tanto sa dire solo "unknown error"

ho già capito che ne riparliamo tra qualche mese . intanto di esami per tenermi impegnato ne ho