Khronos Group annuncia Vulkan: successore di OpenGL

[Z80Fan]

• 

Khronos Group, ente standardizzatore di varie tecnologie come OpenGL e OpenCL, annuncia oggi Vulkan, una nuova API per grafica 3D ad alte prestazioni.

Precedentemente conosciuta con il nome in codice glNext, Vulkan si pone come successore di OpenGL per programmi di grafica tridimensionale come videogiochi, programmi CAD, simulazioni etc.

Punto di forza di questa nuova API, così come le recenti tecnologie DirectX 12 di Microsoft, Mantle di AMD e Metal di Apple, è l'accesso diretto all'hardware di accelerazione grafica (GPU), in modo da utilizzare efficientemente le caratteristiche hardware dei dispositivi di più nuova generazione.
Vulkan si posiziona come tecnologia scalabile da dispositivi portatili (smartphone, tablet etc, occupando il posto di OpenGL ES), a console da gioco, fino a workstation grafiche e rendering farm.

Vulkan non sostituirà completamente OpenGL e OpenGL ES; queste API continueranno ad essere sviluppate in parallelo, principalmente per retrocompatibilità con vecchi programmi.

Assieme a Vulkan, Khronos annuncia anche OpenCL 2.1, famosa API per la programmazione parallela; caratteristica importante di questa versione è l'uso del nuovo "bytecode" SPIR-V compatibile con Vulkan e l'introduzione del linguaggio C++ per la scrittura dei programmi paralleli.

Le specifiche tecniche di Vulkan e i manuali di programmazione non sono ancora disponibili; il primo rilascio (assieme ai primi driver che la supporteranno) è previsto per l'anno corrente.

Più informazioni su Vulkan si avranno al GDC 2015, con conferenze programmate per il 4 e 5 Marzo.

Fonti:
https://www.khronos.org/vulkan
http://www.anandtech.com/show/9038/next-generation-opengl-becomes-vulkan-additional-details-released

[Z80Fan]

• 

Imagination Technologies ha già un demo funzionante su Vulkan per le sue GPU PowerVR:

http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus

Posso dire che il futuro è assai interessante!

[saimon69]

• 

meglio che dai un occhio alla pic, non viene linkata nella home non so perche'

[Z80Fan]

• 

meglio che dai un occhio alla pic, non viene linkata nella home non so perche'

Mi ero accorto, ma visto che non vedevo altre immagini pensavo fossero state disabilitate per le news.
Ho cambiato immagine (è presa da Anandtech) e ora funziona; probabilmente era bloccato via referer.

[Amig4be]

• 

interessante 

Dovrebbe riguardare più che altro i giochi a quanto ho capito

[Z80Fan]

• 

Al momento è sicuramente l'obiettivo principale, assieme a DirectX 12, Mantle e Metal, ma questo non preclude altri usi.

La caratteristica principale di Vulkan (e le altre) è che il lavoro del driver è drasticamente ridotto, e l'api stessa espone funzioni di più basso livello, principalmente per adattarsi meglio alle moderne architetture.

Per farti un esempio stupido: se in OpenGL quando tu vuoi una texture, tu gli dici "fammi una texture con il formato Z, larghezza W e altezza H", in Vulkan (probabilmente) lui ti dice "la vram è questa: arrangiati".
Da un lato è più difficile (relativamente) da usare, ma dall'altro permette di gestire esplicitamente e efficientemente tutte le risorse della GPU, cosa che gli sviluppatori chiedevano da tempo (perchè tanto i moderni engine già fanno le cose come la gestione della memoria, quindi conviene toglierle dal driver e farle fare direttamente all'applicazione).


Questa nuova architettura permette di aumentare considerevolmente il numero di comandi che possono essere inviati alla GPU (perchè il driver non deve fare complesse operazioni per ogni comando), e in più permette a più thread della CPU di comandare la GPU, migliorando il parallellismo.

Nei giochi a ogni frame vengono eseguiti tantissimi comandi di cambiamento di stato (texture, buffer etc), e quindi queste API permettono un incremento prestazionale in scene complesse. Negli altri software come i CAD, di solito non vengono usate tante texture o shader strani, quindi ci sono meno cambiamenti di stato, e probabilmente non avranno tali benefici (c'è anche da dire che i CAD hanno architetture grafiche dell'anteguerra, quindi chissà cosa possono fare ammodernando i loro engine).

[TheKaneB]

• 

Promette bene: http://en.wikipedia.org/wiki/M61_Vulcan

 

[Z80Fan]

• 

È uscito il video della seconda presentazione che è stata data al GDC su Vulkan:
https://www.youtube.com/watch?v=qKbtrVEhaw8

Qui le diapositive della presentazione:
https://www.khronos.org/assets/uploads/developers/library/2015-gdc/Khronos-Vulkan-GDC_Mar15.pdf


Il video della prima presentazione (presentata da Valve e altri) non è ancora disponibile, però ci sono le diapositive:
https://www.khronos.org/assets/uploads/developers/library/2015-gdc/Valve-Vulkan-Session-GDC_Mar15.pdf


C'è anche una presentazione su OpenCL 2.1:
https://www.youtube.com/watch?v=ez18sOaR748

e diapositive:
https://www.khronos.org/assets/uploads/developers/library/2015-gdc/Khronos-OpenCL-GDC_Mar15.pdf

[Z80Fan]

• 

Buone notizie!

Oggi AMD ha rilasciato la documentazione ufficiale di Mantle, in un bel PDF di 435 pagine. La notizia è doppiamente interessante sopratutto perchè Vulkan, a detta di Khronos stessa, è pesantemente basata su Mantle, quindi possiamo usare questa documentazione come una descrizione di massima anche della nuova API.

Notizia su Anandtech
Link al PDF (2 MB)

[TheKaneB]

• 

Si ritorna quindi a programmare grafica sul low level
Chi sviluppa engine ne sarà soddisfatto

[Z80Fan]

• 

Più che altro non ci sarà più l'API "di mezzo" a rompere le balle: Vulkan/D3D12/Mantle/Metal etc. in realtà sono allo stesso "livello" di quello che già si fa ora con D3D11/OpenGL 4 nei motori moderni, perchè ormai le cose "di alto livello" lavorano contro il controllo che si vorrebbe avere, obbligando ad attuare molti work-around (tipo invece che far allocare i vari buffer all'API, si crea un buffer enorme e poi lo si seziona manualmente).

Io prevedo che, passando ad esempio da OpenGL a Vulkan, un engine moderno avrà più o meno la stessa struttura, ma molte meno linee di codice in quanto prima di tutto si può togliere tutto il boilerplate code necessario a star dietro alle strambezze dell'API (ad esempio in OpenGL bisogna star dietro allo stato globale e stare attenti che non si sporchi troppo), e secondo si può fare a meno di tanti di quei salti mortali che si dovevano fare prima per minimizzare le draw call e i cambi di contesto (con la scusa di avere i Command Buffer che si creano prima, invece che dover dare i comandi uno dietro l'altro dalla CPU), andando al contempo a migliorare la qualità del codice stesso (perchè lo si può scrivere in modo più "naturale" invece che nello stile che più piace all'API).

Insomma, livello basso ma neanche troppo.

Ovviamente non serve dire che non vedo l'ora che esca la documentazione ufficiale e i primi driver compatibili!

[TheKaneB]

• 

A me piaceva molto sviluppare sul DS dove praticamente avevi pieno controllo a livello di singolo registro hardware. Complesso, ma molto soddisfacente