CUDA notizie ?

[Albitexm]

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 ?

[eVuGEGA]

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

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]

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]

E c'è perfino la possibilità di accedere alle API da Python... [PyCuda]
Certo che la biscia è dappertutto.

[cdimauro]

SLURP! CUDA lo seguo da tempo, ma proprio perché troppo legato al C, non l'avevo nemmeno studiato.

Adesso il discorso cambia.

[banryu79]

Originariamente inviato da cdimauro

cut...

Bang!
Beccato

@EDIT:

eh, ma i kernel vanno sempre scritti in cuda .

Sisi, a me interessava solo "seccare" cdimauro

[marco.r]

Originariamente inviato da banryu79

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 .

[marco.r]

Originariamente inviato da banryu79

Bang!
Sisi, a me interessava solo "seccare" cdimauro

[Albitexm]

Originariamente inviato da marco.r

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 , e comunque vorrei sperimentare . Potrebbe essere in ogni caso un modo per imparare a usare CUDA .

[Albitexm]

Originariamente inviato da eVuGEGA

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

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]

Non so quanto siano attendibili ed in che modo siano stati calcolati i miglioramenti, ma in questa pagina (sito Nvidia) vengono riportati gli speed-up per alcuni progetti, si va dal 2x al 270x.

[cdimauro]

Originariamente inviato da banryu79

Bang!
Beccato

@EDIT:

Sisi, a me interessava solo "seccare" cdimauro

Originariamente inviato da marco.r

eh, ma i kernel vanno sempre scritti in cuda .

Originariamente inviato da marco.r

Cattiviiiii!!!

Comunque, quando ho studiato elaborazione delle immagini all'università (una dozzina d'anni fa, come minimo ) 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.

Originariamente inviato da Albitexm

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 , 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.

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

[marco.r]

Originariamente inviato da Albitexm

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 , 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]

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

[marco.r]

Originariamente inviato da cdimauro

Cattiviiiii!!!

Comunque, quando ho studiato elaborazione delle immagini all'università (una dozzina d'anni fa, come minimo ) 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 ) 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 .
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 , 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 .

[cdimauro]

Sei stato chiarissimo, grazie.

A questo punto....

del CUDA

per me.

[marco.r]

Originariamente inviato da Tommo

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

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 .

[Albitexm]

Originariamente inviato da variabilepippo

Non so quanto siano attendibili ed in che modo siano stati calcolati i miglioramenti, ma in questa pagina (sito Nvidia) vengono riportati gli speed-up per alcuni progetti, si va dal 2x al 270x.

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 ? Lavoro gratis per la Nv.. ?

[marco.r]

Originariamente inviato da Albitexm

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 ? 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]

Originariamente inviato da marco.r

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?

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