Link alla notizia: http://www.hwupgrade.it/news/skvideo/ati-stream-gpu-computing-secondo-amd_27286.html

Dal 10 Dicembre ATI implementerà il supporto Stream nei propri driver video: GPU Computing anche per le schede Radeon HD 4000

Click sul link per visualizzare la notizia.

Ma il supporto agli ATI Stream è fattibile anche con la passata generazione 38x0.. allora perché non viene implementata?
Come al solito bisogna sperare in un hack dei driver da parte di qualcuno :rolleyes:

Ma il supporto agli ATI Stream è fattibile anche con la passata generazione 38x0.. allora perché non viene implementata?
Come al solito bisogna sperare in un hack dei driver da parte di qualcuno :rolleyes:

ma il titolo infatti dice anche la serie 4000... però poi nella notizia si parla solo di questa :confused:

c'è già un sito ufficiale (che non sia la paginetta nel sito Ati) con un po' di esempi, applicazioni ecc.? oppure per ora presentano i catalist nuovi e DA ADESSO gli sviluppatori possono sbizzarrirsi con le nuove funzioni?

Speró che lo rendino accessibile anche per la serie HD2xxx, anche essa dotata di Stream-Processors.

"Speró che lo rendino accessibile"

:mbe:

:stordita:

:fagiano:

i congiuntivi sono tuoi amici... usali bene :D

di avivo converter si era parlato già ai tempi della serie x1x00, quindi perchè adesso questo "limite" per la sola generazione HD4?

di avivo converter si era parlato già ai tempi della serie x1x00, quindi perchè adesso questo "limite" per la sola generazione HD4?

perchè così te ne compri una nuova? a pensar male si fa peccato, ma in genere ci si azzecca...

Io sono per gli standard aperti..per cui se questo ATI Stream abbraccierà l'OpenCL (e sembra proprio che sarà così) allora tanto di guadagnato per tutti.
Così come simpatizzo per OpenAL e OpenGL.
Nulla di personale contro CUDA per le GPU Nvidia..così come non avevo nulla contro le Glide delle 3dfx..in assenza di standard aperti è plausibile una situazione di standard proprietari e blindati.
Un discorso a parte merita tutto ciò che sforna Microsoft (DirectX in primis)..ma lì è un universo parallelo che ha creato BigM.

c'è già un sito ufficiale (che non sia la paginetta nel sito Ati) con un po' di esempi, applicazioni ecc.? oppure per ora presentano i catalist nuovi e DA ADESSO gli sviluppatori possono sbizzarrirsi con le nuove funzioni?
http://ati.amd.com/technology/streamcomputing/

di avivo converter si era parlato già ai tempi della serie x1x00, quindi perchè adesso questo "limite" per la sola generazione HD4?

Quell'Avivo Converter non aveva nulla a che spartire con questo ;)
Si basava sul lavoro della cpu, e la scelta di lasciarlo solo per la serie X1x00 fu prettamente commerciale.

Ati Stream supporta pienamente OpenCL che sta per diventare LO STANDARD per il GPGPU computing.

Anche se "in ritardo" questa compatibilità è come mettere il peperoncino nel culo a un corridore, sorpassa tutti :D, CUDA compreso.

PS: Cuda avrà anche un anno, ma non è che abbiano fatto granchè, anzi...solo soluzione alla portata di nessuno, per costi e schede supportate.

Sarebbe alquanto autolesionista da parte di AMD tagliare fuori le schede 38XX. Sul sito ufficiale comunque si dice:

"In December 2008, AMD is scheduled to release an update to its ATI Catalyst™ drivers, software version 8.12, that instantly unlocks new ATI Stream acceleration capabilities already built into millions of ATI Radeon™ graphics cards."

Vi pare possibile che quel millions si riferisca solo alle 48XX?
Speriamo poi che queste librerie consentano l'uso delle schede video con progetti tipo BOINC. Magari ne esce un altro aiutino per la scienza.. :D

Ottima cosa questa, speriamo che le prime soluzioni cad/cam che supportino l'accellerazione tramite gpu arrivino in meno di un anno!

Però è bizzarra la tecnologia, perchè da un lato si cerca di spegnere la gpu per risparimiare sui consumi, mentre dall'altro si spinge per impiegare sempre più spesso la gpu per calcoli extra grafica.

Magari si giungerà ad una tecnologia che spegne la gpu quando non serve, permettendo quindi l'uso di una minigpu all'interno della cpu, per poi attivare la gpu o il multigpu quando si gioca o quando serve potenza extra per il calcolo.

