Una breve panoramica dell'API Vulkan

Quindi, qual è il problema con questa nuova API Vulkan comunque, e perché dovrebbe interessarci?

Ecco l'API di Vulkan in un centinaio di parole o meno: è un'API a basso costo e vicina al metallo per la grafica 3D e le applicazioni di calcolo. Vulkan è fondamentalmente un seguito di OpenGL. Originariamente veniva chiamata "l'iniziativa OpenGL di nuova generazione" e include alcuni frammenti dell'API Mantle di AMD. Vulkan dovrebbe fornire numerosi vantaggi rispetto ad altre API GPU, consentendo un supporto multipiattaforma superiore, un supporto migliore per processori multithread, un carico della CPU inferiore e un pizzico di agnosticismo del sistema operativo. Dovrebbe inoltre semplificare lo sviluppo dei driver e consentire la precompilazione dei driver, incluso l'uso di shader scritti in vari linguaggi.

Sono 93 parole, quindi se non sei interessato, puoi saltare le successive 3.500. Se, d'altra parte, vuoi saperne di più sulla prossima API grafica che sarà con noi negli anni a venire, inizierò con le basi.

Come è nata l'API Vulkan

Vulkan è stato originariamente annunciato dal Gruppo Khronos nel marzo 2015, con una data di lancio provvisoria fissata per la fine del 2015. Nel caso non abbiate familiarità con Khronos, è un consorzio industriale senza scopo di lucro fondato quindici anni fa da alcuni dei più grandi nomi del grafica, tra cui ATI (ora parte di AMD), Nvidia, Intel, Silicon Graphics, Discrete e Sun Microsystems. Anche se non hai sentito parlare di Khronos, probabilmente hai sentito parlare di alcuni dei loro standard, come: OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA e glTF.

A questo punto, probabilmente stai pensando "Ah, sono quei ragazzi", quindi posso saltare il resto dell'introduzione e concentrarmi sull'API stessa.

A differenza del suo predecessore, o dei suoi predecessori, Vulkan è progettato da zero per funzionare su diverse piattaforme, che vanno da cellulari e tablet, a console di gioco e desktop di fascia alta. Il design alla base dell'API è a più livelli, o dovremmo dire modulare, quindi consente la creazione di un'architettura comune ma estensibile per la convalida del codice, il debug e la profilazione, senza influire sulle prestazioni. Krhonos afferma che l'approccio a più livelli fornirà molta più flessibilità, catalizzerà una forte innovazione negli strumenti GPU di diversi fornitori e fornirà un controllo GPU più diretto richiesto da sofisticati motori di gioco.

Ora, capisco che molti tecnofili hanno le loro riserve su termini di marketing come "flessibile", "estensibile" e "modulare", ma questa volta abbiamo a che fare con il vero McCoy. In effetti, questa è l'idea alla base di Vulkan: è concepita come un'API per le masse, dai bambini che giocano su smartphone, ai genitori che progettano edifici e giochi su workstation.

In teoria, Vulkan potrebbe essere utilizzato nell'hardware di elaborazione parallela, per controllare decine di miliardi di core GPU, in minuscoli dispositivi indossabili e droni giocattolo, in stampanti 3D, automobili, kit VR e praticamente qualsiasi altra cosa con una GPU compatibile all'interno.

Per maggiori dettagli, ti suggerisco di dare un'occhiata alla panoramica ufficiale di Vulkan in PDF.

DNA del mantello AMD

Se l'approccio quasi metallico suona stranamente familiare, potresti aver seguito gli annunci della GPU di AMD negli ultimi due anni circa. AMD ha sorpreso gli osservatori del settore quando ha annunciato la sua Mantle API nel 2013 e li ha sorpresi ancora una volta quando ha deciso di staccare la spina dall'API, annunciando a marzo 2015 che non avrebbe rilasciato Mantle 1.0 come SDK pubblico. In poche parole, Mantle ha promesso di fornire significativi miglioramenti delle prestazioni e dell'efficienza in alcune situazioni, specialmente sul fronte della CPU poiché ridurrebbe il sovraccarico di elaborazione. Sembrava una buona idea, dato che i giocatori potevano mettere insieme PC personalizzati con processori un po' più lenti e investire più soldi in schede grafiche di prim'ordine. Sembrava molto conveniente anche per AMD, perché l'azienda non disponeva di una CPU di fascia alta competitiva da anni, sebbene abbia ancora buoni prodotti GPU.

