Link alla notizia: http://www.hwupgrade.it/news/cpu/opencl-diventa-ufficialmente-uno-standard_27443.html

Con la pubblicazione delle specifiche 1.0, OpenCL diviene ufficialmente il primo standard aperto e gratuito per la programmazione parallela

Click sul link per visualizzare la notizia.

Evvaiii! Era ora!
Finalmente forse si comincerà ad avere un po' di ordine e una piattaforma su cui basarsi valita per ATI e NVIDIA!!!

son proprio curioso di verlo all' opera e magari di vedere cosa ne sarà fatto su linux e sui vari CAD.

dubito che in ambito cad si utilizzerà ciò che propone microsoft con Vista2 & directx11

Occhio che OpenCL non è GL quindi con la grafica CAD non c'entra nulla.

Comunque son contento, ci voleva, altro che cuda ($) o stream (free)

Ora voglio il supporto di openCL per tutte le schede vieo e nei sw per conversione video, in primisi virtualdub e autoGK relativo

molto interessante vedrete che gli ambienti di sviluppo cad ne avranno grande giovamento per la fase di rendering adesso però ci vorrebbero schede video con registri a 32 bit.

si ovvio che non centra nulla, ma i cad ora come ora hanno bisogno di più potenza...
in gernere su una WS hai discrete schede video...
mi sembra un passo logico

ragazzi ma queste openCL usciranno anche per windows vista o XP?

sono curioso di vedere come sarà implementato dalla nVidia sulle sue schede : una Tesla costa quasi 1400 auro mentre invece una Geforce 280 GTX attorno ai 400 ma sono praticamente la stessa identica scheda con lo stesso processore , l'unica differenza è la memoria Ram che arriva a 4 Gb sulla Tesla.

quindi, se i programmi scritti in OpenCL potranno sfruttare entrambe le schede , che senso ha spendere così tanto per una Tesla ???

perchè se hai 4 gb di dati da maneggiare li porti in sgram e non li lasci sulla memoria centrale portandoli avanti ed indietro ? no ?

sono curioso di vedere come sarà implementato dalla nVidia sulle sue schede : una Tesla costa quasi 1400 auro mentre invece una Geforce 280 GTX attorno ai 400 ma sono praticamente la stessa identica scheda con lo stesso processore , l'unica differenza è la memoria Ram che arriva a 4 Tb sulla Tesla.

quindi, se i programmi scritti in OpenCL potranno sfruttare entrambe le schede , che senso ha spendere così tanto per una Tesla ???

:sbavvv: :asd:

beh vedendo la presenza di intel, ibm, broadcom, penso che avra' un eccellente supporto unix/linux, dato che sono aziende che lo appoggiano spesso e volentieri (le prime due lavorano anche molto sul kernel)

perchè se hai 4 gb di dati da maneggiare li porti in sgram e non li lasci sulla memoria centrale portandoli avanti ed indietro ? no ?
1000 euro in più per 3 Gb di Ram mi sembran tantini ...e non è detto che non escano schede video geforge con uguale quantitativo di ram in futuro

quindi , secondo me, la nVidia non deve vedere tanto si buon occhio questo standard.

:sbavvv: :asd:
lapsus :asd:

L'inizio di una nuova era?
:sperem: :sperem: :sperem:

dos se mi serve oggi lo compro oggi, ci sono software house che cambiano cpu ogni 6 mesi per non sprecare neppure un secondo per compilare i loro programmi.
secondo me tesla è un sistema pilota, è acquistato da sh che si stanno portando avanti con cuda e devono testare il loro software che correrà tra 2 anni su un casino di pc "normali"

Hmmm, Microsoft non è nell'elenco dei contributori.
Questo significa che con tutta probabilità starà già sviluppando una sua API concorrente, da inserire in qualche futura versione di DirectX, magari da legare arbitrariamente a una qualche futura versione di Windows. E tutti gli sviluppatori punteranno quella.

La notizia è comunque ottima per gli utenti di Linux, OSX o in generale di qualunque piattaforma hardware/software diversa da una versione di Windows.

Hmmm, Microsoft non è nell'elenco dei contributori.
Questo significa che con tutta probabilità starà già sviluppando una sua API concorrente, da inserire in qualche futura versione di DirectX, magari da legare arbitrariamente a una qualche futura versione di Windows. E tutti gli sviluppatori punteranno quella.

La notizia è comunque ottima per gli utenti di Linux, OSX o in generale di qualunque piattaforma hardware/software diversa da una versione di Windows.

mmm... osservazione interessante..
Vuoi dire che assisteremo allo scontro DX11 - OpenCL??
brutta cosa... :mad:

Mi auguro almeno che il sistema openCL prenda forma come applicativo di terze parti da installare sotto windows a uso java o directX.. mi farebbe abbastanza incazzare vedere openCL come unico appannaggio di linux o OSX..

