Source Engine 2 girerà su Vulkan

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

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.


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.

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

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?pa...ulkan&num=1

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

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.

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.

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.

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.


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.

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.

[I]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.[/I]

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.

[I]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.[/I]

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.

[I]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.[/I]

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

[I]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.[/I]

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.

[I]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).[/I]

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.

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.

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.

Nono, questo è e resta.

L'ottimizzazione (di un compilatore o di un software) è bravura di un essere umano, la bravura non sempre si può comprare.

Sicuramente se non la paghi non la ottieni, MA anche pagando strafottii non c'è nessuna sicurezza di ottenerla.

Questo è il punto che tutti cercavano di evitare. Il rischio di pagare per un pugno di mosche.

E comunque, in ambito ARM il HSA è IL futuro, punto, quindi "non se lo inculano" solo nei PC.
Praticamente tutti nel mondo ARM stanno contribuendo alla fondazione e facendo roba certificata HSA.

HSA tenta di aggirare il problema dei compilatori dei vari linguaggi dando un target comune, cioè "linguagiio a caso"---> HSAIL, che poi viene ricompilato-ottimizzato HSAIL --> binario specifico per l'acceleratore specifico, da moduli del "finalizer HSA" (che è un compilatore), che sono prodotti dal produttore del dispositivo.
Che così può usare tutte le conoscenze possibili nel suo piccolo compilatore senza rischi di perdere IP o dover fare per forza un sistema open per permettere a compilatori di terze parti di gestire la cosa.

Ho il sospetto di essere nella lista ignore di cdimauro, se non reagisce a questo post puoi diglielo tu (Bivvoz o lettore a caso)? Magari anche di leggersi il post sopra dove copio dalla documentazione.

Perchè anche se è un pò un fanboy Intel, lui è effettivamente qualificato nel'ambito e i suoi commenti se entra nel merito e non è troppo di parte possono essere interessanti.