Source Engine 2 girerà su Vulkan

[Redazione di Hardware Upg]

Link alla notizia: http://www.gamemag.it/news/source-en...kan_58955.html

Valve supporterà Vulkan con il suo nuovo motore grafico. Si tratta delle API che raccolgono il testimone delle OpenGL.

Click sul link per visualizzare la notizia.

[Vul]

Saranno 20 anni che i giochi valve girano su opengl...

In ogni caso non credo che vulkan offrirà le stesse prestazioni di dx 12 (in termini di fps).

E che cavolo è un api che deve funzionare tanto su x86 con gpu dedicata quanto su arm..

L'essenza contraria dell'ottimizzazione.

[Tedturb0]

Originariamente inviato da Vul

Saranno 20 anni che i giochi valve girano su opengl...

In ogni caso non credo che vulkan offrirà le stesse prestazioni di dx 12 (in termini di fps).

E che cavolo è un api che deve funzionare tanto su x86 con gpu dedicata quanto su arm..

L'essenza contraria dell'ottimizzazione.

Tu si che te ne intendi..
per altro directx anche funziona sia su x86 che su arm che su altro..

[metrino]

Le api grafiche sono nate proprio per questo: così ognuno si può scrivere il proprio motore sicuro che l'ottimizzazione sia stata fatta da qualcun altro al livello un po' più basso.

Il problema sta nel fatto che le api devono essere abbastanza di dettaglio da permettere ottimizzazioni di fino specifiche degli strati superiori ma devono anche essere abbastanza generiche da supportare gli sviluppatori senza che questi debbano scrivere righe e righe di codice col copia-incolla per fare qualcosa di ripetitivo.

[Cfranco]

Originariamente inviato da Vul

Saranno 20 anni che i giochi valve girano su opengl...

In ogni caso non credo che vulkan offrirà le stesse prestazioni di dx 12 (in termini di fps).

E che cavolo è un api che deve funzionare tanto su x86 con gpu dedicata quanto su arm..

L'essenza contraria dell'ottimizzazione.

E' da un bel po' che non si programma più in assembly direttamente sui registri delle schede video

[WarDuck]

Originariamente inviato da Vul

Saranno 20 anni che i giochi valve girano su opengl...

In ogni caso non credo che vulkan offrirà le stesse prestazioni di dx 12 (in termini di fps).

E che cavolo è un api che deve funzionare tanto su x86 con gpu dedicata quanto su arm..

L'essenza contraria dell'ottimizzazione.

Sia Vulkan che DirectX12 sono API di "alto livello".

L'ottimizzazione è un passo che avviene in fase di compilazione.

Immagina di scrivere un programma C, questo viene compilato e ottimizzato, e puoi scegliere per quale architettura generare il codice e tutta una serie di ottimizzazioni legate alla presenza o meno di certe funzionalità nelle CPU...

Nel caso delle GPU in realtà la faccenda è simile anche se più complessa... ad esempio se consideriamo il calcolo general purpose per GPU che negli ultimi anni sta prendendo sempre più piede, purtroppo lì non si può prescindere dall'architettura.

Questo non c'entra molto con la parte squisitamente grafica, ma penso sia simile.

Se usi CUDA su scheda video nVidia non puoi comunque prescindere dalla particolare architettura (Kepler/Maxwell...).

Se usi OpenCL purtroppo è la stessa cosa se non peggiore.

A livello di GPU, general purpose, non siamo ancora ai livelli di compromesso tra prestazioni e codice ad alto livello raggiungibili dal software pensato per CPU.

[bobafetthotmail]

Originariamente inviato da Vul

E che cavolo è un api che deve funzionare tanto su x86 con gpu dedicata quanto su arm..

L'essenza contraria dell'ottimizzazione.

??? è una API per parlare con la GPU/driver, cosa c'entra l'architettura del processore adesso?

Sia Vulkan che DirectX12 sono API di "alto livello".

Non erano "basso livello" cioè vicino all'hardware?