Mentre i fan di AMD piangenti si sono riuniti per piangere la morte del loro salvatore, Mantle è stato miracolosamente resuscitato. La buona notizia è arrivata sotto forma di un post sul blog, scritto da Raja Koduri, vicepresidente AMD di Visual and Perceptual Computing. Per coincidenza, in linea con il tema religioso, in un'occasione Koduri tenne un sermone su una cavalcatura, durante l'evento di lancio di AMD alle Hawaii nel 2013, ma sto divagando.

Scherzi a parte, la squadra di Koduri ha fatto un buon lavoro. Sebbene Mantle non sia diventato un nuovo standard del settore, è diventato una base per Vulkan. La differenza più grande è che Vulkan non sarà limitato all'hardware AMD GCN; funzionerà su molte più GPU di diversi fornitori. Probabilmente puoi vedere dove sto andando con questo; è un po' meglio avere una singola API grafica a basso sovraccarico che funzioni su diversi sistemi operativi e piattaforme hardware piuttosto che avere API proprietarie per diverse architetture GPU, sistemi operativi e così via.

L'API Vulkan prende semplicemente una buona fetta della torta Mantle e la condivide con tutti, indipendentemente dal sistema operativo, dall'hardware, dalla razza o dalla religione.

Oh, e c'è un'altra cosa: Mantle alla fine ha costretto Microsoft e Khronos a fare qualcosa per il gonfiore e l'inefficienza di DirectX e OpenGL. Era un calcio gentile e amichevole nel posteriore, o "badonkadonk", come ama definirlo un collega Toptaler.

Come si confronta Vulkan con OpenGL?

Ovviamente, ho bisogno di delineare le differenze di base tra Vulkan e OpenGL. Khronos ha fornito una semplice illustrazione, che mostra quanto gonfiamento del driver potrebbe essere eliminato con la nuova API.

Vulkan consente alle applicazioni di avvicinarsi al metal, eliminando così la necessità di molta memoria e gestione degli errori, oltre a molte sorgenti del linguaggio di ombreggiatura. I piloti saranno più leggeri, più snelli e più cattivi. Vulkan si baserà solo sul linguaggio intermedio SPIR-V e, poiché ha un'API unificata per i mercati mobile, desktop e console, dovrebbe anche ricevere un'attenzione più tenera e amorevole da parte degli sviluppatori.

Ma aspetta, questo non scarica semplicemente più lavoro agli sviluppatori di giochi? Certo, saranno in grado di utilizzare l'hardware in modo più efficiente, ma per quanto riguarda le proprie ore di lavoro? È qui che entra in gioco l'approccio ecosistemico a strati.

Gli sviluppatori potranno scegliere tre diversi livelli, o livelli, dell'ecosistema Vulkan.

• Usa Vulkan direttamente per la massima flessibilità e controllo.
• Usa le librerie e i livelli Vulkan per accelerare lo sviluppo.
• Usa Vulkan tramite motori di gioco standard completamente ottimizzati sulla nuova API.

La prima opzione chiaramente non sarà per tutti, ma sospetto che sarebbe un bel software di benchmarking. Khronos prevede che la seconda opzione sia una "ricca area per l'innovazione" perché molte utilità e livelli saranno open source e faciliteranno la transizione da OpenGL. Se un editore ha alcuni titoli OpenGL che necessitano di modifiche e aggiornamenti, questo è ciò che utilizzerebbe.

L'ultima opzione è, forse, la più allettante perché il sollevamento di carichi pesanti è stato svolto da pesi massimi del settore come Unity, Oxide, Blizzard, Epic, EA, Valve e altri.

