[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[paolo.oliva2]

@digieffe
io mi perdo... e se mi perdo ci metto la fantasia e dopo sono problemi

Ma il discorso della parallelizzazione è diverso dal discorso dell'elaborazione dei dati a seconda di dove si risolverebbero più facilmente (FP-IGP). Cioè... se un programma non sfrutta la parallelizzazione perchè non realizzato in un determinato modo o perchè non si può, è penalizzato in primis perchè non sfrutta il multicore dei proci odierni, ma comunque potrebbe sfruttare l'IGP per risolverli, quindi HSA porterebbe comunque un vantaggio in qualsiasi caso.

Poi non sono d'accordo che non sia parallelizzabile quello che non si può parallelizzare... da sempre il processore è alla rincorsa di emulazione del cervello umano, il quale è un esempio massimo di parallelizzazione. Non è che il cervello umano possa vedere un Film parallelizzato, ma comunque una cosa non parallelizzabile è comunque parallelizzata con altre.

[paolo.oliva2]

Originariamente inviato da Ludus

fx 9370 250€
fx 9590 350€

prezzi visti ora nel mio shop abituale.
bè molto meglio del previsto i prezzi. se li limano di 50€ l'uno sono interessantissimi, consumo a parte.

Per un giudizio più esatto bisognerebbe avere una media del Vcore necessario per una determinata frequenza, perchè è impossibile quantificare un costo/prestazioni e il relativo consumo senza avere almeno una media dei Vcore.

Ad esempio... uno del TH aveva acquistato un 9370 e secondo i suoi test con 1,4V terrebbe i 4,7GHz... ma non so in quale situazione. Quello che voglio dire, per fare un esempio, che se con 1,38V tenesse i 4,7GHz con OCCT, vorrebbe dire +200/300MHz a parità di Vcore con l'8350, ma siccome è il Vcore che aumenta i consumi, a Vcore uguale i consumi se non gli stessi sarebbero simili... quindi si avrebbe un 9370 @4,7GHz che consumerebbe tanto quanto un 8350 @4,4GHz.

Figurati che nel sito di Asrock addirittura riportano 1,4V per un 9590 @5GHz... 1 9590 costa quasi quanto 2 8350... ma se fosse vero @5GHz a 1,4V, varrebbe la pena.

[Ludus]

Il consumo a parte è riferito alle controparti Intel, non al 8350. Ora i prezzi di questi due processori sono allineati al 4670k e 4770k.

[paolo.oliva2]

Comunque io ci vedo qualche cosa di più nello sviluppo in un APU della memoria unificata solo per prestazioni superiori lato IGP integrata.

Cioè, se HSA lavora e la IGP dell'APU con hUMA permette una banda maggiore, questo vorrebbe dire IGP on die di potenza maggiore, ma una IGP di potenza maggiore non vuol dire solamente nella grafica, perchè nel momento che HSA lavorerebbe su quell'APU, avrebbe comunque prestazioni superiori perchè l'FP dell'IGP avrà potenze maggiori.

Inoltre bisogna vedere anche 2 altri aspetti.
Attualmente il vero limite di un APU e la sua IGP non è nella banda ma nella miniaturizzazione silicio che comunque non permetterebbe una IGP di potenza maggiore.
Allora perchè AMD si è concentrata su hUMA con Kavery visto che il 28nm Bulk non permetterà chissà quale guadagno in TDP sul 32nm SOI e di conseguenza l'IGP integrata non soffrirebbe di banda mentre quello sforzo se concentrato sull'architettura X86 avrebbe potuto portare più avanti di Steamroller magari accorpando qualche cosa di Exavator?

Se colleghiamo questo al discorso di APU Opteron, scapperebbe fuori un altro scenario... perchè indubbiamente in qualsiasi caso HSA garantirebbe più potenza con un X86 + discreta che con un APU... ma sarebbe la stessa cosa tra un APU in CF con discreta e X86 + discreta (un guadagno maggiore rispetto all'aumento FP in CF), magari perchè un APU garantirebbe uno smistamento dati più fluido con hUMA che senza?

[paolo.oliva2]

Originariamente inviato da Ludus

Il consumo a parte è riferito alle controparti Intel, non al 8350. Ora i prezzi di questi due processori sono allineati al 4670k e 4770k.

Se parliamo di consumo, bisogna considerare molti aspetti.

In primis l'architettura AMD non è affinata quanto quella Intel, quindi comunque a parità di prestazioni e miniaturizzazione silicio quella AMD consumerebbe di più, inoltre il consumo è inferiore più la miniaturizzazione del silicio è spinta, e AMD sul 32nm contro Intel sul 22nm accentua la differenza dei consumi, quindi qualsiasi FX prendiamo in considerazione, consumerà sempre più di un Intel.

Se inglobi il consumo in un discorso di costi inferiori di utilizzo, dipende quanto tempo utilizzi il procio al giorno e quale carico gli dai, e rapportando quanto risparmi al costo superiore degli Intel.

Con un uso 24h/24 365 giorni all'anno e stracaricato, condizione evidentemente impossibile, un Intel risparmierebbe sulla bolletta circa 70€, il che porterebbe ad un pareggio in circa 2 anni. Con un uso di 8h al giorno di cui 4 stracaricato, tutti i giorni dell'anno, e già sarebbe molto di più dell'uso normale, il risparmio si tradurrebbe in circa 20€, al che occorrerebbe un tempo superiore rispetto alla normale vita del sistema per pareggiare.

In poche parole, se la scelta dell'uno o dell'altro è legata solamente ai consumi, di certo un risparmio non lo offrirebbe un 3770K/4770K, se poi vista la domanda sei "sensibile" ai costi, prendi qualsiasi money-bench e vedresti i rapporti effettivi prestazioni/prezzo, ricalcolalo immaginando di accorpare anche il discorso consumi, e tira le somme.

Da parte mia, un 8350 è preferibile ad un 3770K/4770K perchè ha un costo/prestazioni di gran lunga favorevole... e la diffirenza di consumi nell'uso normale non cambierebbe granchè. Un 9370/9590 incide molto di più nel money-bench che nei consumi... per me un 9370 anche se con un money/bench peggiore dell'8350, dovrebbe risultare ancora favorevole nei confronti 3770K/4770K, ho i miei dubbi per un 9590... ma si discuterebbe sul nulla, perchè se per un 10% di prestazioni massime in più uno preferirebbe spendere 150€ in più in un 4770K al posto di un 8350, un 9590 risulterebbe avere quasi un 20% in più di potenza di un 8350, quindi quei 150€ sarebbero a parti invertite, e dividendo quella somma per i consumi/anno superiori, quanto potrebbe essere? 4-5 anni? 2€ in più o in meno al mese non sono nemmeno quantificabili come risparmio, perchè già inciderebbe di più quale VGA ci monterei...

[mtk]

scusate l ot,secondo voi l fx in oc senza liquido messo qui dentro

http://imageshack.us/f/713/ov9a.jpg/

http://imageshack.us/f/585/kxyw.jpg/

è fattibile?
sto facendo un po' di bricolage

[capitan_crasy]

Originariamente inviato da mtk

scusate l ot,secondo voi l fx in oc senza liquido messo qui dentro

http://imageshack.us/f/713/ov9a.jpg/

http://imageshack.us/f/585/kxyw.jpg/

è fattibile?
sto facendo un po' di bricolage

[dobermann77]

Globalfoundries sta programmando una nuova fabbrica.

http://www.businessmagazine.it/news/...ica_48482.html

[mtk]

Originariamente inviato da gridracedriver

In che senso senza liquido? e che tipo di OC?

comunque, hai la mia più profonda ammirazione

attualmente l fx viaggia a 4,8 con raffreddamento a liquido nel suo bel case,pensavo di finire la postazione da gioco che uso per gtr2 e prossimamente per assetto corsa con un case in stile corsaiolo,ma le dimensioni per alloggiare l hardware sono limitate e dovrò usare molto la parte posteriore della lamiera che fissa la mobo per il fissaggio Dell alimentatore e non ho spazio per mettere anche i radiatori....
Ho circa 7 cm utili per un dissipatore ad aria...anche se stavo pensando di usare una canalizzazione orizzontale che sigillerebbe un dissipatore in rame isolandolo dal resto dell hardware,aspirerebbe dal canale del cerchio a sinistra e soffierebbe a destra sempre attraverso il canale,pero avrei bisogno di sapere quanta massa dissipante mettere oppure comprare un dissi e poi farlo a pezzi e usare quello che mi serve...
la,cosa che mi frena Nell attuare il trapianto dal case tradizionale al cerchio,sono le temperature degli altri componenti...
se qualcuno lo usa su un banchetto senza raffreddamenti aggiuntivi,potrebbe darmi qualche dritta

[epimerasi]

Originariamente inviato da AceGranger

hUMA non serve a nulla per l'HSA, è un "escamotage" per far lavorare meglio 2 entita separate, andando ad agire su uno dei colli di bottiglia che è la comunicazione fra le 2 entita, e il senso ce l'ha eccome, visto che permette prestazioni superiori e migliore efficienza.
Oltre a questo permettera anche di superare il limite della memoria on-board, che se nelle APU ( visto i ltarget ) è inifluente, nel caso delle VGA discrete sara una grossa innovazione, visto che andra a colmare uno dei limiti piu grossi del GPGPU, ed è per questo che anche nVidia sta puntando sulla memoria unificata, nome diverso ma stessa identica cosa, e di certo non pensa di fare CPU X86HSA.

Presumo che a breve AMD introdurra al pari delle sue APU e delle prossime VGA di nVidia, la memoria unificata anche per le proprie VGA discrete.

...

Non ha senso HSA se non hai uno spazio di memoria unificato...

[AceGranger]

Originariamente inviato da epimerasi

...

Non ha senso HSA se non hai uno spazio di memoria unificato...

Non ha senso parlare di spazio di memoria unificato quando il CHIP è un'entita unica.
L'HSA sara un chip monolitico, la parte VGA diventera come ora sopno le parti della cpu che decodificano in hardware i video.
Se AMD domani avesse presentato l'HSA la dicitura "memoria unificata" non l'avresti nemmeno sentita nominare.

[paolo.oliva2]

Originariamente inviato da mtk

attualmente l fx viaggia a 4,8 con raffreddamento a liquido nel suo bel case,pensavo di finire la postazione da gioco che uso per gtr2 e prossimamente per assetto corsa con un case in stile corsaiolo,ma le dimensioni per alloggiare l hardware sono limitate e dovrò usare molto la parte posteriore della lamiera che fissa la mobo per il fissaggio Dell alimentatore e non ho spazio per mettere anche i radiatori....
Ho circa 7 cm utili per un dissipatore ad aria...anche se stavo pensando di usare una canalizzazione orizzontale che sigillerebbe un dissipatore in rame isolandolo dal resto dell hardware,aspirerebbe dal canale del cerchio a sinistra e soffierebbe a destra sempre attraverso il canale,pero avrei bisogno di sapere quanta massa dissipante mettere oppure comprare un dissi e poi farlo a pezzi e usare quello che mi serve...
la,cosa che mi frena Nell attuare il trapianto dal case tradizionale al cerchio,sono le temperature degli altri componenti...
se qualcuno lo usa su un banchetto senza raffreddamenti aggiuntivi,potrebbe darmi qualche dritta

Complementi per la bellezza del tuo banchetto, ma non ho capito bene se sarebbe sempre a liquido o ad aria.

Comunque l'ALI ha la ventola di suo... se il procio lo raffreddi a liquido l'unica cosa da guardare è la parte ali della mobo, ma con una ventolina uso cacchio va più che bene... (e quella del dissi stock del procio sarebbe sovradimensionata). Siccome io uso intensamente l'SB, ho notato che raffreddare solamente la parte ALI della mobo non raffreddava a sufficienza l'SB950, quindi ho messo una ventola pure lì (sempre quella del dissi stock che ne ho in gran numero) che a sua volta permette temp più basse pure al NB.
Io metterei una ventolina pure agli HD... non fa mai male.

[paolo.oliva2]

@epimerasi
Ci sono dei punti che non capisco.
HSA ha lo scopo di utilizzare la VGA come aiuto all'FP del procio, e fin qui ci siamo.

Quello che non comprendo, è che se si parlasse di chip monolitico a quel punto o tutti i produttori solamente di VGA si metterebbero a produrre APU (situazione improbabile) o verrebbero tagliati fuori (vedendo il tot di patner al progetto HSA, presumo che il progetto non parta con l'intenzione di escludere produttori ma di inglobarne il più possibile, quindi a maggior ragione di non escludere i soli produttori di VGA).

Ora... è indubbio che HSA per lavorare abbia bisogno di memoria unificata, ma a quel punto si escluderebbero tutti gli X86 e idem gli APU che non avrebbero la memoria unificata, oppure HSA a livello software la emulerebbe e/o potrebbe essere inglobata sulla VGA discreta?

[carlottoIIx6]

Originariamente inviato da digieffe

si ma la igp (che consuma e non poco) non so quanto sia più efficiente della cpu nei sistemi mobili... (va a finire che la batteria dura 4 ore)

nel mobile hanno già le loro gpu.

forse a livello economico ma non ne sarei così sicuro.
Invece a livello tecnologico sui chip complessi e/o compilatori? brevetti, esperienza, know-how, team di lavoro, tecnologie e strutture produttive (e mi fermo qui) non mi risulta che questi altri siano al livello... dovrebbero comprarsela unitamente a Nvidia così forse...

non devono fare le cpu, ma dare i soldi e ne ahnno tanti. a fare le cpu ci pensano amd arm ecc

mbe? anche se minimo c'è sempre un overhead, insomma anche se leggono la stessa memoria nello stesso modo sono 2 "chip" separati!
Se fossero realmente integrati (senza vedere nel die la separazione tra parte cpu e igp, condividendo registri, caches di ogni libello, ecc) forse entrerebbe in gioco la sinergia ossia 1 + 1 > 2, fino a quel momento sarà per forza di cose 1+1 <= 2.

in verità non è neanche così, la cpu è sempre più veloce della gpu, la gpu esegue lentamente molti più calcoli in parallelo. Quest'ultimo è uno dei motivi per cui 1 + 1 <= 2.

la gpu è lenta ma fa molte cose contemporaneamente.

Aggiungo per i più tecnici che per sapere se la gpu ha terminato il lavoro, attualmente si sono affidati al metodo del "polling", "ottimo direi", speriamo che cambino metodo.

Se non ti fidi dai una occhiata alla documentazione (non gli articoli ipersemplificati di tommy il bugiardo) e ne riparliamo...


we! sia chiaro che non c'è l'ho con te. E' che questo thread lo leggono in molti ed allora su un argomento nuovo come questo cerco di dare i miei 2 cent per non creare confusione... ok? (poi posso sbagliare pure io )

[epimerasi]

Originariamente inviato da digieffe

ciao epimerasi, scusa se mi intrometto, di certo AceGranger non ha bisogno del mio supporto, ma te lo semplifico così slide n.10 primo gruppo http://hsafoundation.com/hot-chips-2...ail-hsa-hsail/

quindi hUMA non è necessario per hsa.


Se qualcuno postasse le slide che ho elencato molte domande non ci sarebbero neppure:
- in alto a sx le slide n. 3, 25, 26, 28;
- in alto a dx la 23;
- in basso a sx la 7, 8, 12 (se non è una ripetizione);
- in basso a dx 2, 3, 7, 15

Alto a sx:
Slide 3: quella è la situazione attuale, non HSA. Il grafico esemplifica il traffico che c'è attualmente da gestire quando si fa un programma che usa CPU+GPU. HSA serve -teoricamente- proprio per semplificare questo workflow.

Dalla slide 5 in poi: è esattamnete quello che sto cercando di dirvi. Leggi attentamente la slide 9.

hUMA non è nient'altro che l'implementazione del modello descritto in quelle slide.

Basso a dx:
Slide 2: "Emerging solution", HSA Hardware: leggi cosa c'è scritto.
Slide successive: il compilatore a run time prende HSAIL e lo trasforma in binario. Se lo spazio di indirizzamento non fosse condiviso, il programmatore dovrebbe prendersi in carico di gestire tutto il traffico fra CPU e GPU, ovvero quello che già si fa attualmente. Non avresti risolto nulla. Si perderebbe il senso di usare lo strato software intermedio.

[epimerasi]

Originariamente inviato da AceGranger

Non ha senso parlare di spazio di memoria unificato quando il CHIP è un'entita unica.
L'HSA sara un chip monolitico, la parte VGA diventera come ora sopno le parti della cpu che decodificano in hardware i video.
Se AMD domani avesse presentato l'HSA la dicitura "memoria unificata" non l'avresti nemmeno sentita nominare.

Quando stai parlando di HSA non stai parlando di hardware, ma di software. Perchè funzioni questo paradigma HAI BISOGNO di uno spazio di memoria unificato.

Dovresti leggere quelle slide.

[epimerasi]

Originariamente inviato da paolo.oliva2

@epimerasi
Ci sono dei punti che non capisco.
HSA ha lo scopo di utilizzare la VGA come aiuto all'FP del procio, e fin qui ci siamo.

Quello che non comprendo, è che se si parlasse di chip monolitico a quel punto o tutti i produttori solamente di VGA si metterebbero a produrre APU (situazione improbabile) o verrebbero tagliati fuori (vedendo il tot di patner al progetto HSA, presumo che il progetto non parta con l'intenzione di escludere produttori ma di inglobarne il più possibile, quindi a maggior ragione di non escludere i soli produttori di VGA).

Ora... è indubbio che HSA per lavorare abbia bisogno di memoria unificata, ma a quel punto si escluderebbero tutti gli X86 e idem gli APU che non avrebbero la memoria unificata, oppure HSA a livello software la emulerebbe e/o potrebbe essere inglobata sulla VGA discreta?

Allora, qui si sta facendo confusione fra hardware e software.

HSA è la proposta per un modello di programmazione che dovrebbe semplificare l'approccio alla scrittura di programmi che vogliono fare uso delle unità GPU (discrete o integrate nelle APU che siano).

Detta in maniera brutale: ora i programmatori usano principalmente due cose C e openCL oppure C e CUDA. OpenCL e CUDA non sono nient'altro che API standard, ovvero io (gruppo Khronos) decido quello che devono fare le GPU per ogni generazione e stabilisco uno standard che i programmi devono seguire per accedere alle funzioni della GPU. È più o meno quello che fa OpenGL o directX.

Il punto è che un'API di questo livello (per quanto migliorino di generazione in generazione):
1) è più di alto livello rispetto al linguaggio macchina ma lascia completamente al programmatore la gestione del traffico dati fra CPU/GPU e la gestione della memoria della GPU.
2) mi vincola nella scrittura dei kernel che devono girare sulla GPU (è molto difficile fare qualcosa che giri bene su tutto, spesso devo fare compromessi)

QUando parliamo di programmi per GPU parliamo di programmi altamente paralleli, ovvero di sequenze di istruzioni che vengono eseguite su tanti dati parallelamente. Per kernel in questo caso si intende il pezzetto di programma che viene applicato su tanti dati parallelamente.

HSA si pone come interfaccia fra programmatore e hardware.

Il parallelo più semplice da fare è quello di Java: la Java virtual machine si mette come livello intermedio fra programmatore (che scrive il programma in un linguaggio solo) e l'hardware/sistema operativo (che può essere molto diverso: x86, power, arm, windows, linux etc...). Sta a produttore di hardware/di sistemi operativi/sviluppatore del linguaggio sfornare le virtual machine per far andare lo stesso programma java sulle varie piattaforme, alleggerendo il lavoro del programmatore.

Nel caso di HSA, HSA permetterebbe la scrittura dei kernel nel linguaggio preferito dal programmatore (senza che debba impararsi un nuovo linguaggio o una nuova API appositamente). Il kernel viene interpretato in linguaggio intermedio (HSAIL). Sta poi ai diversi produttori di hardware fornire dei driver che permettano alla CPU/GPU/APU eseguire il codice HSAIL (con un compilatore just-in-time).

[AceGranger]

Originariamente inviato da epimerasi

Quando stai parlando di HSA non stai parlando di hardware, ma di software. Perchè funzioni questo paradigma HAI BISOGNO di uno spazio di memoria unificato.
Dovresti leggere quelle slide.

HSA non è la parte Hardware Hardware Heterogeneous System Architecture, e HSAIL HSA Intermediate Language la parte software ?

[paolo.oliva2]

Originariamente inviato da epimerasi

Allora, qui si sta facendo confusione fra hardware e software.

HSA è la proposta per un modello di programmazione che dovrebbe semplificare l'approccio alla scrittura di programmi che vogliono fare uso delle unità GPU (discrete o integrate nelle APU che siano).

Detta in maniera brutale: ora i programmatori usano principalmente due cose C e openCL oppure C e CUDA. OpenCL e CUDA non sono nient'altro che API standard, ovvero io (gruppo Khronos) decido quello che devono fare le GPU per ogni generazione e stabilisco uno standard che i programmi devono seguire per accedere alle funzioni della GPU. È più o meno quello che fa OpenGL o directX.

Il punto è che un'API di questo livello (per quanto migliorino di generazione in generazione):
1) è più di alto livello rispetto al linguaggio macchina ma lascia completamente al programmatore la gestione del traffico dati fra CPU/GPU e la gestione della memoria della GPU.
2) mi vincola nella scrittura dei kernel che devono girare sulla GPU (è molto difficile fare qualcosa che giri bene su tutto, spesso devo fare compromessi)

