[vari] Programmazione GP-GPU

[mux85]

Originariamente inviato da Tommo

La documentazione però cita esplicitamente una Command Queue per i Kernels, quindi c'è
Magari al momento è un'estensione di OCL1.0 di AMD?

no beh le command queue esistono anche in opencl 1.0. ma quindi cosa intendi quando dici che sono superiori a quelle di cuda? che in cuda non ci sono proprio? io in effetti non l'ho usato gli ho dato solo un'occhiata vaga mentre opencl lo sto usando per un progetto per l'università

[Tommo]

In cuda pensavo ci fosse, ma ho avuto una brutta sorpresa...

in pratica l'esecuzione di "un Kernel" è parallela al main thread si...

Il problema è che se c'è una nuova chiamata ad un kernel prima che il primo finisca, a causa della mancanza di una command queue il main thread viene messo in attesa del primo, appena prova a lanciare il secondo.

quindi fuori dalle app di esempio che fanno lavorare solo la GPU, ci si trova spessissimo in situazioni dove prima la CPU lancia un sacco di kernels e aspetta la GPU, quindi la GPU aspetta che la cpu finalizzi il frame e faccia quello che deve fare.
Per cui il modello è sostanzialmente sincrono... mentre fai conto che nei videogiochi la GPU si trova a volte fino a 10 frame indietro rispetto alla CPU prima che venga imposta una sincronizzazione!

Inoltre questo fatto lo conoscono in pochi, che io sappia c'è una sola implementazione di command queue in giro.

In realtà ci sarebbero i Compute Streams nel CUDA SDK, che dovrebbero parallelizzare l'esecuzione di N kernels...
il problema è che su qualsiasi cosa che non sia Fermi non fanno assolutamente nulla e tutti i kernels vengono lanciati nel main thread.
E su Fermi se ne possono eseguire (al più, a discrezione dello scheduler) 4 , che comunque presentano lo stesso problema di quell'unico thread di prima, cioè 2 kernel consecutivi serializzano lo stream.

Per cui OpenCL mi è interessata di botto con questa cosa.

Originariamente inviato da marco.r

Lo standard riguarda le API non le ABI. Al piu' ti puoi lamentare che non puoi cross-compilare da una architettura all'altra, ma io francamente neanche me lo aspetto. Sarebbe come chiedere di poter cross-compilare binari ARM per linux da VS ...

E quindi abbiamo OpenCL di Nvidia, OpenCL di AMD, OpenCL di IT, OpenCL di Intel... allora dove sarebbe lo standard se non sono nemmeno compile-compatibili?
La situazione è quantomeno confusa

[Tommo]

*doppio post*

[banryu79]

Originariamente inviato da Tommo

E quindi abbiamo OpenCL di Nvidia, OpenCL di AMD, OpenCL di IT, OpenCL di Intel... allora dove sarebbe lo standard se non sono nemmeno compile-compatibili?
La situazione è quantomeno confusa

Beh, una cosa alla volta: almeno hanno lo stesso nome.
Dagli tempo.

[marco.r]

Originariamente inviato da Tommo

I
E quindi abbiamo OpenCL di Nvidia, OpenCL di AMD, OpenCL di IT, OpenCL di Intel... allora dove sarebbe lo standard se non sono nemmeno compile-compatibili?
La situazione è quantomeno confusa

Se vuoi ti riscrivo quello che hai quotato .
Perche' dovrebbero essere compatibili a livello binario per essere uno standard ? OpenCL si occupa di altro, cosi' come lo standard C++ non si occupa della compatibilita' binaria degli eseguibili. Anzi col C++ e' forse peggio perche' esistono compilatori per la stessa architettura HW (x86) e la stessa piattaforma (win32) che generano codice oggetto con ABI diverse. Nonostante questo c++ e' uno standard.

[Tommo]

Si beh però purtroppo mentre "Win e Linux" sono due cose piuttosto differenti dal punto di vista dell'utente, AMD e Nvidia producono schede video che fanno esattamente le stesse cose.