Ecco una rapida tabella OpenGL vs. Vulkan:

Ad essere onesti, non credo sia nemmeno giusto confrontare i due. Vulkan è un derivato di Mantle, mentre OpenGL è un mastodonte con 20 anni di bagaglio. Vulkan dovrebbe abbandonare un sacco di cose legacy; questo è il punto. Vulkan dovrebbe semplificare i test e l'implementazione, rendere i driver più snelli e migliorare la portabilità del programma shader tramite il linguaggio intermedio SPIR-V.

Questo ci porta alla prossima domanda. Cosa significa veramente Vulkan per gli sviluppatori?

SPIR-V dovrebbe trasformare l'ecosistema linguistico

Allora, dove entra in gioco SPIR-V e cosa succede al buon vecchio GLSL?

GSLS rimarrà attivo per ora e sarà il primo linguaggio di ombreggiatura supportato da Vulkan. Un traduttore da GLSL a SPIR-V farà il lavoro pesante e voilà!, otterrai SPIR-V pronto per alimentare l'affamato runtime Vulkan. Gli sviluppatori di giochi saranno in grado di utilizzare back-end SPIR-V e Vulkan, probabilmente facendo affidamento su front-end di compilatori open source. Oltre a GLSL, Vulkan può supportare i kernel C OpenCL, mentre il lavoro sull'aggiunta del supporto per C++ sta procedendo. Un'altra opzione sono linguaggi, framework e strumenti specifici del dominio. Khronos accenna anche alla possibilità di sviluppare nuovi linguaggi sperimentali.

Qualunque cosa gli sviluppatori scelgano di fare, tutte le strade portano a Vulkan, tramite SPIR-V, e quindi a una moltitudine di dispositivi diversi.

SPIR-V dovrebbe migliorare la portabilità in tre modi:

• Strumenti condivisi
• Set di strumenti unico per un unico ISV
• Semplicità

Dal momento che non sarà necessario che ogni piattaforma hardware includa un traduttore di lingue di alto livello, gli sviluppatori si occuperanno di meno di loro.

Un singolo ISV può generare SPIR-V utilizzando un unico set di strumenti, eliminando così i problemi di portabilità del linguaggio di alto livello.

SPIR-V è più semplice di un tipico linguaggio di alto livello, semplificando l'implementazione e l'elaborazione.

Le prestazioni saranno migliorate in diversi modi, a seconda di come viene implementato Vulkan:

• Niente più front-end del compilatore, molte elaborazioni possono essere eseguite offline
• I passaggi di ottimizzazione possono essere stabiliti più velocemente, le ottimizzazioni eseguite offline
• Più shader sorgente si riducono allo stesso flusso di istruzioni linguistiche intermedie

Khronos non specifica alcun numero di prestazioni e osserva che "il chilometraggio varierà sicuramente". Tutto dipenderà da come viene utilizzato Vulkan. Se vuoi controllare i dettagli grintosi, assicurati di controllare il white paper SPIR-V.

Vulkan sembra promettente dal punto di vista dello sviluppatore

Ho delineato una serie di caratteristiche che dovrebbero rendere Vulkan e SPIR-V popolari nella comunità degli sviluppatori, e anche Khronos è desideroso di chiarire questo punto. La prospettiva di utilizzare gli stessi strumenti e le stesse competenze per lo sviluppo per più piattaforme appare intrigante, soprattutto ora che il divario di prestazioni tra le varie piattaforme si sta riducendo.

Naturalmente, lo sviluppo di un gioco AAA ad alto budget per PC rimarrà un processo estremamente complesso e dispendioso in termini di tempo, che coinvolge un sacco di denaro e risorse umane, ma le piattaforme mobili e le GPU integrate impiegate nei più recenti processori Intel e AMD offrono già molto Prestazioni della GPU per il giocatore occasionale. Inoltre, è più probabile che piccoli sviluppatori indipendenti o liberi professionisti lavorino su giochi casual multipiattaforma rispetto ai titoli AAA sfornati dai principali editori.