Occhio che OpenCL non è GL quindi con la grafica CAD non c'entra nulla.

Comunque son contento, ci voleva, altro che cuda ($) o stream (free)

Ora voglio il supporto di openCL per tutte le schede vieo e nei sw per conversione video, in primisi virtualdub e autoGK relativo

Guarda che CUDA è free quanto Stream...:rolleyes:

Mi auguro almeno che il sistema openCL prenda forma come applicativo di terze parti da installare sotto windows a uso java o directX.. mi farebbe abbastanza incazzare vedere openCL come unico appannaggio di linux o OSX..

Non me ne intendo, ma penso che i produttori di schede video potranno tranquillamente supportarlo anche sotto Windows, basta che sia standardizzata in qualche modo l'interfaccia fra applicazioni e driver, anche senza la benedizione di chi sviluppa il sistema operativo, un po' come succede oggi per OpenGL.

Solo che probabilmente farne uso non sarà la scelta preferita degli sviluppatori, soprattutto quando sarà disponibile un'api "nativa" di Windows per fare più o meno la stessa cosa ;) .

"Le librerie OpenCL ed il linguaggio di programmazione relativo, infatti, saranno utilizzabili con qualunque tipo di processore: ciò significa che anche smartphone, palmari, console, lettori multimediali potranno beneficiare della programmazione in OpenCL."

Questo significa che qualunque scheda grafica sarà supportata?

Yahoooooo!, ora si che iniziamo finalmente a ragionare.
A parte gli ambiti specialistici, che non mi riguarda, la ratificazione di uno standard permetterà finalmente la creazione di decoder video che decodificano tutti i formati sfruttando la gpu, lasciando la cpu libera per l'applicazione di filtri.
Il sogno di un qualsiasi maniaco di htpc! :sofico:

:winner:

E brava Apple :D

Tratto dal progetto C99 portato avanti da Apple
:mbe: Vabbé, nell'entusiasmo i nostri eroi si son confusi
http://en.wikipedia.org/wiki/C99

Hmmm, Microsoft non è nell'elenco dei contributori.
Questo significa che con tutta probabilità starà già sviluppando una sua API concorrente, da inserire in qualche futura versione di DirectX, magari da legare arbitrariamente a una qualche futura versione di Windows. E tutti gli sviluppatori punteranno quella.

MS sta lavorando alle DX11 che includeranno le compute shader. Ma a parte atti di terrorismo informatico, OpenCL ci sarà anche su windows. Se non altro, perché fa comodo scrivere programmi che girano sia su Win che su Mac ;)

Per il GPGPU nei giochi (tipo accelerazione fisica) credo che si punterà sulle DX11, a meno che le console non ci mettano lo zampino.

Comunque non credo che MS non ci abbia messo lo zampino anche in OpenCL, magari sotto copertura. :asd:


Questo significa che qualunque scheda grafica sarà supportata?
No. Per le schede grafiche PC aspettati le Radeon dalla 2xxx in su e le nVidia dalle 8xxx in su. Magari sarà supportato anche dagli IGP lntel, ma sarebbe completamente inutile...

A corredo di questo, segnaliamo come il presidente di Khronos sia Neil Trevett, non a caso anche Vice presidente dei Mobile content in Nvidia stessa.
E per par condicio segnalamo il redattore delle specifiche di OpenCL, ex ATI assunto dall'apple all'uopo ;)
http://www.linkedin.com/pub/3/57a/359

Guarda che CUDA è free quanto Stream...:rolleyes:

Vero sullo sviluppo, ma attualmente non ci sono programmi Free per poter utilizzare CUDA...;)

ho capito bene?

mi sorgono alcune domande..
- che vuol dire programmare su gpu senza imparare un linguaggio specifico?
- è una cosa già supportata dalle sk video/cpu o no?
- se uso opencl per fare un qualunque programma questo riesce a sfruttare assieme sia la cpu che la gpu per fare i calcoli?
- potrei scriverci tipo... openoffice?
- è come java?
- linux ne gioverà?
- l' articolo dice che opencl è basato su C.. ma anche cuda, non è basato su C? che differenza c'è?

danke!

[chi è esperto non mi fucili] ;-)

so che c'è un qualcosa per far girare SPM con cuda in matlab!!!! spero che passino a Open CL, almeno lo posso linuxare tutto (Spm gira già in matlab linux :D)

Vorrei inoltre far notare che il giorno dopo dell'annuncio di OpenCL, NVID*A ha altresì dichiarato di aver aggiornato C*DA per il PIENO SUPPORTO allo standard OpenCL 1.0:
http://news.softpedia.com/news/NVIDIA-Also-Adds-OpenCL-Support-99657.shtml

Non basta?