Sono dette di basso livello perchè danno allo sviluppatore la possibilità di comandare più direttamente la GPU. Questo è ovviamente più complesso. Questo, se tale sviluppatore ha voglia di ottimizzare, può fare in modo che il suo engine (programma) chiami la GPU quando fa più comodo a lui/suo programma, quindi di integrare di più l'engine con la GPU e, tra le altre cose, di sfruttare più di 1 core del processore per le chiamate alla GPU.

Una API di alto livello cioè più astratta come le DX11 è MOLTO più facile da usare perchè lo sviluppatore deve dare molti meno comandi alla GPU, ma limita l'ottimizzazione di brutto perchè il limite dell'ottimizzazione è quanto tale API riesce a tradurre bene i comandi astratti e semplici in qualcosa che la GPU può eseguire (che è sempre roba di basso livello).

Visto che fare un programma abbastanza intelligente da predire quale è il modo per gestire la GPU a seconda dell'engine specifico richiede neanche un AI, ma poteri di onniscienza e previsione del futuro, anche le API astratte migliori le prenderanno sempre senza se e senza ma da un programma scritto decentemente con API di basso livello.

[pindol]

no ma aspettate un momento,

quando diavolo è stato presentato il Source Engine 2? Esistono già delle techdemo o è solo in via di sviluppo?

Pindol

[bobafetthotmail]

Originariamente inviato da pindol

quando diavolo è stato presentato il Source Engine 2? Esistono già delle techdemo o è solo in via di sviluppo?

Dota 2 è l'unico gioco dove c'è qualche feature nuova presa dal source 2, ma a parte quello è ancora in sviluppo.
http://www.extremetech.com/extreme/1...mer-map-editor

Dipende da che parte lo guardi

è il gergo da sempre eh. "basso" è sempre stato "vicino all'hardware"

http://www.computerhope.com/jargon/l/lowlangu.htm
A low-level language is a programming language that provides little or no abstraction of programming concepts, and is very close to writing actual machine instructions. Two good examples of low-level languages are assembly and machine code.


Poi certo, è ovvio che DX12 e Vulkan non sono Assembly, quindi non sono di livello basso in assoluto, ma sono di livello molto più basso delle DX11, e un pò più basso delle OpenGL.

[pindol]

Originariamente inviato da bobafetthotmail

Dota 2 è l'unico gioco dove c'è qualche feature nuova presa dal source 2, ma a parte quello è ancora in sviluppo.
http://www.extremetech.com/extreme/1...mer-map-editor

a ok niente tech demo quindi ancora...

spero tanto in questo nuovo engine di Valve anche perchè solitamente nuovo engine, dovrebbe significare nuovo Half Life

Pindol

[WarDuck]

Originariamente inviato da bobafetthotmail

Non erano "basso livello" cioè vicino all'hardware?

Sono dette di basso livello perchè danno allo sviluppatore la possibilità di comandare più direttamente la GPU. Questo è ovviamente più complesso. Questo, se tale sviluppatore ha voglia di ottimizzare, può fare in modo che il suo engine (programma) chiami la GPU quando fa più comodo a lui/suo programma, quindi di integrare di più l'engine con la GPU e, tra le altre cose, di sfruttare più di 1 core del processore per le chiamate alla GPU.

Una API di alto livello cioè più astratta come le DX11 è MOLTO più facile da usare perchè lo sviluppatore deve dare molti meno comandi alla GPU, ma limita l'ottimizzazione di brutto perchè il limite dell'ottimizzazione è quanto tale API riesce a tradurre bene i comandi astratti e semplici in qualcosa che la GPU può eseguire (che è sempre roba di basso livello).

Visto che fare un programma abbastanza intelligente da predire quale è il modo per gestire la GPU a seconda dell'engine specifico richiede neanche un AI, ma poteri di onniscienza e previsione del futuro, anche le API astratte migliori le prenderanno sempre senza se e senza ma da un programma scritto decentemente con API di basso livello.