Khronos delinea i seguenti vantaggi resi possibili da SPIR-V:

• Gli sviluppatori possono utilizzare lo stesso compilatore front-end su più piattaforme per eliminare i problemi di portabilità tra fornitori
• Il tempo di compilazione dello shader/kernel di runtime sarà ridotto poiché il driver deve elaborare solo SPIR-V
• Gli sviluppatori non devono distribuire codice sorgente shader/kernel, quindi godono di un ulteriore livello di protezione IP
• I driver sono più semplici e affidabili poiché non è necessario includere compilatori front-end
• Gli sviluppatori hanno un quadro migliore dell'allocazione della memoria e possono modificare di conseguenza il loro approccio all'allocazione della memoria

Sono sicuro che sarai d'accordo sul fatto che questo suona bene, ma c'è ancora molta strada da fare.

Vulkan: Funziona, ma è un lavoro in corso

Come ho detto, Vulkan è ancora praticamente un work in progress e dovremmo avere le specifiche complete entro la fine dell'anno. Tuttavia, da quanto visto finora, la nuova API può sbloccare molte prestazioni anche con hardware di attuale generazione.

La migliore illustrazione di Vulkan che ho visto finora proviene da Imagination Technologies, uno dei principali gruppi di GPU mobili in circolazione. L'IP della GPU di Imagination Technologies viene utilizzato in tutti i gadget iOS, insieme a numerosi altri design System-on-Chip basati su ARM e persino in alcuni chip Intel x86 a bassa tensione.

La scorsa settimana Imagination ha pubblicato un post sul blog che descrive in dettaglio i miglioramenti delle prestazioni resi possibili da Vulkan. La scelta dell'hardware è stata alquanto insolita: un Google Nexus Player, basato su un processore Intel quad-core usato raramente con GPU PowerVR G6430. Il dispositivo è stato testato con l'ultimo driver API Vulkan per GPU PowerVR, mentre la corsa di riferimento è stata eseguita su OpenGL ES 3.0. Il divario di prestazioni era a dir poco sbalorditivo.

La scena comprende un totale di 400.000 oggetti, con diversi livelli di dettaglio, che vanno da 13.000 a 300 vertici. L'inquadratura ampia mostra circa un milione di triangoli, alcuni alfa sulle piante e una decina di diverse trame per gli gnomi e le piante. Ogni tipo di oggetto utilizza uno shader diverso e gli gnomi non sono istanziati, ogni chiamata di disegno potrebbe essere un oggetto completamente diverso, con materiali diversi, ma il risultato finale sarebbe simile.

Tuttavia, c'è un grande avvertimento: questo non è il tipo di aumento delle prestazioni che puoi aspettarti nella vita reale. Il team di Imagination Technologies ha utilizzato uno scenario esagerato per evidenziare la superiorità di Vulkan, per spingerlo al limite, e in questo particolare scenario il limite è a favore di Vulkan vs. OpenGL ES. Inoltre, tieni presente che questo test è legato alla GPU , ma è comunque una buona illustrazione dell'utilizzo superiore della CPU di Vulkan.

In che modo Vulkan riduce l'utilizzo della CPU?

Ricordi quella tabella OpenGL vs. Vulkan che avevamo in precedenza, o per essere più specifici, quel bit di rendering piastrellato ? Probabilmente no, quindi eccolo qui, in poche parole: Imagination ha usato Vulkan per disegnare in batch le chiamate nelle tessere e renderizzare una tessera alla volta. A seconda di dove si trova la tessera nel momento in cui viene renderizzata la cornice, può entrare o uscire dalla vista, cambiare il suo livello di dettaglio e così via. In OpenGL ES, tutte le chiamate di estrazione sono dinamiche, vengono inviate con ogni frame, in base a ciò che si trova nel campo visivo. Le chiamate Draw che sono già state eseguite non possono essere memorizzate nella cache.

