ATI Stream: GPU Computing secondo AMD

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.

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.


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.


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

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.



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.



di questo mi sfugge il senso

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.


Ed è proprio quello che intendevo dire.



Il succo del discorso è:
[LIST]
[*]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.
[/LIST]

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

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.



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



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?

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.


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.




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.

ok



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



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.



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