QUando parliamo di programmi per GPU parliamo di programmi altamente paralleli, ovvero di sequenze di istruzioni che vengono eseguite su tanti dati parallelamente. Per kernel in questo caso si intende il pezzetto di programma che viene applicato su tanti dati parallelamente.

HSA si pone come interfaccia fra programmatore e hardware.

Il parallelo più semplice da fare è quello di Java: la Java virtual machine si mette come livello intermedio fra programmatore (che scrive il programma in un linguaggio solo) e l'hardware/sistema operativo (che può essere molto diverso: x86, power, arm, windows, linux etc...). Sta a produttore di hardware/di sistemi operativi/sviluppatore del linguaggio sfornare le virtual machine per far andare lo stesso programma java sulle varie piattaforme, alleggerendo il lavoro del programmatore.

Nel caso di HSA, HSA permetterebbe la scrittura dei kernel nel linguaggio preferito dal programmatore (senza che debba impararsi un nuovo linguaggio o una nuova API appositamente). Il kernel viene interpretato in linguaggio intermedio (HSAIL). Sta poi ai diversi produttori di hardware fornire dei driver che permettano alla CPU/GPU/APU eseguire il codice HSAIL (con un compilatore just-in-time).

Si, quello che non capisco è la parte in neretto.
Praticamente il driver è per far sì che il software possa riconoscere l'hardware e quindi che si possa utilizzarlo.
Ora... prendiamo un 8350, un Trinity ed un Kaveri. I primi 2 non hanno nulla di supporto hardware per la memoria unificata, Kaveri si.
Ora... che AMD con Kaveri rilasci un driver per supporto codice HSAIL (quindi HSA) è scontato (altrimenti per cosa avrebbe fatto hUMA?), ma con Trinity e 8350... ammesso e concesso che AMD abbia la volontà di realizzare il driver, lo potrebbe fare ugualmente o l'assenza di hUMA renderebbe la cosa impossibile?