Di conseguenza, OpenGL ES necessita di molte chiamate in modalità kernel per modificare lo stato del driver e convalidarlo. Vulkan non lo fa perché si basa su comandi pregenerati (buffer di comando) per ridurre il sovraccarico della CPU ed eliminare la necessità di convalidare o compilare durante il ciclo di rendering. Il team di Imagination ha descritto la capacità di riutilizzare i buffer dei comandi come "utile in alcune circostanze" e possibile utilizzarla "in larga misura" in molti giochi e applicazioni.

Il secondo punto di svolta è la generazione di buffer paralleli , che consente a Vulkan di sfruttare la potenza di tutti i core della CPU. OpenGL ES è stato progettato prima dell'avvento dei chip mobili multi-core, ma negli ultimi tre anni il settore è passato da due, quattro, otto e dieci core di CPU, con i SoC serie A di Apple e Nvidia Tegra con sede a Denver chip come le uniche eccezioni degne di nota. Ho parlato delle tendenze del SoC mobile in uno dei miei precedenti articoli sul blog, che trattava del prossimo compilatore Optimizing Android, quindi puoi dare un'occhiata per ulteriori informazioni.

Proviamo un'analogia: se Vulkan fosse un motore a combustione interna, stoccherebbe e riutilizzerebbe parte della sua potenza, più o meno allo stesso modo in cui farebbero un turbocompressore e un intercooler (tamponi di comando), e sarebbe in grado di usarne quattro, sei, otto o anche dieci cilindri senza perdita di efficienza (generazione parallela di accumulo). Confrontare Vulkan con OpenGL ES suona un po' come confrontare un nuovo motore turbo ridimensionato con un vecchio motore monocilindrico sul Triumph Trophy di tuo nonno.

Beh, almeno il nonno era un vero rocker, non un mod.

Il risultato finale è un ambiente molto più efficiente, in grado di fare buon uso di tutto l'hardware disponibile, a differenza di OpenGL ES, che è vincolato alla CPU nella maggior parte degli scenari. Ciò significa che Vulkan può fornire livelli di prestazioni simili mantenendo la CPU a clock inferiori, riducendo così il consumo energetico e il throttling.

Potenziali svantaggi dell'API Vulkan (avviso spoiler: non ce ne sono molti)

Non sono pignolo; Ritengo sia anche importante elencare i pro ei contro dell'API Vulkan. Fortunatamente, non ci sono molti contro a parte alcuni piccoli e, potenzialmente, uno o due grandi. Se pensi che Vulkan sia la cosa migliore dopo il pane a fette e non vedi l'ora di provarlo nel tuo prossimo progetto, potresti prendere in considerazione alcuni di questi punti:

• Aggiunta complessità del codice in determinati scenari
• Time-to-Market
• Livello di supporto del settore
• Vulkan potrebbe non essere così rilevante o efficace su alcune piattaforme (desktop)
• Convincere gli sviluppatori a utilizzare Vulkan su alcune piattaforme
• Compatibilità limitata con hardware legacy

Se uno sviluppatore vuole implementare alcune delle funzionalità descritte in questo post, comporterà una discreta quantità di lavoro. Ciascuno dovrà essere implementato nel codice, ma la buona notizia è che i leader del settore renderanno il processo più semplice con gli aggiornamenti dei nuovi driver.

Il time-to-market è un'altra preoccupazione, così come l'implementazione di Vulkan in app e giochi meno recenti. Vulkan è ancora un'anteprima tecnica; le specifiche e le implementazioni iniziali sono previste entro la fine del 2015, quindi, realisticamente, probabilmente non vedremo molte applicazioni reali prima della metà del 2016.

Il supporto dell'industria non dovrebbe essere un problema; Dopotutto, questo è uno standard Khronos, ma potrebbe volerci un po'. Questo è uno dei motivi per cui ho concentrato questo post sul segmento mobile; Il software e l'hardware mobili si evolvono più rapidamente e potrebbero essere necessari alcuni altri trimestri prima che Vulkan abbia un impatto sulle piattaforme desktop. È così che funziona l'industria, ci sono molte più cose di cui preoccuparsi nella nicchia dei desktop: supporto per applicazioni professionali, orde di giocatori armati di forconi che scimmiottano su ogni fotogramma strappato e così via. Tuttavia, il fatto che Vulkan sia derivato da Mantle di AMD è incoraggiante.