Detta in altra maniera, non è fattibile un eseguibile per Nvidia e uno per AMD in un'applicazione di massa... sia per la manutenzione che per l'utente finale che spesso non sa nemmeno che è una scheda video ( "è lo schermo?" (cit.) ) e va prepotentemente contro l'idea che ha fatto nascere OpenCL, cioè computing parallelo portabile e trasparente.
All'inizio dicevano che avrebbe funzionato pure sui processori, figurarsi.

A questo punto è ovvio che si fa prima a dire "nvidia only" e supportare il tool fatto meglio.
Bah, speriamo che la situazione cambierà, OpenCL non mi dispiace

[Tommo]

Ho provato su Mac, com'è giusto che sia il kit offerto col sistema non fa alcuna distinzione tra Nvidia e AMD... magari le prestazioni non sono al top (58 gflops per lo nbody sample) ma trattandosi di una 8600GT su mac "non ufficiale" è notevole.

Come sarà che su Windows questa cosa è "tecnicamente impossibile"?

EDIT: ah ecco

Mac OS X’s OpenCL compiler uses the clang and LLVM technologies to compile the kernels written in OpenCL and translate those instructions into optimized machine code targeted for the hardware on the host machine. Mac OS X v10.5 and later uses LLVM technology in other environments as well, such as for compiling OpenGL code. When the compiler converts your OpenCL code it first translates your instructions from OpenCL to an intermediate representation (IR). After that, LLVM does its best to optimize the IR before passing it along to the code generators for the devices that the code must execute on. The importance of this pipeline is that it makes it possible to write a single OpenCL program that can execute natively on various machine architectures—such as those of the various CPUs and GPUs available on your system. Although LLVM is fast, compiling is always expensive and the resulting programs should be cached by your application to avoid unnecessary re-compilation.

Tanta roba.
Che è sto LLVM che sembra saper fare di tutto?

[shinya]

Originariamente inviato da Tommo

Che è sto LLVM che sembra saper fare di tutto?

http://llvm.org/
Se non mi ricordo male sta per Low Level Virtual Machine. E' una macchina virtuale con molte funzionalità avanzate, e vuole rappresentare un pò lo stato dell'arte.

Ci ho giocato un pò e mi sembra davvero un gioiellino.
Oltretutto, i messaggi d'errore di clang (il progetto principale a contorno, C su LLVM in pratica) sono spettacolari

[banryu79]

Originariamente inviato da shinya

Oltretutto, i messaggi d'errore di clang (il progetto principale a contorno, C su LLVM in pratica) sono spettacolari

[OT:] in che senso?

[shinya]

Originariamente inviato da banryu79

[OT:] in che senso?

http://blog.llvm.org/2010/04/amazing...-recovery.html

Notare che ti sottolinea l'errore in ascii-art style e ti dice "did you mean X?" con la correzione. Spettacolo.
C'è un confronto diretto tra clang e gcc... la differenza si nota!

[banryu79]

Originariamente inviato da shinya

http://blog.llvm.org/2010/04/amazing...-recovery.html

Notare che ti sottolinea l'errore in ascii-art style e ti dice "did you mean X?" con la correzione. Spettacolo.
C'è un confronto diretto tra clang e gcc... la differenza si nota!

Azz, visto, e sottoscrivo: molto bello (e utile) davvero

[Pixel452]

Ma visto che mi pare di capire che qui c'è gente che usa OpenCL... Usate Visual Studio 2010 per sviluppare? Perchè io non riesco a far andare l'intellisense nei file .cl, faccio tutto quello che dice la guida(stessa roba col'2008 che però mi funziona) ma va solo per i file .cl che sono GIA' presenti nei progetti dell'SDK, se anche ne aggiungo uno ad un esempio già esistente non mi funziona, ma solo per il file nuovo. Vi viene in mente niente?
Grazie.

p.s. La configurazione l'ho impostata come per i file già presenti.