Diciamo che nel corso del tempo si è formata una gerarchia di linguaggi e di API a diversi livelli di astrazione, tali per cui "basso" o "alto" è relativo effettivamente al livello in cui ci si mette a guardare.

Bivvoz scherzava ma alla fine non c'è andato neanche lontano... "dipende".

DX12 e Vulkan dovrebbero consentire un'astrazione minore rispetto ai predecessori, quindi sicuramente sono API di più basso livello rispetto a prima.

Di fatto se pensiamo a come si sono evolute le cose in ambito CPU questo è un po' paradossale, e rispecchia comunque uno dei problemi nel programmare le GPU oggi, ovvero che volenti o nolenti per ottenere prestazioni "decenti" devi per forza di cose guardare l'architettura.

Intendiamoci anche con le CPU se uno vuole ottimizzare seriamente non puoi prescindere dall'architettura, ma i compilatori sono molto avanzati nell'ottimizzazione (in alcuni casi basta anche solo prendere piccoli accorgimenti nel codice di alto livello per far generare al compilatore del codice più prestante, senza doverlo fare "a mano" o ricorrere ad assembly).

Ma con le GPU non credo ci sia ancora lo stesso livello di maturità, e questo spiega la "regressione", intesa come passaggio da una API di alto livello ad una di basso livello.

Ci si è resi conto che quelle astrazioni costavano parecchio.

[Titanox2]

finalmente dota 2 sarà ancora di più in hd cosi vedo meglio il cappellino da 20 euro che ho comprato

[bobafetthotmail]

Originariamente inviato da WarDuck

Ma con le GPU non credo ci sia ancora lo stesso livello di maturità, e questo spiega la "regressione", intesa come passaggio da una API di alto livello ad una di basso livello.

Oddio, non la chiamerei "regressione" anzi, la chiamerei evoluzione.

Storicamente si è preferito risolvere i problemi dii scarsa ottimizzazione software con hardware più potente, le API di controllo delle GPU dovevano solo rendere facile gestire hardware anche molto diverso.

Ora che non puoi fare hardware (significativamente) più potente senza investimenti paurosi lato CPU che alla fine impatta anche le GPU, si ritorna trascinando i piedi e con lo sguardo basso verso l'ottimizzazione software.

Sia i proci Intel che AMD hanno architetture fisiche abbastanza diverse, nonostante siano entrambi x86-64, cioè possano eseguire una serie di istruzioni particolari, il come ciò avviene varia a seconda del tipo di CPU.

DX12 e Vulkan mi sembra tanto che vadano in questa direzione, un'API di più basso livello possibile che fa da ponte sulle differenze di architettura che abbiamo tra una GPU e l'altra (anche di due generazioni diverse) ma con il minimo possibile di astrazione per spremere le prestazioni.

Ironicamente spremono di più la CPU che la GPU, e questo lo porto come esempio di quanto sia andato avanti il giochino di cui sopra, da sempre una GPU è CPU-limited, ma solo l'ottimizzazione software poteva risolvere il problema.

Quindi Vulkan/DX12 = x86-64 per le GPU, se mi si passa la bestialità per un momento visto che è comunque più astratta che le istruzioni di un processore.

Ci si è resi conto che quelle astrazioni costavano parecchio.

Storicamente quelle astrazioni hanno fatto la fortuna delle DX e di MS.