Figata! :D

Allora, per prima cosa non si capisce se sto nuovo super avivo converter è solo per le 4xxx o anche le altre che supportano CAL (dalle 2xxx in poi)

Poi

la disponibilità di CUDA, in differenti versioni, da più di 1 anno e mezzo ha permesso ad alcuni progetti di calcolo parallelo di sperimentare l'adozione delle GPU accanto ai processori per alcune elaborazioni specifiche.

Come no, peccato che su Folding@Home le ATI vennero supportate prima delle nvidia...sia la serie 1xxx (tramite directx, quindi possiamo anche non contarle) che tutte le altre, e stavolta tramite CAL, il corrispettivo ATI di CUDA...

Poi, brava ATI a spingere su OpenCL, invece che su roba proprietaria

Poi, così come c'è CUDA da un pò, idem c'è CAL, quindi volendo si poteva programmare su CAL già da tempo

Molto interessante. Sono curioso di vedere quali saranno i programmi a sfruttare questa tecnologia. :)

La conseguenza diretta di questo è una notevole diminuzione dei tempi di elaborazione rispetto ad un approccio che veda l'utilizzo di un processore.

Anche la GPU è un processore, ma il senso si è capito lo stesso (spero).

Ati continua ad offrire software GRATIS x tutti, adoro questa filosofia :) Nvidia chiede 30€ x Badaboom come faceva all'epoca con il PureVideo, per poi cambiare rotta , mi dispiace x quelli che hanno pagato :asd:

con poco + di cento euri si possono acquistare le 48xx che vanno il doppio rispetto alle 38xx quindi fatelo sto sforzo e upgradade :) oppure potete prendere le 46xx con cifre ridicole x quello che offrono ed avete schede cmq migliori rispetto alle 2xxx e 3xxx

Non potete sempre sperare che l'hardware resti fermo e di coseguenza il software, Berlusca ha detto che dobbiamo spendere e quindi spendete :asd:

Ma il supporto agli ATI Stream è fattibile anche con la passata generazione 38x0.. allora perché non viene implementata?
Come al solito bisogna sperare in un hack dei driver da parte di qualcuno :rolleyes:

ma il titolo infatti dice anche la serie 4000... però poi nella notizia si parla solo di questa :confused:

Speró che lo rendino accessibile anche per la serie HD2xxx, anche essa dotata di Stream-Processors.

"Speró che lo rendino accessibile"

:mbe:

:stordita:

:fagiano:

i congiuntivi sono tuoi amici... usali bene :D

perchè così te ne compri una nuova? a pensar male si fa peccato, ma in genere ci si azzecca...

congiuntivi a parte :D , si potrà utilizzare con tutte le gpu ati a partire da R600 e derivati.

Io sono per gli standard aperti..per cui se questo ATI Stream abbraccierà l'OpenCL (e sembra proprio che sarà così) allora tanto di guadagnato per tutti.
Così come simpatizzo per OpenAL e OpenGL.
Nulla di personale contro CUDA per le GPU Nvidia..così come non avevo nulla contro le Glide delle 3dfx..in assenza di standard aperti è plausibile una situazione di standard proprietari e blindati.
Un discorso a parte merita tutto ciò che sforna Microsoft (DirectX in primis)..ma lì è un universo parallelo che ha creato BigM.
Ati Stream supporta pienamente OpenCL che sta per diventare LO STANDARD per il GPGPU computing.

Anche se "in ritardo" questa compatibilità è come mettere il peperoncino nel culo a un corridore, sorpassa tutti :D, CUDA compreso.

PS: Cuda avrà anche un anno, ma non è che abbiano fatto granchè, anzi...solo soluzione alla portata di nessuno, per costi e schede supportate.No.

AT* STRE*M, al momento, è concettualmente simile a NVID*A C*DA.

Così come C*DA, anche STR*AM è "chiuso" (fra virgolette).