Premetto che essendo tutto in alto-mare, probabilmente è difficile sapere alcune cose con certezza, ma più che altro era per capire la posizione di AMD, perchè chi non è competente (come me), non riesce a discernere un annuncio stile "primo APU con supporto memoria unificata" se commerciale o di grande importanza hardware.
Cioè... che hUMA serva a Kavery per i vantaggi con l'IGP on-die al di fuori di HSA, è un fatto a parte, ma che poi rappresenti il 1° APU al mondo che potrebbe già supportare HSA a tutti gli effetti, non sarebbe di poco conto, perchè AMD tramite Kaveri e le sue VGA, potrebbe offrire HSA (a patto che il software venga ricompilato correttamente, cosa che comunque AMD potrebbe forse richiedere direttamente alle ditti produttrici di software) senza comunque aspettare che sia definito uno standard HSA.

[epimerasi]

Originariamente inviato da AceGranger

HSA non è la parte Hardware Hardware Heterogeneous System Architecture, e HSAIL HSA Intermediate Language la parte software ?

EDIT: H non sta per Hardware.

HSA indica tutta la piattaforma su cui si basa questo approccio di interpretazione/compilazione (in quelle diapositive viene descritta nel dettaglio: scopo, progettazione, modello della memoria, etc...)

HSAIL è un componente di HSA, in particolare è un linguaggio intermedio fra i linguaggi di programmazione (e relative librerie) e l'hardware target su cui devono girare i programmi.

http://www.slideshare.net/hsafoundat...ail-hsa-hsail/

In particolare vai nella slide 12 in cui si vede in parallelo qual è lo stack delle applicazioni che usano l'hardware grafico e quale sarà lo stack secondo HSA.

Nella slide 39 c'è una comparazione: ignora le prime 3 colonne, (che indicano le linee di codice necessarie a implementare quel programma su CPU). Nelle altre vedi che utilizzare HSA ti fa risparmiare molto tempo rispetto ad usare C&OPenCL, C++&OpenCl, C++&AMP (una libreria per il calcolo parallelo), con prestazioni simili.