NVID*A ha inoltre affermato di stare lavorando per garantire un pieno supporto anche allo Stream Computing dato dalle DirectX 11, e non vuole abbondonare neppure C*DA, che nel 2009 arriverà alla versione 3.0:
http://www.engadget.com/2008/12/09/nvidia-dishes-about-opencl/

- che vuol dire programmare su gpu senza imparare un linguaggio specifico?
Penso intendesse "specifico per ciascuna GPU".

- è una cosa già supportata dalle sk video/cpu o no?

No, ma i driver usciranno nella prima metà del 2009.

- se uso opencl per fare un qualunque programma questo riesce a sfruttare assieme sia la cpu che la gpu per fare i calcoli?

Dipende dai driver, ma direi di sì. Solo che i conti che vengono meglio alla GPU li farà la GPU, quelli che vengono meglio alla CPU li farà la CPU.

- potrei scriverci tipo... openoffice?

Potresti usarlo per scriverci una parte di openoffice a cui gioverebbe il GPGPU (ma non mi viene in mente niente per openoffice ^^'')

- è come java?

non c'entra niente, è più come OpenGL.
- linux ne gioverà?
Si

- l' articolo dice che opencl è basato su C.. ma anche cuda, non è basato su C? che differenza c'è?

Sia il rumeno che il francese sono lingue romanze basate sul latino... :D

Vorrei inoltre far notare che il giorno dopo dell'annuncio di OpenCL, NVIDIA ha altresì dichiarato di aver aggiornato CUDA per il PIENO SUPPORTO allo standard OpenCL 1.0:
http://news.softpedia.com/news/NVIDIA-Also-Adds-OpenCL-Support-99657.shtml

Azz... finalmente ti sei accorto anche tu che anche nVidia fa parte del Khronos Group? ( :asd: )
Ce ne hai messo di tempo, eh ;) Comunque oggi è giorno di festa :)

(Sia nVidia che AMD stavano provando internamente le bozze dei driver OpenCL mentre scrivevano insieme le specifiche. Si nota la differenza con CUDA, CAL e broccoli vari, sì? sta tutta in quell'avverbio.)

Le OCL su Windows, come le OGL, vengono introdotte dal supporto driver, cosa che oggi copre sia le GPU ATI, con Stream, sia le GPU NVIDIA, con CUDA. Per quanto riguarda il supporto alle istruzioni OCL da parte della suite di API DirectX esso verrà introdotto con le DirectX 11 per NT6 e NT7 entro fine 2009 con il compute shader, direttiva dello Shader Model 5.0, e fuibile anche per GPU con SM 4.0 e 4.1 (per il 3.0 ne duvito ne verrà implementato mai il supporto, per 2.0/b economicamente sarebbe da ritardati mentali).

grazie!

non male l' ultima risposta.. rende bene l' idea!! ;-)

Azz... finalmente ti sei accorto anche tu che anche nVidia fa parte del Khronos Group? ( :asd: )
Ce ne hai messo di tempo, eh ;) Comunque oggi è giorno di festa :) Non so se incazzarmi e quindi offenderti oppure se il tuo reply è simpatico e quindi farti anche io l'occhietto amicizia

Nel dubbio tengo un andamento basso, dato che sono pure a rischio cartellino avendo osato toccare un amichetto dei moderatori, e quindi mi limito a dire che sono stato fra i primi a dire che NVID*A faceva parte del Kronos (mentre tutti gli altri erano intenti a sbrodolare il competitor, credendo che solo lui ne facesse parte), e ti riporto anche
un mio reply datato 25/11/2008 (http://www.hwupgrade.it/forum/showpost.php?p=25166523&postcount=22) (2 settimane fa):

Ah, l'attuale presidente del Khron*s Group (che è il consorzio che si preoccupa di ratificare, fra gli altri, lo standard OpenCL), è Neil Trevett.

Neil Trevett è colui che si è interamente occupato della ratifica dello standard OpenGL ES (standard usato in Android, iPhone, PS3, Symbian, Pandora).

Senza dimenticarci di OpenVG, OpenMAX, COLLADA, e OpenSL ES, di cui NVID*A si è fortemente preoccupata.

Neil Trevett è inoltre l'attuale Vice-Presidente del settore "Embedded Content", in una azienda chiamata "NVIDIA Corporation" (emh...).

Questo giusto per zittire qualche "tifo rosso" un po' di troppo.

Così magari ci pensi un po' su.

Io francamente avrei gradito un'approccio differente piuttosto che l'ennesima nuova API. Supponendo di dover scrivere un'applicazione multipiattaforma, soprattuto in ambito grafico, si dovrebbero usare:

1) OpenGL per la grafica pura.
2) OpenGL Shading Language per gli shader.
3) OpenMP per il codice parallelo CPU.
4) OpenCL per il codice parallelo GPGPU.
5) Varie ed eventuali API per tutto il resto.