Eventualmente lo faranno diventare (ORA NON LO E') compatibile OpenCL.

Come eventualmente NVID*A lo farà diventare il suo C*DA (questa affermazione si rivelerà profetica), datosi sono sue tutte le VGA dei portatili *PPLE, e quest'ultima è quella che maggiormente spinge sullo standard OpenCL.

Nvidia chiede 30€ x Badaboom come faceva all'epoca con il PureVideoBadaboom è creato dalla compagnia Elemental Technologies.
NVID*A poco c'entra, è semplicemente la fornitrice del suo strumento lavorativo (C*DA). Gratis.

p.s. Ph*sX è gratis.

Come no, peccato che su Folding@Home le ATI vennero supportate prima delle nvidia...sia la serie 1xxx (tramite directx, quindi possiamo anche non contarle) che tutte le altre, e stavolta tramite CAL, il corrispettivo ATI di CUDA...Peccato che le VGA NVID*A nel Folding@Home vadano circa il doppio rispetto le corrispettive concorrenti AT*.

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.

:rolleyes:

la disponibilità di CUDA, in differenti versioni, da più di 1 anno e mezzo ha permesso ad alcuni progetti di calcolo parallelo di sperimentare l'adozione delle GPU accanto ai processori per alcune elaborazioni specifiche.

Come no, peccato che su Folding@Home le ATI vennero supportate prima delle nvidia...sia la serie 1xxx (tramite directx, quindi possiamo anche non contarle) che tutte le altre, e stavolta tramite CAL, il corrispettivo ATI di CUDA...

Poi, brava ATI a spingere su OpenCL, invece che su roba proprietaria

Poi, così come c'è CUDA da un pò, idem c'è CAL, quindi volendo si poteva programmare su CAL già da tempo

1)Come no, peccato che con il vecchio CAL, prima che seguisse la strada di CUDA, dovevi ricompilare Folding@Home o qualsiasi altra applicazione ogni cambio di generazione.

2)CUDA utilizza il C, C++ e Fortran, non mi sembra proprio "roba proprietaria", tuttalpiù sono standard.

Ati Stream supporta pienamente OpenCL che sta per diventare LO STANDARD per il GPGPU computing.

Anche se "in ritardo" questa compatibilità è come mettere il peperoncino nel culo a un corridore, sorpassa tutti :D, CUDA compreso.

PS: Cuda avrà anche un anno, ma non è che abbiano fatto granchè, anzi...solo soluzione alla portata di nessuno, per costi e schede supportate.
CUDA toolkit è royalty free, per cui il suo utilizzo è completamente gratuito, l'unico costo sono le schede, che comunque permettono di risparmiare sia per costo che per consumo rispetto all'uso di CPU, e il costo per la migrazione che utilizzando il C disponibile attraverso CUDA sarebbe comunque minore rispetto all'uso di OpenCL che è comunque derivato dal C.

Ah, l'attuale presidente del Khronos 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 NVIDIA 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.

:rolleyes:
Hai completamente ragione.
Ma credo che molti parlino senza cognizione di causa e abbino solo una leggera simpatia verso il "rosso".

1)Come no, peccato che con il vecchio CAL, prima che seguisse la strada di CUDA, dovevi ricompilare Folding@Home o qualsiasi altra applicazione ogni cambio di generazione.



se parli di generazioni di vga è più che normale: CAL gira su R5x0 e su R600 e derivati. Le due architetture sono completamente differenti. Ritieni possibile far girare la stessa versione su entrambe.
CUDA gira solo su chip a shader unificati e non su G7x (che è l'equivalente di R5x0 per nVIDIA). La notazione fp64 è utilizzabile su tutti i chip ATi a partire da R600 e solo su GT200 per nVIDIA.



2)CUDA utilizza il C, C++ e Fortran, non mi sembra proprio "roba proprietaria", tuttalpiù sono standard.


anche le dx sono scritte in C. Sono API standard e sono proprietarie ma sono anche free. C'è un po' di confusione tra i termini: standard, proprietario e open. L'utilizzo di C o C++ per scrivere un tool non ne fa automaticamente uno standard e neppure un SW open. CUDA non rappresenta uno standard anche se è scritto in C ed è proprietario.




CUDA toolkit è royalty free, per cui il suo utilizzo è completamente gratuito, l'unico costo sono le schede, che comunque permettono di risparmiare sia per costo che per consumo rispetto all'uso di CPU, e il costo per la migrazione che utilizzando il C disponibile attraverso CUDA sarebbe comunque minore rispetto all'uso di OpenCL che è comunque derivato dal C.


di questo mi sfugge il senso