Quando sono state inventate (e quei criceti di openGL stavano cincischiando e facendo dei casini tremendi), sono state inventate per permettere agli sviluppatori di fare un gioco che funzionasse su molto hardware diverso (dentro all'OS windows).
Quando c'erano ancora altri oltre a ATI e NVIDIA a fare GPU.

Quando le console avevano hardware uguale per permettere agli sviluppatori di ottimizzare e controllare direttamente l'hardware, mentre fare la stessa cosa su PC sarebbe stato un suicidio causa millimila componenti diversi.

Comunque sono sicuro che non vedremo nessun hl3 (se mai lo vedremo) prima di steamos e steam machine ufficiali.

Non mi sorprenderebbe se facessero HL3 solo per SteamOS. Sarebbe una esclusiva bella grossa, non credi?

[bobafetthotmail]

Originariamente inviato da Bivvoz

Ma in teoria non basterebbe fare delle API di alto livello meglio ottimizzate?

Come ho detto, per farlo servirebbero doti di onniscienza.

Le API per controllare la GPU sono utilizzate dal game engine, un programma che gira sul processore.

Non puoi ottimizzare una mazza delle API se non sai come funge il game engine.

Ogni game engine si suppone che sia relativamente diverso dagli altri, e ovviamente in genere sono closed-source.

Anche assumendo che tu ottimizzi l'API per un game engine... dopo hai un profilo di ottimizzazione per ogni game engine, perchè l'ottimizzazione per l'engine X va a incastrare brutalmente il game engine Y., e ci viene un bordello assurdo da mantenere per chi fa l'API.

In parte questo avviene già, comunque. I driver "ottimizzati" per un certo gioco, fanno proprio questo. Non è vuoto marketing. La differenza si vede.

Comunque, nel frattempo, avere a che fare con driver open che gestiscono quelle API aiuta parecchio nella ottimizzazione del game engine, perchè puoi andare a vedere i driver cosa fanno in realtà, dopo che chiami le API.
http://www.phoronix.com/scan.php?pag...g-vulkan&num=1

Quindi linux e l'open in genere sono effettivamente interessanti a livello commerciale in questa nuova era.

Cioè posso fare cose ottimizzate meglio con il basso livello ma ci vuole un sacco di tempo e fatica in più.

Vero, ed è la ragione per cui hanno ignorato l'elefante nella stanza tutto questo tempo.

Tutto sto circo è figlio del fatto che Intel non è riuscita a portare i processori in singlecore alle frequenze mirabolanti che avrebbe voluto ai gloriosi tempi dei Pentiun 4.

Sono partiti con i processori in multicore, che costringono i programmatori a spezzare il programma in più porzioni per poter impegnare più di un core.

Guarda che è uno sbattimento atomico, fare tutto per un procio singlecore o con 2-4 core è molto più facile che impegnarne 8+.

Ma costruire fisicamente un processore singlecore più potente andava contro la volontà diddio, quindi ci si arrangia.

Qui a livello grafico, si sono accontentati di API poco ottimizzate perchè comunque Intel riusciva a garantire un aumento decente di IPC ogni generazione di processori, per quanto multicore.
E un bel "crepa" ad AMD che aveva IPC scarso e 6-8 core.... aspetta chi è che ha tirato fuori Mantle (poi confluito in Vulkan quando MS ha risposto con le DX12)? Ah ecco, tutto si tiene.

Ma sta degenerando, Intel è già da un pezzo che non riesce a fare processori significativamente più potenti come IPC.
C'è gente che resta sui Sandy Bridge di 3 anni fa e gioca perfettamente bene, o anche tu col tuo PC.

Quindi si sono messi il cuore in pace e le pive nel sacco. Se vogliono continuare a vendere GPU discrete gaming (visto che le vendite di discrete scarse è in caduta libera causa GPU integrate) devono aggirare sta bazza della CPU, costi quello che costi.

E nota bene che non è un problema grosso ORA dove grosso modo vendono lo stesso, ma per il futuro. Loro stanno facendo la mossa ORA per evitare di chiudersi in una strada senza uscita in futuro.
L'ottimizzazione software è una brutta puttana, ci vuole un tempo non tanto prevedibile per avere un prodotto decente, non è un cambio di generazione di processore che tra tick tock e taaaac! è prevedibile e a basso rischio.

[Vul]

Originariamente inviato da Bivvoz

Comunque sono sicuro che non vedremo nessun hl3 (se mai lo vedremo) prima di steamos e steam machine ufficiali.

SteamOS già c'è eh

Steam Machine son già state annunciate.

HL3 probabilmente non lo vedremo mai.

Valve guadagna il 30 % di ogni vendita effettuata su steam...

Avrebbero macchine da soldi facilissime da rilasciare (vedi portal 3, l4d 3..).

Half Life 3 potrebbe vendere anche tantissimo, ma sarebbe quasi sicuramente un forte backslash se dopo 10 anni non è IL GIOCO.

[bobafetthotmail]

Originariamente inviato da Bivvoz

Ma infatti la più grande evoluzione nell'architettura delle cpu l'ha fatta AMD con HSA e l'hanno capito tutti, solo che AMD nel mercato pc è il pesce piccolo e nessuno rischia.
Ma nel mondo ARM la musica è molto diversa.

Perchè resta una "accelerazione su GPU", rivoluzionaria, ma su GPU.

Nel mondo embedded usare acceleratori hardware di vario tipo è la norma quindi ci si sono buttati a pesce.

Ma sul mercato PC... eh... resta quello che avevo detto sopra,
"è uno sbattimento atomico, fare tutto per un procio singlecore o con 2-4 core è molto più facile che impegnarne 8+."

Mercato workstation e server AMD è fuori da troppo.

Il momento della verità ci sarà con Zen, che si vedrà la offerta AMD per i server quanto piace e quanto se la gioca con le offerte di Intel e Nvidia.
SE se la cava bene, allora arriva anche su desktop. Se fallisce resta negli embedded, e AMD probabilmente passa a fare processori ARM e basta.

[bobafetthotmail]

Originariamente inviato da Bivvoz

Non dovrebbe manco essere complicato perchè esistono dei compilatori fatti apposta.

Nono aspe, questa me la ero persa. Se ci sono compilatori che gestiscono la storia in automatico via HSA cambia molto.

Io ero rimasto al fatto che veniva aggiunta ai compilatori tipo il gcc (quello di linux) la possibilità di sfruttare HSA se ti va e se sai usarla.

La verità è che l'installato è inesistente.

Perchè questa roba deve andare PRIMA su workstation e server perchè qualcuno si degni di usarla, le APU non le sta cagando nessuno neanche nel settore consumer.

Finchè AMD non offre una cippa per server, HSA non se lo fila nessuno.

Quindi o Zen o resta su ARM e basta.

[bobafetthotmail]

Abbeh, perchè io sono tanto qualificato invece.

Comunque, a Marzo hanno pubblicato lo standard HSA 1.0 (tipo 2 anni dopo la presentazione di HSA nel 2013), avevo letto quello.

link alla documentazione

In grassetto le parti importanti.

The HSA system architecture defines a consistent base for building portable applications that access the power and performance benefits of the dedicated kernel agents. Many of these kernel agents, including GPUs and DSPs, are capable and flexible processors that have been extended with special hardware for accelerating parallel code. Historically these devices have been difficult to program due to a need for specialized or proprietary programming languages. HSA aims to bring the benefits of these kernel agents to mainstream programming languages using similar or identical syntax to that which is provided for programming multi-core CPUs. For more information on the system architecture, refer to the HSA Platform System Architecture Specification Version 1.0.

Quindi, partono dicendo che ad oggi ci sono una valanga di coprocessori (che chiamano "kernel agent" perchè fanno cose per il kernel, non sono controllati direttamente) che tra le altre cose sono fatti solo per o hanno anche capacità di accelerare codice parallelizzato.
Una GPU dedicata è un coso con migliaia di piccoli e deboli core (una integrata ne ha meno ma il concetto è lo stesso), progettato per gestire un carico massivamente parallelizzato cioè calcolare momento per momento cosa mostrare in ogni singolo pixel dello schermo.
Visto che ci sono una valanga di pixel, che per ogni singolo pixel la GPU deve eseguire gli stessi identici calcoli e che il risultato del pixel A non influenza il risultato del pixel B, il carico è estremamente parallelizzabile.

Parlano anche di DSP, che sono Digital Signal Processors. Processori di manipolazione del suono, video, eccetera.
Stessa storia delle GPU, ma in genere limitati a poche classi di operazioni (e costano poco).
Questa è roba embedded più che PC, tipo negli scatolotti da pedaliera che fanno gli effetti per le chitarre elettriche, ma anche per i sensori audio/video o il sonoro in uno smartphone o elettronica di consumo, tipo telefoni normali/cordless/citofoni.

Dicono che fino ad ora per programmare questi cosi si ha sempre dovuto usare un linguaggio specifico o proprietario o chessò, quindi non erano molto usati al di fuori delle nicchie dove non se ne poteva fare a meno, e anche lì ci sono casi in cui sono usate male causa difficoltà di programmarle (HPC ed embedded).

Dicono che HSA vuole rendere facile utilizzare questi coprocessori quanto è facile scrivere un programma per CPU multicore (in senso assoluto non è così facile, ma è più facile che usare il CUDA), semplicemente perchè uno sviluppatore scrive in linguaggio a scelta e poi il resto è gestito da compilatori e da software di basso livello.

Questo significa che comunque chi fa il programma deve essere capace di fare un programma moderatamente parallelizzato anche normalmente, se chi fa il programma non è capace, HSA non lo salva magicamente.

Figure 1–1 HSA Software Architecture shows how the HSA runtime fits into a typical software architecture stack. At the top of the stack is a programming model such as OpenCL™, Java, OpenMP, or a domain-specific language (DSL). The programming model must include some way to indicate a parallel region that can be accelerated. For example, OpenCL has calls to clEnqueueNDRangeKernel with associated kernels and grid ranges. Java defines stream and lambda APIs, which provide support for both multi-core CPUs and kernel agents. OpenMP contains OMP pragmas that mark loops for parallel computing and that control other aspects of the parallel implementation. Other programming models can also build on this same infrastructure.

Quindi abbiamo che vari linguaggi vengono compilati da compilatori HSA-aware che rilevano parti del codice che possono essere smollati alla GPU/acceleratore di calcolo parallelizzato.
Se il linguaggio in sè permette di specificare/capire quali parti beneficierebbero se parallelizzate, e fa alcuni esempi con java e OpenMP.
Ma si parlava anche di C, C++, Python, eccetera da altre parti.

The language compiler is responsible for generating HSAIL code for the parallel regions of code. The code can be precompiled before runtime or compiled at runtime. A high-level compiler can generate the HSAIL before runtime, in which case, when the application loads the finalizer, converts the HSAIL to machine code for the target machine. Another option is to run the finalizer when the application is built, in which case the resulting binary includes the machine code for the target architecture. The HSA finalizer is an optional element of the HSA runtime, which can reduce the footprint of the HSA software on systems where the finalization is done before runtime.

Il compilatore di ogni linguaggio deve conoscere HSA visto che è quello che genera dei binari HSAIL (HSA Intermediate Language) con le porzioni di codice sorgente che sono da smollare al coprocessore di calcolo parallelo (GPU o altro).

La compilazione può avvenire a carico dello sviluppatore (quindi ti danno un binario) o prima dell'esecuzione del programma (come nei linguaggi del documento).

In tutti i casi c'è un componente HSA detto "finalizer" che converte le parti in HSAIL in un binario eseguibile dal coprocessore specifico (GPU o altro), o a monte (quindi il programma conterrà binari di vario tipo per i vari coprocessori supportati), o a valle (quindi il programma o la parte HSAIL dello stesso viene compilata nel sistema bersaglio, così c'è solo il binario specifico per il suo coprocessore).

