Supporto a OpenCL: la posizione di NVIDIA

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/skvideo...dia_27461.html

NVIDIA vede positivamente l'introduzione OpenCL, che permetterà di supportare un maggior numero di applicazioni GPGPU

Click sul link per visualizzare la notizia.

[!fazz]

ovviamente visto che è il principale fornitore di gpu per apple

[demon77]

Non sono programmatore quindi capisco solo grossolanamente la differenza tra openCL e CUDA...
Quello che non mi è del tutto chiaro.. se sono diversi sono anche "incompatibili": o usi cuda o usi openCL no??

Alla fine CUDA essendo Nvidia only andtà necessariamente a morire o (come spero) a venire assorbito in un sistema più ampio che usi tutte le GPU e non solo le nvidia..

[!fazz]

Originariamente inviato da demon77

Non sono programmatore quindi capisco solo grossolanamente la differenza tra openCL e CUDA...
Quello che non mi è del tutto chiaro.. se sono diversi sono anche "incompatibili": o usi cuda o usi openCL no??

Alla fine CUDA essendo Nvidia only andtà necessariamente a morire o (come spero) a venire assorbito in un sistema più ampio che usi tutte le GPU e non solo le nvidia..

Se non sbaglio opecl è un layer sopra ai vari cuda, brook cal ecc ecc

penso che alla fine o implementeranno direttamente il gpgpu all'interno di opecl o più probabilmente creeranno delle routine di conversione opencl--> cuda, brook ecc ecc

[qboy]

"Al di là delle considerazioni di mercato, gli elementi più interessanti riguardano le tempistiche con le quali NVIDIA introdurrà il supporto ad OpenCL. Secondo le informazioni disponibili, a partire dal primo trimestre del prossimo...£
del prossimo cosa? anno? mese? decenio? non si capisce la data

[lowenz]

Nell'articolo dice che è un layer SOTTO non sopra

"OpenCL sia un ambiente di sviluppo che consente al programmatore il pieno accesso alle risorse hardware, in modo che possa gestire direttamente la gestione di memoria, l'inizializzazione di periferiche e via discorrendo."

[!fazz]

Originariamente inviato da qboy

"Al di là delle considerazioni di mercato, gli elementi più interessanti riguardano le tempistiche con le quali NVIDIA introdurrà il supporto ad OpenCL. Secondo le informazioni disponibili, a partire dal primo trimestre del prossimo...£
del prossimo cosa? anno? mese? decenio? non si capisce la data

anno prossimo visto che nel 2009 è previsto snow leopard

[deglia]

scusa...ma xchè vuoi la morte di CUDA?ok va solo sulle nvidia,è ottimizzato x quelle schede,quindi se resta in ambito professionale/ricerche che ti frega?in fondo è quello il settore (x ora) dove nvidia punta maggiormente con tesla ecc ecc.

[Kuarl]

cuda in realtà permette due stili di programmazione, uno molto simile a opencl, che poggia sui driver della gpu, e l'altro che poggia sul sistema operativo. Entrambi hanno vantaggi e svantaggi, credo anche io comunque che opencl sarà per cuda (ma anche per ati stream) solo un binding di codice già esistente.

[ElBizio]

cit demon77: Non sono programmatore quindi capisco solo grossolanamente la differenza tra openCL e CUDA...
Quello che non mi è del tutto chiaro.. se sono diversi sono anche "incompatibili": o usi cuda o usi openCL no??


ciao,

in maniera grossolana le differenze tra linguaggi di programmazione di alto e basso livello è questa:

in un linguaggio di alto livello dici alla "macchina" cosa deve fare (leggi qua, scrivi questo ecc.....), ma la tua istruzione (di lettura o scrittura in questo esempio) non è immediata, il tuo prgramma è uno strato software che interagisce più in basso con un altro strato software, il s.o., che esegue le tue istruzioni al momento che ritiene "più opportuno". Lo stesso s.o. poi, deve interagire ancora più in basso con un altro strato software, il firmware del dispositivo che fisicamente effettuerà la tua istruzione (il motore e la testina del disco rigido ad esempio)

sostanzialmente più il linguaggio di programmazione è ad alto liello più è "capibile" dall'uomo,
più è di basso livello più si avvicina al dispositivo hw

spero di essere stato semplice e chiaro


detto questo, è assolutamente normale e, come avrai capito, necessario che vari linguaggi di programmazione interagiscano tra loro, ogni linguaggio è buono per svolgere particolari compiti e assolutamente incapace di svolgerne di altri

ciao

[demon77]

Originariamente inviato da deglia

scusa...ma xchè vuoi la morte di CUDA?ok va solo sulle nvidia,è ottimizzato x quelle schede,quindi se resta in ambito professionale/ricerche che ti frega?in fondo è quello il settore (x ora) dove nvidia punta maggiormente con tesla ecc ecc.

Dici a me?
No non voglio la morte di cuda.. dico solo che se viene delineato un sistema standard (cosa per cui faccio un tifo enorme) è fisiologico che cuda essendo proprietario e valido solo per nvidia venga accantonato..
Chiaro che però con "accantonato" non intendo "buttato via" ma assorbito nel sistema standard al fine di renderlo migliore!