se parli di generazioni di vga è più che normale: CAL gira su R5x0 e su R600 e derivati. Le due architetture sono completamente differenti. Ritieni possibile far girare la stessa versione su entrambe.
CUDA gira solo su chip a shader unificati e non su G7x (che è l'equivalente di R5x0 per nVIDIA). La notazione fp64 è utilizzabile su tutti i chip ATi a partire da R600 e solo su GT200 per nVIDIA.

Ciò che ritengo è che sarà possibile far girare un applicazione creata tramite CUDA su tutte le architetture che la supportano, vale a dire anche il successore di GT200 e quello dopo ancora e volendo anche r770 se ipoteticamente AMD decidesse di supportare CUDA, questo senza la necessita di alcuna modifica all'applicazione.
Naturalmente se un programma svolge calcoli in fp64 con la GPU non potrà girare su hardware che non lo prevedono.

anche le dx sono scritte in C. Sono API standard e sono proprietarie ma sono anche free. C'è un po' di confusione tra i termini: standard, proprietario e open. L'utilizzo di C o C++ per scrivere un tool non ne fa automaticamente uno standard e neppure un SW open. CUDA non rappresenta uno standard anche se è scritto in C ed è proprietario.
Ed è proprio quello che intendevo dire.:)


di questo mi sfugge il senso
Il succo del discorso è:

L'utilizzo delle GPU in per computazioni non prettamente grafiche in un ambito adatto, come simulazioni fisiche, finanziarie, sintesi di proteine, analisi geosismiche, risonanze magnetiche, tomografie, ecc., porta importanti benefici a livello di tempo di esecuzione, consumo energetico e costo delle macchine.
Il vantaggio di CUDA rispetto a soluzioni concorrenti è di fornire un ambiente di sviluppo familiare al programmatore come il C standard(con qualche piccola modifica), o il Fortran, molto usato in applicazioni mediche.
In questo modo uno sviluppatore può cominciare a scrivere quasi da subito e in poco tempo cominciare ad ottimizzare il codice o ad elaborare nuove tecniche non possibili con l'uso di CPU.
In quest'ottica la migrazione a CUDA non è così dispendiosa.


Se leghi questo discorso al post a cui rispondeva forse ne comprenderai il significato;)

2)CUDA utilizza il C, C++ e Fortran, non mi sembra proprio "roba proprietaria", tuttalpiù sono standard.






anche le dx sono scritte in C. Sono API standard e sono proprietarie ma sono anche free. C'è un po' di confusione tra i termini: standard, proprietario e open. L'utilizzo di C o C++ per scrivere un tool non ne fa automaticamente uno standard e neppure un SW open. CUDA non rappresenta uno standard anche se è scritto in C ed è proprietario.





Ed è proprio quello che intendevo dire.:)





avrò capito male io, ma qui mi sembra che dicevi esattamente il contrario, ovvero che cuda poteva essere considerato alla stregua dui uno standard, essendo in C. CUDA non è uno standard né open né proprietario, quindi non può essere considerato né alla stregua delle OpenGL (o delle OpenCL, visto che siamo in tema di gpgpu), né delle DX.

Ciò che ritengo è che sarà possibile far girare un applicazione creata tramite CUDA su tutte le architetture che la supportano, vale a dire anche il successore di GT200 e quello dopo ancora e volendo anche r770 se ipoteticamente AMD decidesse di supportare CUDA, questo senza la necessita di alcuna modifica all'applicazione.
Naturalmente se un programma svolge calcoli in fp64 con la GPU non potrà girare su hardware che non lo prevedono.



hai affermato che non era possibile far girare la stessa versione di CAL su differenti GPU ATi, come se, invece, con CUDA e le gpu nVIDIA fosse possibile. La realtà è che, cambiando le architetture e passando dagli shader dedicati a quelli unificati, le versioni precedenti di CAL non potevano essere riadattate. Con CUDA il problema non si pone perchè non esisteva prima della serie a shader unificati e non esiste per archiettture nVIDIA a shader dedicati (quindi niente CUDA per G7x e precedenti, mentre esiste una verisone dii CAL per R5x0, ovviamente diversa da quella epr R600 e derivati). Per quanto riguarda le future compatibilità, è ovvio che se l'architettura dei chip manterrà come base quella di GT200 (o G8x), CUDA sarà compatibile, come lo sarà CAL per le gpu ATi qualora dovessero basarsi sull'architettura di RV770 (o anche RV670 o R600).
In quanto al resto, CUDA, con le opportune ottimizzazioni, è sicuramente compatibile con le gpu ATi, ma anche stream è compatibile con quelle nVIDIA (sempre con le opportune ottimizzazioni :D).




Il succo del discorso è:

L'utilizzo delle GPU in per computazioni non prettamente grafiche in un ambito adatto, come simulazioni fisiche, finanziarie, sintesi di proteine, analisi geosismiche, risonanze magnetiche, tomografie, ecc., porta importanti benefici a livello di tempo di esecuzione, consumo energetico e costo delle macchine.
Il vantaggio di CUDA rispetto a soluzioni concorrenti è di fornire un ambiente di sviluppo familiare al programmatore come il C standard(con qualche piccola modifica), o il Fortran, molto usato in applicazioni mediche.
In questo modo uno sviluppatore può cominciare a scrivere quasi da subito e in poco tempo cominciare ad ottimizzare il codice o ad elaborare nuove tecniche non possibili con l'uso di CPU.
In quest'ottica la migrazione a CUDA non è così dispendiosa.