Each language also includes a "language runtime" that connects the language implementation to the HSA runtime. When the language compiler generates code for a parallel region, it will include calls to the HSA runtime to set up and dispatch the parallel region to the kernel agent. The language runtime is also responsible for initializing the HSA runtime, selecting target devices, creating execution queues, managing memory. The language runtime may use other HSA runtime features as well. A runtime implementation may provide optional extensions. Applications can query the runtime to determine which extensions are available. This document describes the extensions for Finalization, Linking, and Images.

Questo blabla dice che per ogni linguaggio supportato c'è un modulo del runtime HSA che gestisce il fatto che il programma giri in parte sulla CPU e in parte sulla GPU/coprocessore di calcolo parallelo.

Visto che questo sistema spezza il programma in parti per la CPU e parti per la GPU/coprocessore, bisogna che comunque ste parti si parlino.

The API for the HSA runtime is standard across all HSA vendors. This means that languages that use the HSA runtime can execute on different vendors’ platforms that support the API. Each vendor is responsible for supplying their own HSA runtime implementation that supports all of the kernel agents in the vendor’s platform. HSA does not provide a mechanism to combine runtimes from different vendors. The implementation of the HSA runtime may include kernel-level components (required for some hardware components) or may only include user-space components (for example, simulators or CPU implementations).

