Jump to content
papafoxtrot

Elaborazioni Gp-gpu

Recommended Posts

Salve ragazzi!

Apro questo thread, che dedicheremo alla raccolta ed allo scambio di informazioni sulle elaborazioni General purpose GPU e allo sviluppo delle librerie e dei driver OpenCL.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

Ottimo, non vedo l'ora che questa tecnologia approdi anche nel nostro mondo!!!

Ma io dico, ma AMD sa solo lamentarsi? Prima hanno accusato nVidia di non puntare su OCL ma solo su una tecnologia proprietaria, poi loro con ATI-Stream hanno buttato solo soldi, ora se tutto va bene loro presentaranno OCL verso la fine dell'anno e per ora le beta sono soltanto private... Ad un certo punto si meritano di essere sempre secondi...

Domanda: compatibilità con applicazioni CUDA?


Edited by Simone82

Share this post


Link to post
Share on other sites

Che vuoi... li è questione di soldi da investirci e forza lavoro... si sa che sul lato software&driver nvidia spinge di più... Arriverà anche ATI!

Oggi sembra una buona notizia che nvidia sia intenzionata a rivolgersi a globalfoundries per le sue gpu: da una parte uol dire che globalfoundries sta sviluppando ottimi processi produttivi, merito dei dollari petroliferi degli arabi, dall'altra vuol dire che in futuro arà un sacco di soldi da spendere in R&D...

La scissione che a me non paiceva potrebbe rivelarsi per AMD una vera manna, nel senso che globalfoundries potrebbe portare in amd processi produttivi davvero all'avanguardia, affinati ed efficienti, da sempre il ramo più debole dell'azienda!

Share this post


Link to post
Share on other sites

Global Foundries non è quella che produce le cpu di AMD? Sembra che battano addirittura le fonderie della Intel, che prevede i 32nm il prossimo anno mentre GF si dice potrebbe addirittura stampare a 28nm... Staremo a vedere...

Con OCL nVidia apre al mondo Apple che monta le sue gpu soprattutto sui portatili: se fosse facile passare da CUDA ad OCL sarebbe davvero una ottima cosa, soprattutto per quelle tantissime applicazioni scientifiche che su CUDA oramai sono estremamente efficienti...

Share this post


Link to post
Share on other sites

Eh si... proprio loro :)

Evidentemente gli arabi ci spendono ed in un settore del genere l'importante è proprio quello, avere i soldi da metterci in R&D!

Comunque per Cuda/openCL: OpenCL è solo una libreria, ci vogliono poi dei motori in grado di sfruttarla; credo che physX possa essere uno di questi; se non vado errando funziona come con i motori grafici per i videogiochi, che al momento sfruttano quasi tutti directx.

Infine ci vuole un compilatore o comunque un linguaggio di programmazione. Tutto ciò può essere sviluppato a piacere da parecchie software house e/o università, ora che è disponibile una standard di oggetti (openCL) ed un driver in grado di sfruttarla (quello di nvidia per geforce/quadro/tesla) e quello che arrierà presto, speriamo, da parte di ATI, per radeon/firepro/fireGL/firestream.

CUDA potrebbe essere modificato per lavorare tramite openGL, ma a questo punto non è più l'unico linguaggio per programmare gpu nvidia... Ovvio che i codici già scrtitti in cuda non useranno mai le openCL ma dovranno essere eventualmente riscritti attraverso il nuovo codice ed il nuovo compilatore.

Un enorme passo queste librerie.

Share this post


Link to post
Share on other sites