Se leghi questo discorso al post a cui rispondeva forse ne comprenderai il significato;)

continui a parlare di CUDA come se fosse l'unica a fare uso di C. Anchebrooks o brooks+ (che fa parte di stream) è C; anche OpenCL è C. Quindi qual è il vantaggio di usare CUDA rispetto a questi ultimi?

avrò capito male io, ma qui mi sembra che dicevi esattamente il contrario, ovvero che cuda poteva essere considerato alla stregua dui uno standard, essendo in C. CUDA non è uno standard né open né proprietario, quindi non può essere considerato né alla stregua delle OpenGL (o delle OpenCL, visto che siamo in tema di gpgpu), né delle DX.

Io mi riferivo a C, C++, Fortran, e rispondevo a chi diceva, "Stream si basa su standard aperti mentre CUDA si basa su roba proprietaria".
Non credo affatto che CUDA sia uno standard.

hai affermato che non era possibile far girare la stessa versione di CAL su differenti GPU ATi, come se, invece, con CUDA e le gpu nVIDIA fosse possibile. La realtà è che, cambiando le architetture e passando dagli shader dedicati a quelli unificati, le versioni precedenti di CAL non potevano essere riadattate. Con CUDA il problema non si pone perchè non esisteva prima della serie a shader unificati e non esiste per archiettture nVIDIA a shader dedicati (quindi niente CUDA per G7x e precedenti, mentre esiste una verisone dii CAL per R5x0, ovviamente diversa da quella epr R600 e derivati). Per quanto riguarda le future compatibilità, è ovvio che se l'architettura dei chip manterrà come base quella di GT200 (o G8x), CUDA sarà compatibile, come lo sarà CAL per le gpu ATi qualora dovessero basarsi sull'architettura di RV770 (o anche RV670 o R600).
In quanto al resto, CUDA, con le opportune ottimizzazioni, è sicuramente compatibile con le gpu ATi, ma anche stream è compatibile con quelle nVIDIA (sempre con le opportune ottimizzazioni :D).
R5x0 non aveva shader unificati?
Comunque, io intendevo dire è che all'inizio con CtM era possibile programmare solo in assembly e non era previsto un layer software per poter utilizzare architetture diverse, ora sia con Stream che con CUDA sarà possibile utilizzare la medesima applicazione anche con l'arrivo di nuove architetture.


continui9 a parlare di CUDA come se fosse l'unica a fare uso di C. Anche brooks (che fa parte di stream) è C; anche OpenCL è C. Quindi qual è il vantaggio di usare CUDA rispetto a questi ultimi?

Di usare il C standard con qualche estensione.
Poi è importante che vengano supportati altri linguaggi, come Brook (Ian Buck, uno dei padri di Brook è director GPU Computing SW in NVIDIA) o Open CL che è attualmente sviluppato anche da NVIDIA.

Io mi riferivo a C, C++, Fortran, e rispondevo a chi diceva, "Stream si basa su standard aperti mentre CUDA si basa su roba proprietaria".
Non credo affatto che CUDA sia uno standard.



ok :)




R5x0 non aveva shader unificati?



R500 si; R5x0 indica la serie per pc (derivata da R520 ed R580) che non ha shader unificati.



Comunque, io intendevo dire è che all'inizio con CtM era possibile programmare solo in assembly e non era previsto un layer software per poter utilizzare architetture diverse, ora sia con Stream che con CUDA sarà possibile utilizzare la medesima applicazione anche con l'arrivo di nuove architetture.



vero; CTM era solo in assembly e presupponeva una buona conoscenza dell'architettura della gpu. Idem per CAL; quindi si è adottata un'interfaccia utilizzando un linguaggio di programmazione ad alto livello (prima brooks e poi brooks+). Stream, di fatto, è CAL più un'interfaccia di alto livello.



Di usare il C standard con qualche estensione.
Poi è importante che vengano supportati altri linguaggi, come Brook (Ian Buck, uno dei padri di Brook è director GPU Computing SW in NVIDIA) o Open CL che è attualmente sviluppato anche da NVIDIA.

che è quello che permettono di fare anche gli altri tool per il gpgpu