Non era possibile strutturare il GPGPU in stile DirectX con i compute shader, ovvero aggiungendo una nuova estensione al GLSL? O meglio, non era meglio unificare OpenCL 1.0 con le specifiche OpenMP 3.0?

No. Per le schede grafiche PC aspettati le Radeon dalla 2xxx in su e le nVidia dalle 8xxx in su. Magari sarà supportato anche dagli IGP lntel, ma sarebbe completamente inutile...

beh un trasferimento dei calcoli (stile physX) sull'igp intel io nn lo vedo tanto male.... anzi...
potrebbe funzionare come co-co-subprocessore :asd:

o magari sub-co-co-co-processore...
un subprocessore con contratto co.co.co. ... scusate non ho resistito :asd::asd::rotfl: :rotfl: :rotfl:

Non era possibile strutturare il GPGPU in stile DirectX con i compute shader, ovvero aggiungendo una nuova estensione al GLSL? O meglio, non era meglio unificare OpenCL 1.0 con le specifiche OpenMP 3.0?

attualmente dovrebbe essere meglio ,perché così tale standard non si legherà ad una soluzione professionale e si adatterà ai prezzi del mercato consumer .

sempre che i driver nVidia e ATI per le schede grafiche non professionali permettano una piena funzionalità.

beh vedendo la presenza di intel, ibm, broadcom, penso che avra' un eccellente supporto unix/linux, dato che sono aziende che lo appoggiano spesso e volentieri (le prime due lavorano anche molto sul kernel)

"boradcom" e "supporto linux" non dovrebbero stare nella stessa frase

"boradcom" e "supporto linux" non dovrebbero stare nella stessa frase

Se seguiamo i dettami di Stallman e il free software certamente no. Se seguiamo i lati pratici della vita, è una delle poche aziende che rilascia nativamente driver anche per Linux. Sarà poco rispetto a quello che vuole la FSF o i bigotti dell'open source ma è sicuramente qualcosa in piu' di quello che fanno molte aziende.

attualmente dovrebbe essere meglio ,perché così tale standard non si legherà ad una soluzione professionale e si adatterà ai prezzi del mercato consumer .

sempre che i driver nVidia e ATI per le schede grafiche non professionali permettano una piena funzionalità.

Scusa ma che c'entra con la mia richiesta? Cosa c'entra il legarsi a soluzioni professionali con il chiedere di avere uno standard unificato che includa le specifiche OpenMP 3.0 / OpenCL 1.0?

Non me ne intendo, ma penso che i produttori di schede video potranno tranquillamente supportarlo anche sotto Windows, basta che sia standardizzata in qualche modo l'interfaccia fra applicazioni e driver, anche senza la benedizione di chi sviluppa il sistema operativo, un po' come succede oggi per OpenGL.
Che infatti è snobbato dal 98% delle software house, e che viene utilizzato dalla restante parte solo per accordi commerciali con la Apple...

Solo che probabilmente farne uso non sarà la scelta preferita degli sviluppatori, soprattutto quando sarà disponibile un'api "nativa" di Windows per fare più o meno la stessa cosa ;) .

E' proprio questo la fregatura... finché non ci saranno degli standard unici e aperti/accessibili da tutti gli os... non avremo mai vera concorrenza, specie nei videogame... :cry:
Es. su Linux con Wine riesco a giocare a World of Warcraft, con performance inferiori, ma perché la Blizzard ha inserito il supporto OpenGL per OSX... altrimenti stavo fresco... :muro: Ma parliamo di uno splendido OS di nicchia che vuol rimanere tale... (imho ovviamente).


1) OpenGL per la grafica pura.
2) OpenGL Shading Language per gli shader.
3) OpenMP per il codice parallelo CPU.
4) OpenCL per il codice parallelo GPGPU.
5) Varie ed eventuali API per tutto il resto.


Ma così mi fai sognare ad occhi aperti! :eek:
Spero che un giorno potremo scegliere liberamente... senza avere restrizioni di sorta nell'uso dei nostri pc... :(

Purtroppo ho l'impressione che Microsoft ci metterà lo zampino e alla fine farà fare alle OpenCL la fine delle OpenGL...

sono curioso di vedere come sarà implementato dalla nVidia sulle sue schede : una Tesla costa quasi 1400 auro mentre invece una Geforce 280 GTX attorno ai 400 ma sono praticamente la stessa identica scheda con lo stesso processore , l'unica differenza è la memoria Ram che arriva a 4 Tb sulla Tesla.

quindi, se i programmi scritti in OpenCL potranno sfruttare entrambe le schede , che senso ha spendere così tanto per una Tesla ???