Qui dice che l'API è standard (ma grazie al...) e che ogni produttore è responsabile della creazione e distribuzione del HSA runtime in tutte le piattaforme che decide di supportare.

Quindi di fatto questa parte funziona come OpenGL/DX/eccetera. Ogni produttore si fa i suoi "driver" (di fatto tutta sta roba sono componenti del pacchetto driver) come gli pare dove ottimizza l'esecuzione del HSAIL per girare sul suo prodotto.

Quindi ci saranno SoC certificati HSA 1.0, HSA 1.1, HSA 1.2, eccetera.

[bobafetthotmail]

Sì. Semplificando ulteriormente, tutto il sistema HSA si basa sulla ottimizzazione software degli ottimizzatori software che ottimizzano il software.

Quello che fa o disfa tutta la baracca sono i compilatori e i driver che gestiscono lo smazzamento grosso.

Quindi può benissimo essere (anzi mi aspetto che sia così) che certi produttori dimmerda tipo Imagination Tecnologies o Mediatek (che fanno parte della fondazione ma credo solo per sbaglio, dovevano restare coi loro amichetti Allwinner e Rockchip) facciano dei driver HSA scarsi o non li aggiornino neanche dietro minaccia, mentre AMD tanto per cambiare ha messo tutto open per linux (ovviamente per le sue APU) sperando nell'assistenza di terzi che li hanno già aiutati parecchio per i loro driver video open.