Speriamo solo che questi nuovi linguaggi vengano digeriti il prima possibile e che al di là di Università e centri di ricerca (che possono permettersi programmatori che lavorano a tal fine perché tanto ne hanno all'interno) il tutto cominci a passare ad applicazioni extra scientifiche, come appunto il rendering e la CG. Non credo ci vorrà ancora molto, anche perché non si capisce altrimenti a cosa servirà la prossima generazione di schede video con tutta quella potenza hardware...


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

Anche io credo che il 2010 sarà l'anno decisivo almeno per mettere le fondamenta ai progetti futuri: poi nel 2013 mi faccio una doppia GTX595 in SLI abbinata ad un quad cpu da 32 threads l'uno... :hello:


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

ATI sta lavorando ad un progetto per rendere open source le librerie che gestiscono la fisica nei giochi: il tutto insieme a Bullet e Pixelux, per sviluppare le Open Physics Library, da affiancare alle OCL. Anche i motori fisici dei giochi (Havok per Intel e PhysX per nVidia) infatti sono in formato proprietario che non è possibile utilizzare ad di fuori del codice supportato dal chip dedicato: in futuro non dovrebbe essere più così, il che aiuterà anche gli sviluppatori di effetti per la computer grafica (pensiamo al particellare ad esempio) di poter accelerare in tempo reale i loro programmi con qualsiasi chip grafico in dotazione.

In futuro dunque sempre più la scelta di una gpu si baserà solo ed esclusivamente in base al prezzo ed alla sua potenza, e non già alla compatibilità con il software in commercio: anche questa è un'ottima notizia e vedremo se anche in questo caso nVidia si lancerà nella sfida tentando di rubare la scena ad ATI che pure come visto per prima ha avuto l'idea...


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

ATI supporterà engine Havok (che è stato acquistato da intel maledizione... maledizione perché è il più diffuso mtoore di simulazione per la fisica e da quando è stato acquistato non ha più avuto alcuno sviluppo). AMD utilizzerà di esso la parte riguardante i tessuti. Per il resto si appoggierà a pixelux, terzo motore per diffusione per quanto riguarda la simulazione fisica. Il secondo ovviamente è physX. Ovviamente al momento solo physX ha una versione che gira su GPU ed è il CUDA version. Pixelux ed Havok daranno luogo ad una libreria. L'engine dovrebbe essere quello integrato in directx 11... direct compute.

Ad ogni modo in campo GPU si avrà sempre una maggiore differenziazione fra software sviluppati per nvidia e software sviluppati per ATI. Questo perché le due architetture sono profondamente diverse e dnque richiedono approcci diversi in fasi di programmazione. Le CPU hanno architettura più standardizzata e dunque soffrono meno di queste differenze. Ad ogni modo è anche possibile distinguere fra software ottimizzati per intel (la maggior parte ovviamente) e software ottimizzati per AMD... in genere questi ultimi sono sviluppati o compilati autonomamente su piattaforma linux.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

scusate, sul mio MacPro ho installato Snow Leopard...basato interamente su OpenCL e Grand Central Dispatch....grandissime features, ma mi sembra di aver capito che se il software non le supporta....è come se non ci fossero...giusto?


Edited by MSolferino

Share this post


Link to post
Share on other sites

Le OCL sono utilizzate dal sistema operativo per velocizzare i suoi effetti grafici, che si appoggiano alla gpu, come sarà con Win 7. I software invece sono un'altra cosa: quelli devono essere scritti in quell'apposito ambiente, allo stato attuale nessuno è compatibile con OCL, quei pochi che utilizzano calcolo gp-gpu (come Adobe) si appoggiano ad altri ambienti (anche perché la CS4 è stata scritta quando OCL ancora non esisteva).

Inoltre vale dire che finché non ci saranno driver compatibili OCL esse non potranno cmq essere utilizzate: anche se con MacOS immagino che i driver li abbiano scritti loro...

Share this post


Link to post
Share on other sites

Arriva la certificazione di Khronos group per l'SDK AMD stream 2

AMD rilascia dunque l'SDK stream 2 completo di supporto openCL sia su CPU (già presente) che su GPU. Il pacchetto comprende ovviamente anche i driver della scheda video adatti.

Le schede video supportate sono tutte le schede delle famiglie radeon hd4000 e hd5000, nonché le firepro firestream che da esse derivano.

http://www.hwupgrade.it/news/software/open...m-20_30423.html

Al momento il supporto openCL è dunque presente su schede video nvidia, su schede video ATI, su CPU AMD ed eventualmente su CPU Intel, qualora fossero utilizzate assieme a schede video ATI: Il pacchetto messo a disposizione da ATI è infatti ovviamente compatibile anche con CPU intel, ma può essere instalalto solo in presenza di VGA (o cpu) AMD.

Manca ora un supporto dedicato da parte di intel, che consenta di usufruire pienamente delle librerie OpenCL su macchine equipaggiate con VGA nvidia e CPU Intel.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites
Il futuro reale non è neanche a mio avviso il gpu-computing (CUDA e ATI Stream per intenderci), ma appunto il cpu-gpu via OCL

A parte che uno sia proprietario e l'altro sia creato da un ente superpartes (anche se le prime specifiche sono state scritte da Apple) non c'è nessuna differenza tra CUDA e openCL.

E chi l'ha negato... Ma oltre a dire che affermare che non c'è nessuna differenza è palesemente un errore, mi sa che ti sfugge il problema centrale, ma fa niente: questo discorso è OT, a chi interessa lo si può continuare nell'apposita discussione della sezione hardware.

Scusa, mi era sfuggito questo tuo ultimo messaggio anche se non ne capisco il senso, forse è tardi.

L'affermazione "E chi l'ha negato..." si intende che non neghi che non c'è differenza tra i due, ma subito dopo dici che è palesemente sbagliato. Comunque hai negato l'uguaglianza quando hai detto che il futuro non è CUDA / ATI, ma OCL.

entrambe sono librerie di GPU computing, una di nVidia (e ci mette quello che gli pare a loro, compatibile solo con schede nVidia(per questione di test dicono loro)) l'altro di Khronos sviluppata a braccetto dai "big" della grafica. Se non sbaglio il modello evolutivo di openCL è simile a quello di openGL, quindi non ci vedo tutta questa grande differenza, CGFX docet.

Se vogliamo proprio parlare di futuro il punterei su Larrabee(anche se il primo demo è stato proprio deludente) e Fusion.

Ripeto, forse è tardi, sono stanco e con le triple negazioni ammetto di avere qualche difficoltà, ma quale sarebbe il problema centrale che mi è sfuggito?

Share this post


Link to post
Share on other sites

Il problema centrale è che CUDA è una libreria gpu proprietaria, OCL è una libreria cpu-gpu (ed altri processori) multipiattaforma... Fanno le stesse cose, ma a partire da punti di vista abbastanza diversi: quindi è sbagliato dire che sono perfettamente identiche, poiché se fosse così il codice sarebbe portabile, invece non è portabile, va in parte riscritto (se non erro, non sono un programmatore).

Larrabee è totalmente un'altra cosa, basandosi sulle specifiche x86 per l'esecuzione del codice: e sotto questo aspetto non ci vedo niente di sensazionale per il computing massivo di alto livello e ad alte prestazioni. Fusion è ancora un'altra cosa, ma a pare il mio sempre indirizzata all'ambito home/consumer...

Share this post


Link to post
Share on other sites

Ehm.. anche CUDA è una libreria CPU-GPU, se non trova l'acceleratore nVidia CUDA utilizza la CPU cercando di scalare su più core possibile.

E per il resto è proprio quello che ho detto io "A parte che una è proprietaria e l'altra no, per il resto sono uguali", se non ti piace uguali, metti molto simili. Francamente non amo i thread in cui due persone dicono la stessa.

Ho citato CGFX perché più o meno si sta sviluppando lo stesso scenario. Anche per gli shader infatti c'è uno standard aperto e multipiattaforma che è GLSL, ma GLSL è venuto fuori quando nVidia aveva già fatto il proprio linguaggio (CGFX) iperottimizzato per nVidia e gira così così su ATI.

GLSL si è evoluto con le varie release di openGL (che purtroppo si è evoluto solo in quest'ultimo anno) mentre CGFX è stato al passo con le varie release dei driver nVidia.

CGFX è stato fortunato, vuoi perché GLSL non era stato sviluppato proprio benissimo o perché è "multipiattaforma" (con 18 virgolette), ma fatto sta che è ancora li ed è molto più usato di GLSL.

Per adesso CUDA non è accelerato su ATI (soprattutto perché le GPU ATI per adesso non davano un interfaccia stabile per il GPU computing), se in futuro CUDA supporterà ATI (anche in maniera parziale) allora sopravviverà, altrimenti sarà delegato solo ad un ambito molto ristretto.

I problemi con le architettura attuali non sono tanto di potenza di calcolo ma di banda. Si devono mandare solo grandi quantità di dati tutti assieme per essere efficienti.

Si vocifera che la strategia generale per il futuro sia quella di accorpare GPU e CPU.

Anche se con visioni molto diverse è proprio quello che i progetti Fusion e Larrabee stanno facendo.

Larrabee non è soltanto tante CPU x86 una accanto all'altra, quelle ci sono già da tanto tempo ma sono distribuite su più macchine, questo assolutamente non risolve i problemi di banda che ci sono attualmente (e soprattutto un supercomputer da 256 CPU non ha prezzi che un utente normale si può permettere). Larrabee dovrebbe includere molti core x86 all'interno di un unico processore con un livello di cache comune, in pratica sarebbe un ingigantimento dell'architettura CELL di IBM.

Su Fusion ne so poco (molto poco, solo sentito dire), ma dovrebbe togliere il bus tra CPU e GPU e accorpare tutto in un unico chip. Anzi se avete informazioni più precise sarei lieto di capirne qualcosina di più.

Share this post


Link to post
Share on other sites

Non ho neanche letto tutto, perché vorrei farvi notare un errore di fondo molto grosso.

CUDA NON E' una libreria.

OpenCL è una libreria. OpenGL è una libreria.

PhysX è una libreria.

CUDA è un ambiente di sviluppo, come C++, come visual studio, Fortrnan o quant'altro.

OpenCL non è un ambiente di sviluppo.

Quindi a noi serve da un lato un ambiente di sviluppo, dall'altro la libreria.

L'ambiente di sviluppo ci serve per scivere il software e deve appoggiarsi ad una libreria di istruzioni, nelk qual caso openCL ad esempio.

L'utilizzatore dovrà avere hardware in grado di eseguire tali istruzioni e dunque in grado di supportare, nel nostro esempio, openCL.

Quindi se io voglio sviluppare un applicativo tramite openCL, lo standard che volevamo, mi serve comunque come minimo un compilatore, e questo può essere ad esempio CUDA. Posso usare cuda per scrivere il. software, compilarlo e poi distribuirlo come software che girerà su qualunque hardware in grado di supportare openCL.

In questo openCL si configura come una base di istruzioni che deve essere supportata da tutto l'installato hardware possibile e usata per scrivere software.

Poi che il software sia scritto con cuda, con c++, con fortran, ATI stream o quant'altro a noi non interessa, ognuno utilizzerà quello che preferisce, come avviene oggi per le CPU.

Le physX sono una cosa diversa ad esempio: se physX è supportato solo dalle GPU nvidia io non potrò mai scrivere un algoritmo che sfrutti tali librerie e farlo andare su una scheda ATI. Per questo PhysX è destinato all'abbandono, CUDA no. Cuda lo può usare chiunque senza rischiare che il suo software perda di generalità! Solo che il programmatore che vuole usarlo dovrà avere una scheda video nvidia...!

Infine su larrabee: ilmale io non credo che sarà la soluzione definitiva. Larrabee è una scheda acceleratrice che ha un unico grande vantaggio: usa le x86 e dunque può essere programmata da chiunque, mentre per programmare su scheda video bisogna imparare parecchio di nuovo e non tutti sono disposti.

Per il resto larrabee è un grosso compromesso fra un architettura più efficiente nelle elaborazioni parallele, come quella delle schede video, e un hardware che può essere supportato da qualunque software house senza dover far aggiornare tutti i suoi programmatori.

L'architettura x86 ha dimostrato più volte di non avere grandi efficienze, in particolare proprio in ambito GPU, dove servirebbe e sarebbe possibile amggiore ottimizzazione. Gli ARM ne sono una prova tangibile e molto terra terra... Processore quad core da 1GHz che consuma 80 milliwatt...

Fusion è un'altra cosa ancora, non c'entra nulla con Larrabee. Fusion è un progetto per integrare un chip video nella cpu, in modo da ridurre ingombri, consumi e calore. Non è un approccio molto diverso dallintegrazione della GPU nel chipset e infatti si tratterà di video di fascia bassa su cpu di fascia medio-bassa e solo dopo di fascia più alta. Come le cpu che farà uscire intel quest'inverno... dual core con dentro un chip video paragonabile a quello dell'intel g45... non è certo niente di potente...

Larrabbe poi non è una cpu multi core con cache comune... integra core simd. Certo al pari di cell, ma studiando bene si vede come fra cell e larrabee ci sia una certa differenza.

CPU e GPU non saranno mai unite; al massimo nella fascia bassa si possono integrare, per avere minor costo e consumo come ti dicevo, ma nella fascia alta c'è tutto l'interesse a tenerle distinte.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites
Non ho neanche letto tutto, perché vorrei farvi notare un errore di fondo molto grosso.

CUDA NON E' una libreria.

OpenCL è una libreria. OpenGL è una libreria.

:wallbash:

Ti prometto che un giorno la capirò anche io la differenza... :ph34r:

Share this post


Link to post
Share on other sites
CUDA NON E' una libreria.

OpenCL è una libreria. OpenGL è una libreria.

PhysX è una libreria.

CUDA è un ambiente di sviluppo, come C++, come visual studio, Fortrnan o quant'altro.

OpenCL non è un ambiente di sviluppo.

Qui c'è molta confusione, non so dove hai reperito queste informazioni, ma ne avessi azzeccata una. :lol:

Se è Hardware upgrade ti consiglio di cambiare spacciatore di informazioni. :P

openGL non è una libreria, se pensi che openGL sia opengl32.dll sei molto lontano. Se hai mai scritto un programma in openGL sotto windows noterai che all'inizio devi fare (o usare una libreria che ti fa) un sacco di wglGetProcAddress() per importare le chiamate di funzioni dal driver.. perché? Perché la libreria che link non è altro che un ponte tra l'implementazione openGL di windows e l'implementazione openGl vera e propria è nel driver, quella di openGL32.dll è un implementazione software fatta da Microsoft e ovviamente è lentissima.

Sotto linux/OSX devi linkare GL.s ma ugualmente devi usare glXGetProcAddress per ottenere le funzioni dal driver.

Poi sotto windows ogni cosa è una libreria pure il driver, ma di suo openGL non è altro che una specifica che il driver implementa.

Se openGL fosse una libreria dovresti avere una dll per ogni versione di opengL supportata.

Anche openCL è una specifica (tra cui comprende un linguaggio simil C), e quello che la implementa ti da una libreria (e gli header per usarla) per permetterti di accedere alle sue funzionalità. La libreria è composta da un interfaccia che ti permette di caricare dati su un buffer, permetterti di chiamare il compilatore, eseguire il programma (kernel*) openCL compilato e riprendere dati e un compilatore che prende il tuo kernel e lo lo traduce in codice eseguibile dipendente dalla piattaforma di destinazione. Il compilatore viene chiamato OGNI VOLTA che esegui il programma perché il programma che generi non sa su cosa dovrà essere eseguito il kernel.

CUDA bada caso funziona nella stessa identica maniera (poi uno dice che sono simili). Non c'è nessun ambiente di sviluppo chiamato CUDA, quello che chiami ambiente di sviluppo è il Cuda Toolkit che comprende un compilatore C, un linker, un debugger e le librerie di cui sopra (che si trovano anche nell'SDK). Infatti io per fare programmi (va be' chiamiamole schifezze di test, che proprio programmi non sono) con CUDA uso Visual studio.

Anche le SDK per Cuda ti danno anche loro la loro bella libreria per interfacciarti con il compilatore.

Cambieranno i nomi delle funzioni, ma il modo di operare è il solito.

C++ non è un ambiente di sviluppo, nemmeno Fortran, sono linguaggi, nient'altro che un insieme di regole semantiche. Tant'è che se scrivi del codice C++ su un foglio di carta rimane C++.

Quello che fa il compilatore, linker, assembler e IDE ti fa l'ambiente di sviluppo.

Visual studio è un ambiente di sviluppo, il pacchetto GNU Gpp, G++ ecc.. è un ambiente di sviluppo (senza IDE), QtCreator è un ambiente di sviluppo, KDevelop è un ambiente di sviluppo.

PhysX è una libreria e openCL non è un ambiente di sviluppo. Su questo non posso far altro che concordare. :)

Mi sono fermato alle prime 5 righe, se dovevo commentare tutto il resto del post facevo notte.

Ora spiegatemi una cosa, è da giugno che scrivete e non sapete nemmeno di cosa state parlando?

*per chiarire in questo caso kernel è il programma openCL, non ha niente a vedere con il cuore del sistema operativo.

Share this post


Link to post
Share on other sites

Non ho capito bene tutto il cancan che hai fatto.

Ammetto di avere una conoscenza solo teorica della cpsa, dato che come dicevo anche in altre discussioni non ho mai scritto niente in cuda.

Però mi sembra evidente, anche dal tuo discorso, che c'è una differenza fondamentale fra CUDA e openCL! OpenCL avrà anche un compilatore simil-C a corredo, ma è principalmente una libreria di istruzioni

Lo dice già il nome... OpenCL... open Computing library...

E le openGL... open ... graphic library.

Vorresti dirmi che non sono librerie di istruzioni?

CUDA hai ragione... contiene anche librerie. E contiene un ambiente di sviluppo, magari non completo: c'è un compilatore, un debugger...

Fortran e C++ di per se sono dei linguaggi, con appositi compilatori; se prendi un devC++, o simili, hai tutto l'ambiente... Certo, semplice, ma fai uso di un ambiente e di un compilatore....

In questo senso sono diversi da una libreria di istruzioni!

Mi sembra evidente ciò che volevo far notare...

CUDA non è destinato a sparire perché chiuso... chiunque può usarne il compilatore con librerie openCL o quant'altro!

All'utilizzatore basterà dunque avere hardware compatibile con le openCL per far girare il software! Non hardware compatibile con cuda, hardware compatibile con openCL.

Allo stesso modo puoi usare le librerie physX, ma ci vorrà hardware compatibile con PhysX per far girare il software, e se hai una scheda non nvidia ti attacchi.

Io credo che da qui a qualche anno ci saranno compilatori di diverso tipo in grado di compilare per scheda video e di usare le librerie a disposizione... In quel caso a nessuno interesserà con che software è stato scritto e compilato il programma...

E cuda sarà uno dei compilatori disponibili per scrivere software...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...