E' un'errore di battitura vero? :D 4 tb sono TANTINI O.O (tipo che per i prossimi 15 anni non mi servirebbe cambiare scheda video per i giochi causa sufficente spazio per le texture... quindi sarebbe un discreto affare O.o)

errata corrige:
non volevo dire broadcom ma atheros che rilascia i driver opensource :)

che poi broadcom li rilasci chiusi, beh lo fanno anche nvidia e ati, e male non fa

edit errata corrige:
broadcom a gennaio ha rilasciato i driver semiopensource (il codice è in parte aperto) per tutti i suoi chip 43xxx

Non so se incazzarmi e quindi offenderti oppure se il tuo reply è simpatico e quindi farti anche io l'occhietto amicizia

Si faceva per scherzare, non volevo assolutamente offenderti :cincin: , lo sai che sei uno dei miei preferiti da queste parti.

Mi sono solo fatto un pò prendere dall'entusiasmo, sono 2 mesi che in ogni discussione postavo "Ma quale CUDA e CAL, ci vogliono robe come OpenCL che tanto uscirà nel 2009", e sono contento che le specifiche siano uscite prima di quello che mi aspettavo :D

Inoltre ho sfogliato i nomi di chi ha collaborato alle specifiche (ci sono nello stesso documento) ed è esaltante vedere come la créme della créme di aziende concorrenti possa lavorare assieme, alla faccia dei fanboy :)

errata corrige:
non volevo dire broadcom ma atheros che rilascia i driver opensource :)

che poi broadcom li rilasci chiusi, beh lo fanno anche nvidia e ati, e male non fa
Mi aspetto che il supporto OpenCL avverrà con una libreria di traduzione OpenCL->CUDA per nVidia, e OpenCL->CAL per AMD.

Siccome CUDA & CAL sono disponibili anche per Linux, non dovrebbero esserci problemi per OpenCL. Lo stesso vale anche per Windows (anzi, probabilmente nVidia & AMD riuseranno lo stesso codice tra win, mac e linux).

Difficile che rilascino la libreria OpenCL opensource, probabilmente vorranno mantenere segreti alcuni segreti. E' però possibile che la community decida di scriverne una propria implementazione, casomai servisse a quacosa.

Se seguiamo i dettami di Stallman e il free software certamente no. Se seguiamo i lati pratici della vita, è una delle poche aziende che rilascia nativamente driver anche per Linux. Sarà poco rispetto a quello che vuole la FSF o i bigotti dell'open source ma è sicuramente qualcosa in piu' di quello che fanno molte aziende.

Guarda che c'è poco di bigotto a richiedere le specifiche dell'hardware. Linux non ha un'interfaccia stabile per i driver, quindi i binari tendono a funzionare solo per la particolare versione di Linux per cui sono stati scritti - e questo è un "lato molto pratico della vita".
Considerato che tutti gli altri produttori di chip wireless le rilasciano, non si capisce cosa abbia impedito a Broadcom di fare lo stesso, se non il totale disinteresse verso la comunità che ha tanto contribuito al suo successo commerciale (tutte le sue piattaforme di riferimento sono basate su Linux, qualcuna su vxWorks).

E no, Broadcom non è una "delle poche aziende che rilasciano i driver nativi per Linux" - Intel, Atheros, ZyDas, RaLink hanno rilasciato non solo le specifiche (che non gli costano niente) ma addirittura i sorgenti completi per i loro driver, mentre Broadcom originariamente non rilasciava proprio niente, neanche un driver chiuso (solo driver precompilati per MIPS, da usare sui router di sua produzione, inutilizzabili su x86 se non previo disassamblaggio).

Finalmente sotto le pressioni di "bigotti dell'open source" tipo Dell, Broadcom si è "abbassata" a rilasciare un driver chiuso - 4 anni dopo l'uscita del prodotto - però nessuno mi fa dimenticare che per 4 anni sono stato costretto a usare driver reverse-engineered, resi disponibili grazie agli sforzi di programmatori amatoriali a dir poco eroici. Grazie a loro, che hanno pubblicato le specifiche reverse-engineered, posso sperare, ad esempio, che un giorno avrò un driver per Solaris per la mia schedina BCM4318 (be', prima che la Sun fallisca :)) e che su Linux potrò sempre godere della mia scheda wireless

edit errata corrige:
broadcom a gennaio ha rilasciato i driver semiopensource (il codice è in parte aperto) per tutti i suoi chip 43xxx

No, prova un po' a scaricarli... sono i soliti blob chiusissimi, con una colla di sorgenti per compilarli contro la versione specifica del kernel. :(

ah ecco non li ho scaricati, ma sul sito opensuse la novell ha pubblicato una patch per patacharli e adattarli ai suoi kernel piu' recenti...

quindi non mi ero ancora "interessato", non avendo ancora installato linux sul mio hp non ho potuto provare direttamente :)