Magari certi linguaggi non renderanno bene come altri con HSA perchè i compilatori HSA-aware per quel linguaggio fanno pena. O non si potranno usare perchè non ci sono proprio compilatori HSA-aware per quel linguaggio.

Ma se continuano di questo passo dovrebbe essere pronta allo scontro con Intel e NVIDIA per quando lanciano Zen.

[cdimauro]

Originariamente inviato da Bivvoz

Non ci crederai ma ho letto tutto o quasi

Il succo è che HSA foundation sta facendo il possibile perchè scrivere un software compatibile con HSA sia semplice e non richieda molte conoscenze extra.
Sembrerebbe che sia poco più che saper scrivere un programma che supporti il normale multithread.
Ovvio che se chi programma è un asino non è che viene automaticamente trasformato nel mago del software accelerato

Lo stesso vale per chi asino non è, perché l'accelerazione del software non è cosa facile, e anche usando l'HSA non c'è nessun "free lunch".

In particolare i DSP hanno architetture molto particolari, con set di istruzioni un po' diverse da quelle che si usano convenzionalmente, registri molto specializzati, e modalità d'indirizzamento altrettanto specializzate e/o complesse. Roba che già un compilatore per linguaggi comuni/mainstream ha difficoltà a generare codice "ottimizzato", per cui figuriamoci soluzioni come HSA (ma il discorso vale anche per OpenCL et similia).

La cosa positiva di strumenti come questi è che consentono di sfruttare più facilmente la parallelizzazione del codice, ma questo non significa che si riesca a sfruttare bene l'hardware.