[appleroof]

Mi fà sorridere pensare a quelli che profetizzavano la morte di cuda ecc, mentre Nvidia partecipava direttamente per opencl...evidentemente era tutto calcolato, con buona pace dei sapientoni

per fare il sapientone anche io , credo che cuda verrà indirizzato verso ambiti specifici, imho prettamente scientifici....vediamo

cmq anche io a questo punto sono contento dell'affermazione di questo standard unico, vediamo nei prossimi mesi in cosa si tradurrà per l'utente finale, quali vantaggi apporterà al gamer, all'appassionato di videoediting, ecc ecc

[Mercuri0]

Originariamente inviato da appleroof

Mi fà sorridere pensare a quelli che profetizzavano la morte di cuda ecc, mentre Nvidia partecipava direttamente per opencl...evidentemente era tutto calcolato, con buona pace dei sapientoni

Certo che era tutto calcolato, anzi era proprio scontato. Per questo un pò mi meravigliavo di non essere capito quando profetizzavo OpenCL.
Non era mica un segreto che nVidia partecipasse attivamente alla stesura di OpenCL. Solo che non usciva nelle press-release pubblicitarie, per qualche motivo.

per fare il sapientone anche io , credo che cuda verrà indirizzato verso ambiti specifici, imho prettamente scientifici....vediamo

Concordissimo, in ambiti non consumer ha senso usare linguaggi specifici.

A vedere le slide su TechReport, sembra che quello che abbiamo sempre chiamato "CUDA" sia ora diventato "C for CUDA", e con "CUDA" ora nVidia si riferisce a qualcosa di simile alla CAL di AMD.

OpenCL girerà su CUDA per nVidia e su CAL per AMD, insieme ad altri eventuali linguaggi e API.
(in sostanza AMD & nVidia forniranno una dll che farà da traduttore da OpenCL->CUDA/CAL)