cmq all'inizio volevo intendere atheros ;)

ma dico io... non vuoi sviluppare driver opensource... ok, fai come nvidia, che ogni due versioni per windows ne fa una linux (piu' o meno) funzionante, aggiornata, e che si autocompila a seconda del kernel....


cmq tornando a noi

beh io penso che ci siano buone probabilita' di avere implementazioni native linux, essendo cmq uno standard, e per quanto vuoi allontanartici, a meno che non usi piattaforme totalmente proprietarie... è difficile allontanarsi da una interoperabilita' tra sistemi operativi, tantopiu' che ibm lo usera' sulle sue workstation e i suoi mainframe, quindi sara' interessanta molto al mondo unix linux in generale,
inoltre a quanto capisco dovranno essere librerie totalmente slegate dal sistema
infatti si parla anche di aziende di telefonia mobile (e non dimentichiamo che nokia è proprietaria di trolltech, e delle qt, quindi ha tutto l'interesse ad avere migliorie prestazionali con chip video da telefonino) (ericsson e motorola ora sono nell'open handset alliance) etc

alla fine se tutto va come SEMBRA (cioe' dalla teorica serieta' di molte aziende presenti) potrebbe essere uno standard veramente standard e funzionante dovunque e in qualunque modo ;)

E no, Broadcom non è una "delle poche aziende che rilasciano i driver nativi per Linux" - Intel, Atheros, ZyDas, RaLink hanno rilasciato non solo le specifiche (che non gli costano niente) ma addirittura i sorgenti completi per i loro driver, mentre Broadcom originariamente non rilasciava proprio niente, neanche un driver chiuso (solo driver precompilati per MIPS, da usare sui router di sua produzione, inutilizzabili su x86 se non previo disassamblaggio).


Parliamo di originariamente o di adesso? Tutto l'hardware Broadcom che ho sul mio notebook è nativamente supportato dal kernel. Magari non per merito loro, in ogni caso per il mio hardware ci sono tutti i driver. Semplici blob, ma ci sono. Quindi al di la di tutte le vicissitudini e la storia che ci sta dietro, determinati hardware broadcom sono supportati. Non è certo rosea come situazione ma non è nemmeno merda.


No, prova un po' a scaricarli... sono i soliti blob chiusissimi, con una colla di sorgenti per compilarli contro la versione specifica del kernel. :(

E' la stessa situazione che propina nVidia. Ringrazia Dio che ce li hai almeno.

alla fine se tutto va come SEMBRA (cioe' dalla teorica serieta' di molte aziende presenti) potrebbe essere uno standard veramente standard e funzionante dovunque e in qualunque modo ;)

Sì, è il bello di quando gli standard sono formati da consorzi larghi anziché dettati da una singola azienda - si aumentano le libertà dello sviluppatore e del consumatore.

Anche OpenGL è uno standard di questo tipo, però la sua adozione sulla piattaforma Windows è oggi scarsa (praticamente si usa DirectX su Windows, e OpenGL in tutto il resto del mondo, inclusi Linux, Mac, console e dispositivi embedded).
In teoria potrebbe non fregarmene niente, in pratica Windows è oggi il mercato più importante per le schede video e forma una quantità enorme di programmatori - quindi se vogliamo che in futuro OpenCL sia costantemente aggiornato e supportato dai produttori di hardware, sarà importante che OpenCL abbia successo su Windows.

Parliamo di originariamente o di adesso? Tutto l'hardware Broadcom che ho sul mio notebook è nativamente supportato dal kernel. Magari non per merito loro, in ogni caso per il mio hardware ci sono tutti i driver. Semplici blob, ma ci sono. Quindi al di la di tutte le vicissitudini e la storia che ci sta dietro, determinati hardware broadcom sono supportati. Non è certo rosea come situazione ma non è nemmeno merda.


Ci tenevo semplicemente a precisare che Broadcom è una delle aziende peggiori per quanto riguarda il supporto dei propri clienti che scelgono Linux.
Prima: supporto zero. Adesso: supporto minimo.
Se le cose funzionano è importante attribuire i meriti a chi li ha, così il cliente prima di scegliere il suo prossimo prodotto potrà decidere quale azienda premiare.


E' la stessa situazione che propina nVidia. Ringrazia Dio che ce li hai almeno.

A nVidia va un ringraziamento particolare perché mantiene driver Linux di qualità alta, anzi è probabilmente l'unica azienda che lo fa, tutti gli altri driver binari che abbia mai usato sono stati solo fonte di instabilità e scocciature.

Detto questo, io non devo ringraziare nessuna divinità per il fatto di possedere una scheda nVidia - l'ho pagata con soldi immanenti e per questo ho tutto il diritto di chiedere a nVidia di essere libero di farne l'uso che più ritengo appropriato. Se nVidia ritiene che la mia soddisfazione in quanto cliente sia meno importante della segretezza dei registri delle sue schede, passerò ad Ati che evidentemente la pensa in modo diverso.

