OpenCL diventa ufficialmente uno standard

[Sajiuuk Kaar]

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

[CaFFeiNe]

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

[Mercuri0]

Originariamente inviato da MiKeLezZ

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

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

[Mercuri0]

Originariamente inviato da CaFFeiNe

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.

[peppepz]

Originariamente inviato da mjordan

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

Originariamente inviato da CaFFeiNe

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.

[CaFFeiNe]

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

[mjordan]

Originariamente inviato da peppepz

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.

[peppepz]

Originariamente inviato da CaFFeiNe

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.

[peppepz]

Originariamente inviato da mjordan

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.

[Gigio91]

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

[CaFFeiNe]

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

[fano]

A parte i gemiti di godimenti di cui ci avete voluto far partecipi 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 la voglio poter sfruttare... poi magari andrà tutto a scatti, però voglio essere IO a decidere che non serve a una mazza non loro

Ciao,
fano

[gabi.2437]

La tua 6150 mi sa che CUDA nemmeno sa che esiste

[mjordan]

Originariamente inviato da fano

A parte i gemiti di godimenti di cui ci avete voluto far partecipi 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 la voglio poter sfruttare... poi magari andrà tutto a scatti, però voglio essere IO a decidere che non serve a una mazza non loro

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

[fano]

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

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 e poi anche se volevi usare i filtri di ffdshow ti salutava
Per uso HTPC puro era meglio scheda GPU maffa e CPU ultrasonica: stavo meditando su almeno un bel dual ocre da 3 GHz ciascuno
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

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

[elevul]

Originariamente inviato da fano

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

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 e poi anche se volevi usare i filtri di ffdshow ti salutava
Per uso HTPC puro era meglio scheda GPU maffa e CPU ultrasonica: stavo meditando su almeno un bel dual ocre da 3 GHz ciascuno
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

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

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

[fano]

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

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

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