Heterogeneous Queuing: l'approccio di AMD alla programmazione di CPU e GPU

[digieffe]

Originariamente inviato da XFer

@digieffe:

Sì, ma vedi che si appoggia sempre su OpenCL e C++ AMP?

Hanno bellamente ignorato SimpleCL, un piccolo, intelligente uovo di Colombo che richiedeva solo un po' di finanziamento e supporto tecnico, e anche Graphite.

dove dovrei vederlo?
nella slide che ho postato? se si, non indica che si appoggia ma che questi "sistemi" sono compatibili.

non conosco simplecl e graphite.


@tutti: perché non continuiamo la discussione dopo aver visto le slide?

[PaulGuru]

Prima volevi un risposta e poi mi ignori ?

[XFer]

@digieffe
Sì dalle slide, in particolare la n.7 del gruppo in basso a destra.

Cito, non integralmente:

"HSA Parallel Execution Model:

Programmer supplies a kernel that is run on each work-item
Programmer specifies grid dimensions"

E' il classico approccio dei linguaggi paralleli, come OpenCL, C++ AMP, CUDA: scrivi un kernel per il parallel device in un linguaggio con certi costrutti (tipi di dato, definizione di grid etc.) e poi lo dai in pasto ad un compilatore specifico per la ISA in gioco.
Non per nulla, si fa esplicito riferimento, tra gli ambienti compilati (JVM a parte, insomma), a OpenCL e C++ AMP: per "rassicurare" in qualche modo gli sviluppatori che già li usano.
Tempo fa, il gruppo PGI (Portland) ha fatto una cosa molto simile, con precompilatore in vendita a circa 500 euro (l'ho anche provato).

Ma è un approccio che non mi trova d'accordo, lock-in, niente trasversalità (no Intel, no NVidia, no ARM almeno con certe IP integrate) etc. :-(

[digieffe]

Originariamente inviato da PaulGuru

Nell'altro thread hai detto esplicitamente senza troppi giri di parole che APU con HSA risponderà ad Intel lasciando intendere qualcosa di presumibilmente miracoloso.

Dicendo anche che avrebbe risolto i suoi limiti in gaming con questo HSA dicendo che avrebbe usato l'IGP interna per svolgere buona parte del lavoro della cpu e così invece abbiamo visto che non solo come avevo intuito non sarebbe stato possibile ma non c'è nemmeno un minimo di influenza a riguardo.

Il mio intervento non lo reputo fazioso, per me sono normali scambi di opinioni aldilà di un atteggiamento che reputo eccessivamente permaloso nei confronto degli utenti che han AMD, in pratica nessuno può criticare i prodotti AMD se non con i guanti di velluto e discorsi da galateo e a volte nemmeno quelli sono sufficienti.

Quando si usa l'espressione "CASCA L'ASINO" non si intende dare dell'asino a un altra persona, è un espressione che con cui si intende dire che viene smacherato l'inghippo o un punto debole di un discorso.
Ed è un espressione abbastanza usata. -> LEGGI

Intel? non mi pare di aver nominato intel negli ultimi giorni, tutt'alpiù nvidia.

Risolto i suoi limiti in ambito gamig?
Utilizzando l'ipg per svolgere buona parte del lavoro della cpu? (forse ho detto qualcosa di simile ma non questo)

in ogni caso, cortesemente mi riporteresti il mio post evidenziando le parti in questione, così ne chiariamo pacificamente?

in ogni caso non sono un fanboy di amd e nei thread amd sono molto critico.

[digieffe]

Originariamente inviato da XFer

@digieffe
Sì, il lock-in tra l'altro avviene anche, in certi casi, con pratiche non proprio "limpide", ma questo è un altro discorso.
Comunque specie con l'avvento e la pervasività di dispositivi mobile ed embedded, ci vorrebbe che i produttori capissero l'importanza di strumenti open source e trasversali. Per lo sviluppo inteso anche come debug ed emulazione (chiunque abbia provato a risolvere problemi in un kernel OpenCL, magari senza la possibilità di installare tutti i possibili dispositivi su cui dovrà girare, sa cosa intendo).

Con i mezzi che hanno, vorrei tanto che si mettessero d'accordo su una singola estensione al linguaggio (se proprio serve) e la implementassero tutti, fornendo in open source gli SDK necessari e supportando i team che lavorano a LLVM e soprattutto GCC (molto più diffuso e più facile da portare su nuove architetture).

purtroppo ti capisco, purtroppo nel migliore dei casi non si mettono d'accordo nel peggiore cercano di fare "divide et impera".

[digieffe]

Originariamente inviato da XFer

@bivvoz

HSAIL vuole kernel OpenCL e chiamate host OpenCL (o C++ AMP).
Dopodiché capisce se è meglio indirizzare a device_CPU o device_GPU, eventualmente anche "massaggiando" un po'.
Ma non è in grado di riconoscere automaticamente se, all'interno di un comune algoritmo ANSI C (pensiamo alla montagna di letteratura e codice per BLAS o CV, fluidodinamica, simulazione strutturale ad elementi finiti, pattern matching etc.), ci sono parti vettorializzabili, CPU-parallelizzabili, GPU-parallelizzabili.

Insomma è un altro preprocessor che si mette tra OpenCL (che è un mezzo incubo di per sé) e il binario.
Sforzo apprezzabile in sé, ma poco pratico per lo sviluppatore finale, specie per piccoli team. Anche perché, appunto, darebbe benefici solo per architetture HSA, che sono e saranno solo una percentuale del totale.

vorrei conoscere la tua opinione su hsa bolt, è nelle slide.

[XFer]

@PaulGuru:

Premetto che non sono un gran simpatizzante AMD negli ultimi tempi, anche se all'epoca degli Athlon mi avevano conquistato il cuore. :-)

Però è vero che un approccio di questo tipo (HSA con hUMA) può risolvere tanti colli di bottiglia, anche in ambito gaming. Sulla carta almeno!
Finché devi passare per una chiamata a sistema per far iniziare a lavorare una GPU, hai un ritardo orrendo. In certi casi il ritardo per la partenza del kernel è tale, da mangiarsi quasi interamente il guadagno in termini di velocità di elaborazione. Bypassare la chiamata a sistema (HSA) renderebbe la GPU utile anche per "piccoli" lavori che normalmente sarebbero inefficienti per il ritardo della partenza del kernel.
Inoltre le GPU lavorano male quando c'è branching. O il programmatore se ne fa carico ( :-( ) o la GPU dovrebbe poter chiamare la CPU quando ci sono parti del codice che non sono adatte a lei. Oggi non lo può fare (neanche nelle architetture integrate Intel, che pure sono quasi-hUMA), con HSA sì.

In più oggi devi spostare continuamente i dati tra memoria CPU e memoria GPU; è un'operazione lenta, sia perché anche in quel caso devi passare per una chiamata a sistema, sia perché il passaggio tramite PCIExpress penalizza le prestazioni rispetto all'accesso diretto a memoria.
Con hUMA risolvi il problema.

Che AMD abbia visto bene si capisce anche dal fatto che NVidia sta inserendo CPU ARM nelle sue prossime architetture GPU, per evitare questo ping-pong attraverso OS e PCI-Express tra CPU e GPU.

Poi sono d'accordo con te che tra il dire e il fare...!

[digieffe]

Originariamente inviato da PaulGuru

Prima volevi un risposta e poi mi ignori ?

ti ho risposto, è che ho un certo lag per via del multitasking al quale sono sottoposto.

@tutti: mi scuso con il ritardo con il quale sono costretto a rispondere, questo out of syncro può rendere i miei interventi meno logico

[XFer]

Ragazzi bella chiaccherata, un grazie a tutti e specialmente a digieffe, ora devo scappare.
Speriamo di vedere presto qualche ricaduta pratica di queste innovazioni architetturali.
Se non per i piccoli/medi team di sviluppo indipendenti, almeno per gli utenti finali (es.: il QuickSync di Intel si "vede" :-) ).
Almeno fornissero librerie runtime già ottimizzate, sarebbe qualcosa.
Con OS-X, ad esempio, Apple ha realizzato librerie runtime C e C++ che implementano già, in modo trasparente per utente e sviluppatore: multicore, vettorializzazione e in qualche caso esecuzione su GPU.
Anche quella è una strada, anche se meno attraente di un singolo kit SDK open source condiviso e implementato da tutti. :-)