Ahhh... ohhh... uuhhh... mmmh... siddai ancora.... uuuh come godo....

mmmmm commento alquanto discutibile
anche perchè si dovrebbe scrivere "si, dai ancora" o al massimo "si dai, ancora" siddai ancora, sembra piu' una parola indiana





tutto questo
ASD

A parte i gemiti di godimenti di cui ci avete voluto far partecipi :D non mi è chiara una cosa... mettiamo io riuscissi con l'intercessione di San Linus Torwald e San Richard Stallman Martire a compilare un banale Hello World cosa otterrei un eseguibile per la CPU o qualcosa di più esotico?
Cioè la CPU deve sempre esser messa in mezzo non può star tutto sulla CPU e poi il produttore i scheda grafica deve creare devi driver apposta, vero?
Cioè ora del mio eseguibile compilato non me ne farei una mazza giusto?
Nel manuale di 3000 pagine che ho scaricato parlano di runtime e codice che sembra compilato dinamicamente... c'è di mezzo una sorta di macchina virtuale tipo JAVA o .NET?

Comunque la trovo una tecnologia interessante soprattutto nel campo HTPC pensate ai codec che finalmente potrebbe beneficiare della GPU in tutti i campi (non solo in quelli decisi da ATI e Nvidia), i filtri di ffdshow e avisinth potrebbero fare cose stratosferiche e questo con CPU pressoché scarica...

Il mio timore è che se devono far dei driver appositi possano decidere di troncare il supporto a GPU vecchie o addirittura vendere OpenCl come una feature disponibile solo a partire dalla prossima generazione di GPU (ATI 5x00 e NVIDIA 10000?).

Speriamo non facciano troppo i furbini io la mia NVIDIA 6150 integrata :sofico: la voglio poter sfruttare... poi magari andrà tutto a scatti, però voglio essere IO a decidere che non serve a una mazza non loro :D

Ciao,
fano

La tua 6150 mi sa che CUDA nemmeno sa che esiste

A parte i gemiti di godimenti di cui ci avete voluto far partecipi :D non mi è chiara una cosa... mettiamo io riuscissi con l'intercessione di San Linus Torwald e San Richard Stallman Martire a compilare un banale Hello World cosa otterrei un eseguibile per la CPU o qualcosa di più esotico?
Cioè la CPU deve sempre esser messa in mezzo non può star tutto sulla CPU e poi il produttore i scheda grafica deve creare devi driver apposta, vero?
Cioè ora del mio eseguibile compilato non me ne farei una mazza giusto?
Nel manuale di 3000 pagine che ho scaricato parlano di runtime e codice che sembra compilato dinamicamente... c'è di mezzo una sorta di macchina virtuale tipo JAVA o .NET?

Comunque la trovo una tecnologia interessante soprattutto nel campo HTPC pensate ai codec che finalmente potrebbe beneficiare della GPU in tutti i campi (non solo in quelli decisi da ATI e Nvidia), i filtri di ffdshow e avisinth potrebbero fare cose stratosferiche e questo con CPU pressoché scarica...

Il mio timore è che se devono far dei driver appositi possano decidere di troncare il supporto a GPU vecchie o addirittura vendere OpenCl come una feature disponibile solo a partire dalla prossima generazione di GPU (ATI 5x00 e NVIDIA 10000?).


Se leggi bene la notizia, OpenCL non è un toolkit pensato per la programmazione parallela su CPU (che è invece appannaggio di OpenMP e MPI) ma per il GPGPU computing. Ciò significa che non serve per "parallelizzare un programma intero" ma soltanto parallelizzare degli algoritmi di calcolo facendoli eseguire mediante GPU. Stessa cosa dicasi per OpenMP su CPU generica. Non si può parallelizzare tutto, quindi il discorso che hai fatto presenta un'errore di fondo. I programmi paralleli sono comunque programmi seriali che eseguono alcuni algoritmi in modo parallelo. Se serve un'operazione generica su CPU, si usa OpenMP. Se serve un'operazione meglio eseguita da una GPU si usa OpenCL. Per quanto riguarda l'implementazione, OpenCL sotto questo aspetto non è diversa da OpenGL: è pur sempre un'API che deve poter accedere in qualche modo alla GPU. Di conseguenza, richiede un supporto driver. L'implementazione della libreria, esattamente come OpenGL, può essere fornita da un produttore indipendente. Resta il fatto che il driver deve fornire all'API un'altra API di piu' basso livello (usata nell'implementazione della libreria) per accedere alla GPU.
Alla fin fine sappiamo come andrà a finire: saranno i produttori stessi di GPU che ne forniranno l'implementazione con i driver. Non è escluso che OpenCL, nel caso di nVidia, possa venir implementata come un layer di piu' alto livello su CUDA o potrebbe rilasciare un'estensione a CUDA che sia compatibile con le specifiche OpenCL 1.0
Lo scenario non è surreale, basti pensare al fatto che Cg (il linguaggio di shading di nVidia) è in grado di generare codice compatibile con l'OpenGL Shading Language (nel caso di OpenGL) o HLSL (nel caso di Direct3D). Alla fin fine quello che conta non è come lo implementano ma quando lo rilasciano.