Curiosamente, C for CUDA è più ad alto livello (nel senso più lontano dall'hardware) rispetto a OpenCL, tant'è che la gente aveva chiesto se C for CUDA sia in grado di pareggiare OpenCL in prestazioni...

Vabbé, spero di non aver ubriacato la gente con 'sto casino. Tanto alla fine ai non addetti ai lavori basterà ricordare due sole sigle: OpenCL e DirectX11.

[appleroof]

Originariamente inviato da Mercuri0

Certo che era tutto calcolato, anzi era proprio scontato. Per questo un pò mi meravigliavo di non essere capito quando profetizzavo OpenCL.
Non era mica un segreto che nVidia partecipasse attivamente alla stesura di OpenCL. Solo che non usciva nelle press-release pubblicitarie, per qualche motivo.


Concordissimo, in ambiti non consumer ha senso usare linguaggi specifici.

A vedere le slide su TechReport, sembra che quello che abbiamo sempre chiamato "CUDA" sia ora diventato "C for CUDA", e con "CUDA" ora nVidia si riferisce a qualcosa di simile alla CAL di AMD.

OpenCL girerà su CUDA per nVidia e su CAL per AMD, insieme ad altri eventuali linguaggi e API.
(in sostanza AMD & nVidia forniranno una dll che farà da traduttore da OpenCL->CUDA/CAL)

Curiosamente, C for CUDA è più ad alto livello (nel senso più lontano dall'hardware) rispetto a OpenCL, tant'è che la gente aveva chiesto se C for CUDA sia in grado di pareggiare OpenCL in prestazioni...

Vabbé, spero di non aver ubriacato la gente con 'sto casino. Tanto alla fine ai non addetti ai lavori basterà ricordare due sole sigle: OpenCL e DirectX11.

ma infatti non mi riferivo a te in particolare, ma a tutti quelli che profetizzavano la morte di CUDA tout-court....cmq stiamo a vedere, lo scenario che indichi è molto interessante

[Stefem]

Originariamente inviato da Mercuri0

Certo che era tutto calcolato, anzi era proprio scontato. Per questo un pò mi meravigliavo di non essere capito quando profetizzavo OpenCL.
Non era mica un segreto che nVidia partecipasse attivamente alla stesura di OpenCL. Solo che non usciva nelle press-release pubblicitarie, per qualche motivo.


Concordissimo, in ambiti non consumer ha senso usare linguaggi specifici.

A vedere le slide su TechReport, sembra che quello che abbiamo sempre chiamato "CUDA" sia ora diventato "C for CUDA", e con "CUDA" ora nVidia si riferisce a qualcosa di simile alla CAL di AMD.

OpenCL girerà su CUDA per nVidia e su CAL per AMD, insieme ad altri eventuali linguaggi e API.
(in sostanza AMD & nVidia forniranno una dll che farà da traduttore da OpenCL->CUDA/CAL)

Curiosamente, C for CUDA è più ad alto livello (nel senso più lontano dall'hardware) rispetto a OpenCL, tant'è che la gente aveva chiesto se C for CUDA sia in grado di pareggiare OpenCL in prestazioni...

Vabbé, spero di non aver ubriacato la gente con 'sto casino. Tanto alla fine ai non addetti ai lavori basterà ricordare due sole sigle: OpenCL e DirectX11.

A dire il vero il C in ambiente CUDA veniva definito "C for CUDA" fin dal suo rilascio, CUDA non è mai stato un linguaggio, infatti da tempo supporta C++, Java, Fortran e Python, ma è un ambiente di sviluppo che permette di unificare la programmazione su diverse famiglie di GPU in modo da non dover scrivere applicazioni per ognuna di esse.
Questo è ora, e lo è sempre stato, a differenza di CtM, CAL, Stream

[bLaCkMeTaL]

ragazzi, per come la vedo io,

OpenCL sta ad ASSEMBLER come CUDA stà a C.

Sicuramente lo standard avrà dalla sua la "flessibilità" di gestire l'HW in modo diretto, mentre l'utilizzo di CUDA porterà ad una astrazione relativa alla programmazione delle GPU.
Detta così OpenCL sembra uno standard "difficile" da maneggiare, mentre CUDA sicuramente porterà con se svariate librerie già pronte in grado di accelerare lo sviluppo di compiti GPU-oriented.

[t0mcat]

l'ultima parte della news è abbastanza imprecisa.

La gestione diretta della memoria è possibile tanto con OpenCL che con "C for CUDA", visto che entrambi sono basati su C e prevedono simili chiamate di basso livello in stile C, che comunque alla fine è sempre un linguaggio di livello più medio che alto, se per alto intendiamo Java e C++.
OpenCL quindi non è di basso livello, non ha niente a che vedere con il livello di Assembler, anzi, è anni luce più astratto; sarà usato "a un livello più basso di CUDA" perché "C for CUDA" contiene già di suo molte strutture e procedure già pronte, che permettono di sviluppare più velocemente e a un livello di astrazione più alto, fintanto che avranno hardware Nvidia.
Chi vorrà implementare le stesse funzioni di "C for CUDA" su altro hardware, dovrà replicarle riscrivendole da capo in OpenCL, anche se non sempre sarà possibile visto che "C for CUDA" permette alcune cose che sfruttano peculiarità dell'hardware nvidia.
Per interfacciare quest'ultimo con le proprie gpu, è probabile che Nvidia non farà altro che implementare qualche sorta di wrapper tra OpenCL e CUDA, così come hanno fatto terzi per linguaggi diversi dal C, tipo python e java.

Per inciso, comunque, CUDA in senso lato è l'architettura dell'engine di general purpose computing implementata a livello sia driver che hardware da nvidia, e "C for CUDA" è l'API per usare l'engine tramite un linguaggio C-style.
Pertanto è chiaro che CUDA non può morire, perché servirà ad usare il GPGPU di Nvidia a prescindere dal linguaggio che si usa, sia esso "C for CUDA", OpenCL, PyCUDA, etcetc.

L'imprecisione della news probabilmente è scaturita dal fatto che OpenCL mette a disposizione alcuni strumenti di compilazione che operano a livello di bytecode.

[Mercuri0]

Originariamente inviato da Stefem

A dire il vero il C in ambiente CUDA veniva definito "C for CUDA" fin dal suo rilascio, CUDA non è mai stato un linguaggio, infatti da tempo supporta C++, Java, Fortran e Python, ma è un ambiente di sviluppo che permette di unificare la programmazione su diverse famiglie di GPU in modo da non dover scrivere applicazioni per ognuna di esse.
Questo è ora, e lo è sempre stato, a differenza di CtM, CAL, Stream

Oki, ora è tutto chiaro, anche se spesso ci si è riferiti al "C for CUDA" chiamandolo solo CUDA.

Ma a questo punto perché dici che CUDA (senza "C for") sarebbe diverso da CAL? A me sembra che occupino la stessa funzione. CAL è una interfaccia astratta dall'hardware che AMD usa per non dover riscrivere le applicazioni su ogni familia di GPU.

Infatti anche brook+ gira su CAL, "brook for CAL" ^^''. CtM non esiste più dalle x1xxx, e Stream è solo un marchio commerciale.

[t0mcat]

hmm, è un po' confusa come cosa: fondamentalmente CUDA fa per Nvidia quello che CTM faceva per AMD e che ora sta sotto il nome di Stream, il quale non è semplicemente un marchio: CTM è stato riscritto prima di essere rilasciato sotto il nome di Stream, ed è l'interfaccia hardware tramite la quale si può accedere via CAL (basso livello) o Brook (alto livello, C-like).
Il problema è che, al pari di CUDA, con Stream non ci si riferisce solo all'interfaccia di livello driver/hardware, ma anche alle API che stanno sopra.

In soldoni:
Brook (API) non gira su CAL (API), sia Brook che CAL girano su CTM (implementazione hw/driver)
tutti assieme costituiscono Stream (environment).
così come "C for CUDA" (API) gira su CUDA (implementazione hw/driver) e con CUDA (environment) ci si riferisce indifferentemente ad entrambi, separatamente o assieme!

Porca miseria che casino!