[digieffe]

Originariamente inviato da XFer

@digieffe
Sì dalle slide, in particolare la n.7 del gruppo in basso a destra.

Cito, non integralmente:

"HSA Parallel Execution Model:

Programmer supplies a kernel that is run on each work-item
Programmer specifies grid dimensions"

E' il classico approccio dei linguaggi paralleli, come OpenCL, C++ AMP, CUDA: scrivi un kernel per il parallel device in un linguaggio con certi costrutti (tipi di dato, definizione di grid etc.) e poi lo dai in pasto ad un compilatore specifico per la ISA in gioco.
Non per nulla, si fa esplicito riferimento, tra gli ambienti compilati (JVM a parte, insomma), a OpenCL e C++ AMP: per "rassicurare" in qualche modo gli sviluppatori che già li usano.
Tempo fa, il gruppo PGI (Portland) ha fatto una cosa molto simile, con precompilatore in vendita a circa 500 euro (l'ho anche provato).

Ma è un approccio che non mi trova d'accordo, lock-in, niente trasversalità (no Intel, no NVidia, no ARM almeno con certe IP integrate) etc. :-(

vedo ciò che mi posti, anche se ho la sensazione che non sia tutto così, purtroppo ho bisogno di rivedere le slide (che ho visto in settembre), può andar bene se rispondo più lentamente? continuerai a seguire il thread fino almeno domani


Edit: la mia sensazione (ricordi non chiari) era errata, applicavo mentalmente l'autoparallelizzazione e autovettorializzazione di llvm ad hsail.
sarà necessario capire a che punto di maturità è llvm e come lo integreranno in questa soluzione.

[fano]

Leggerò le slide con comodo (ci vorrà qualche oretta), ma la cosa sembra a pelo molto interessante

Mi chiedevo una cosa, ma a sto punto se è così facile come dicono parlare direttamente con la GPU si potrebbe fare a meno dei driver?

Un ipotetico OS futuro potrebbe far disegnare le finestre direttamente alla GPU? A me pare possibile... e sembra, in effetti, logico

Una nota LLVM di per sè è una Macchina Virtuale a basso livello quindi cosa MOLTO diversa da GCC, la cosa più simile a GCC in quel mondo è LCC che però al momento non è finito e si preferisce usare un loro fork dello stesso GCC che, però non compila codice macchina, ma bitcode (sì la 'y' manca volutamente ).

Con LLVM, però, puoi compilare JAVA, C, C++ e potenzialmente qualsiasi cosa... è persino banale scrivere il proprio linguaggio di programmazione[1] e sospetto questa sia la via seguita da AMD... non programmerai in C/C++, ma in qualcosa di molto simile e sarà poi LLVM a farsi il c*lo

Egoisticamente dobbiamo sperare che AMD abbia fatto il colpaccio come con X64 e che nonna Intel sia costretta a seguirla con la coda tra le gambe

[1] Vedi il toy language "Kaledoscopie" ci ho capito persino qualcosa io e mi è persino venuta voglia di cimentarmici

[digieffe]

Originariamente inviato da fano

Leggerò le slide con comodo (ci vorrà qualche oretta), ma la cosa sembra a pelo molto interessante

Mi chiedevo una cosa, ma a sto punto se è così facile come dicono parlare direttamente con la GPU si potrebbe fare a meno dei driver?

Un ipotetico OS futuro potrebbe far disegnare le finestre direttamente alla GPU? A me pare possibile... e sembra, in effetti, logico

Una nota LLVM di per sè è una Macchina Virtuale a basso livello quindi cosa MOLTO diversa da GCC, la cosa più simile a GCC in quel mondo è LCC che però al momento non è finito e si preferisce usare un loro fork dello stesso GCC che, però non compila codice macchina, ma bitcode (sì la 'y' manca volutamente ).

Con LLVM, però, puoi compilare JAVA, C, C++ e potenzialmente qualsiasi cosa... è persino banale scrivere il proprio linguaggio di programmazione[1] e sospetto questa sia la via seguita da AMD... non programmerai in C/C++, ma in qualcosa di molto simile e sarà poi LLVM a farsi il c*lo

Egoisticamente dobbiamo sperare che AMD abbia fatto il colpaccio come con X64 e che nonna Intel sia costretta a seguirla con la coda tra le gambe

[1] Vedi il toy language "Kaledoscopie" ci ho capito persino qualcosa io e mi è persino venuta voglia di cimentarmici

I driver ci saranno sempre ma per l'assegnazione dei lavori non saranno utilizzati (vedi slide 25 e 26 gruppo in alto a sx)
io intendevo llvm IR e strumenti relativi.

[fano]

Originariamente inviato da digieffe

I driver ci saranno sempre ma per l'assegnazione dei lavori non saranno utilizzati (vedi slide 25 e 26 gruppo in alto a sx)

Quello che pensavo è posso rivoltare la frittata? Ovvero posso inviare alla GPU "disegna un quadrato"? O sono limitato a calcoli matematici? Ovvero ad usare la GPU come una... CPU?

Pensavo alla possibilità di scrivere una sorta di "Poor Man's Driver" per OS Open Source che per un motivo o per l'altro non può avere i Driver (per esempio il "mio" Haiku non supporta manco una banalissima GPU Intel ficcata dentro la CPU ) oppure un super Qt o Super Java che disegna direttamente le finestre senza l'intervento nè di Kernel nè di OS!
(Non nascondiamoci dietro ad un dito AWT e SWT non sono venuti bene, e la versione di Eclipse è peggio perchè non supporta il Garbage Collector... liberare memoria? In JAVA?)

Originariamente inviato da digieffe

io intendevo llvm IR e strumenti relativi.

E' appunto ciò di cui parlavo Bitcode o IR - Intermediate Representation, ma facciamolo dire a loro:

The LLVM Core libraries provide a modern source- and target-independent optimizer, along with code generation support for many popular CPUs (as well as some less common ones!) These libraries are built around a well specified code representation known as the LLVM intermediate representation ("LLVM IR"). The LLVM Core libraries are well documented, and it is particularly easy to invent your own language (or port an existing compiler) to use LLVM as an optimizer and code generator.

e quindi? E quindi abbiamo, da una delle loro slide, che "HSAIL is a virtual ISA for parallel programs" che è finalizzato da un JIT (LLVM) che è indipendente per costruzione da CPU & GPU (Bitcode / IR), a me sembra alquanto chiaro, no? ISA sta per Instruction Set Architecture, no? Ovvero, in Italiano, un'architettura per una Macchina Virtuale...

LLVM, ovviamente, può essere un modo per "compilare" HSAIL, a quanto pare JVM è un altro

Accidenti! Ricompilano JAVA in LLVM IR e poi in Open CL! Vi rendete conto? Tu scrivi "normale" JAVA e lui di soppiatto lo trasforma per vostre stesse parole in quel m*rdaio di Open CL o, bontà di LLVM, in un paio di thread JAVA se la vostra GPU fa schifo... a Runtime s'intende
Non è che va a finire che JAVA diventa veloce come C/C++ o persino più veloce?
Di sicuro sarà più facile da programmare senza gli orridi Posix Threads o OpenMP
Il passo successivo? Riscrivere Java in modo che non crei più bytecode, ma direttamente HSAIL loro lo chiamano "Sumatra Project"

Anche la Microsoft, se vuole, lo fo fare a .NET, i ragazzi di Qt potrebbero compilare per HSAIL, gli GNU possono mettersi a riscrivere GCC (auguri!)...

Dite che non è aperto? Tutt'altro io vedo ad occhio centinaia di pagine di Specifiche cosa volete di più? Che lo scrivano al posto vostro ?