Speriamo non facciano troppo i furbini io la mia NVIDIA 6150 integrata :sofico: la voglio poter sfruttare... poi magari andrà tutto a scatti, però voglio essere IO a decidere che non serve a una mazza non loro :D

Ciao,
fano

Bhè, quella la puoi usare come carta igienica già da adesso, senza troppo sperare. Parliamo di GPGPU computing, non di giocattolini accademici. Quella GPU non ha senso se non per muovere finestre in modalità compositing (ma neppure).

Dici che nemmeno 2 calcoli in croce può fare?
Possibile faccia così schifo?

Beh per lo uso che ne faccio ora va bene visto che in un HTPC la GPU non serve a una mazza :D

Fin ora non vedevo di buon occhio anche quelle cazzute per uso HTPC visto che per poter usare le accelerazioni su H264 e VC1 era necessario usare codec e programmi proprietari e poi spesso i file dovevano essere codificati in modo particolare (simile a come sono sui BluRay) se uscivi un minimo dalle specifiche l'accelerazione ti salutava :D e poi anche se volevi usare i filtri di ffdshow ti salutava :D
Per uso HTPC puro era meglio scheda GPU maffa e CPU ultrasonica: stavo meditando su almeno un bel dual ocre da 3 GHz ciascuno :D
Certo se sto OpenCL fosse supportato a dovere da ffdshow e c. beh allora una ATI della serie 4000 potrebbe divenire interessante anche per me... magari le versioni di gamma bassa come le 4500 senza ventola :D

Quindi bisogna attendere i driver e vedere cosa vorranno supportare sia ATI che NVIDIA?
Speriamo non decidano di rimandare tutto tra un anno con l'arrivo delle nuove schede e NON supportare le vecchie :doh:

Dici che nemmeno 2 calcoli in croce può fare?
Possibile faccia così schifo?

Beh per lo uso che ne faccio ora va bene visto che in un HTPC la GPU non serve a una mazza :D

Fin ora non vedevo di buon occhio anche quelle cazzute per uso HTPC visto che per poter usare le accelerazioni su H264 e VC1 era necessario usare codec e programmi proprietari e poi spesso i file dovevano essere codificati in modo particolare (simile a come sono sui BluRay) se uscivi un minimo dalle specifiche l'accelerazione ti salutava :D e poi anche se volevi usare i filtri di ffdshow ti salutava :D
Per uso HTPC puro era meglio scheda GPU maffa e CPU ultrasonica: stavo meditando su almeno un bel dual ocre da 3 GHz ciascuno :D
Certo se sto OpenCL fosse supportato a dovere da ffdshow e c. beh allora una ATI della serie 4000 potrebbe divenire interessante anche per me... magari le versioni di gamma bassa come le 4500 senza ventola :D

Quindi bisogna attendere i driver e vedere cosa vorranno supportare sia ATI che NVIDIA?
Speriamo non decidano di rimandare tutto tra un anno con l'arrivo delle nuove schede e NON supportare le vecchie :doh:

Media Player Classic Home Cinema usa la DXVA per decodificare attraverso la gpu la maggior parte degli h264.

Si appunto la "maggior parte" quelli che non li decodifica si appoggiano sulla CPU...
e poi è possibile che la decodifica fatta da ffdshow o CoreAVC (in software) sia migliore come qualità se poi uno ha abbastanza potenza per fare pure del resize, filtraggio ecc... beh il DVXA lo si cestina... e la GPU può esser pure una 6150 integrata :fagiano:

Analogamente se voglio decodificare per qualche motivo astruso divx o realmedia o chessò io un ipotetico Mpeg99 con la GPU come faccio?
Con OpenCL si potrebbero riscrivere ffdshow e CoreAVC per usare la GPU, in modalità "software": qualità migliore e flessibilità!
Inoltre potremmo pur far fare i filtri e resizing alla GPU (se ce la fa ancora) o farli fare alla CPU che a quel punto sarebbe altrimenti scarica :p

Si potrebbe anche ribaltare il mio ragionamento CPU scarsa (Atom o Sempreron) + GPU cazzuta con OpenCL = HTPC fico :D
Per esempio il nuovo EEEBox con GPU ATI discreta diverrebbe un ottimo mediacenter :D