Sebbene Vulkan possa fare miracoli in un ambiente vincolato alla CPU, in particolare con SoC mobili multi-core, questi miglioramenti delle prestazioni saranno limitati sulle piattaforme desktop. I desktop gestiscono processori multi-core con un livello di efficienza maggiore e le applicazioni graficamente più esigenti sono legate alla GPU.

Fino a quando tutti i pezzi del puzzle non andranno a posto, alcuni sviluppatori potrebbero essere riluttanti a fare il grande passo e a scherzare con Vulkan. Molte persone semplicemente non hanno tempo per sperimentare e imparano nuove abilità solo quando assolutamente necessario. Bruciare un sacco di soldi e sprecare ore di lavoro per modificare i giochi mobili esistenti per utilizzare Vulkan in questa fase iniziale non sarà un'opzione per molti sviluppatori ed editori.

La compatibilità con hardware meno recente potrebbe essere un'altra fonte di preoccupazione. Vulkan avrà bisogno dell'hardware OpenGL ES 3.1 o OpenGL 4.1, accompagnato da nuovi driver. Ad esempio, le GPU PowerVR serie 6 di Imagination Technologies possono supportarlo, ma la serie 5 no. La serie Adreno 400 di Qualcomm supporta OpenGL ES 3.1, ma la serie 300 no. Le serie ARM Mali T600 e T700 supportano OpenGL ES 3.1, ma manca il supporto sui modelli della serie T400 precedenti. Fortunatamente, quando Vulkan diventerà rilevante, la maggior parte dei dispositivi con GPU non supportate sarà fuori gioco. Questi includono iPhone 5/5C, iPad di quarta generazione e dispositivi Samsung basati su alcuni chip Exynos della serie 5000. I dispositivi basati su Qualcomm potrebbero non essere così fortunati poiché le GPU della serie Adreno 300 sono utilizzate su design relativamente recenti e prolifici come Snapdragon 410, Snapdragon 600, Snapdragon 800 e 801. Tuttavia, sospetto che la maggior parte di loro se ne sarà andata prima del tempo Vulkan diventa davvero rilevante.

Vivi a lungo e rendi

È ancora troppo presto per dire se Vulkan cambierà le regole del gioco, ma penso che sarai d'accordo sul fatto che ha un sacco di potenziale. Penso che sarà un grosso problema e baso questa ipotesi su un decennio di esperienza nel settore delle GPU. Ci vorrà del tempo, tuttavia, e sospetto che Vulkan farà sentire la sua presenza sui dispositivi mobili prima che inizi a cambiare il panorama del desktop.

Più o meno allo stesso tempo, driver, motori di gioco e giochi ottimizzati per Vulkan, avremo un nuovo hardware con cui giocare, e non intendo solo piccole modifiche hardware. Lo sviluppo del SoC mobile si è bloccato per una serie di motivi di cui non parlerò ora, ma il 2016 sarà un grande anno per il settore, poiché i nodi FinFET a 14/16 nm diventeranno disponibili per più produttori e diventeranno economicamente sostenibili per l'hardware tradizionale piuttosto che chip di punta.

Gli sviluppatori avranno a disposizione hardware molto più potente ed efficiente con cui giocare e una nuova API grafica a basso costo sarà la ciliegina sulla torta. Spero sinceramente che i fornitori di hardware smettano di utilizzare la risoluzione del display come espediente di marketing, poiché risoluzioni inutilmente elevate non fanno nulla per la qualità visiva ma sprecano comunque energia. Sfortunatamente, dal momento che il consumatore medio non lo ottiene e vuole vedere numeri più grandi sulla scatola, sospetto che ciò non accadrà presto. Ho intenzione di esaminare questo strano problema in uno dei miei prossimi post, quindi se ne sei infastidito, resta sintonizzato e sentiti libero di sfogarti nella sezione commenti.