Source Engine 2 girerà su Vulkan

Source Engine 2 girerà su Vulkan

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

di pubblicata il , alle 16:01 nel canale Videogames
Steam
 

The Khronos Group ha rilasciato un video che mostra la presentazione fatta in occasione del SIGGRAPH 2015. Una presentazione che tocca diverse argomentazioni tecniche inerenti OpenGL, OpenGL ES e Vulkan, le API di basso livello che raccolgono il testimone delle OpenGL.

Al minuto 57 si discute nello specifico di come Valve abbia contribuito alla nascita e allo sviluppo di Vulkan, mentre AMD ha fornito parte della sua tecnologia Mantle. Vulkan, come precedentemente noto, è derivato da e costruito su componenti Mantle di AMD.

A 1:41, invece, Dan Ginsburg dettaglia il supporto di Valve a Vulkan, dicendo che si è occupato personalmente del porting del Source Engine 2 per le nuove API e che Intel, AMD e NVIDIA hanno già fornito dei driver che consentono di far girare la beta del Source Engine 2 in versione Vulkan sui loro hardware.

Altri dettagli su Vulkan si trovano qui.

22 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Vul25 Settembre 2015, 16:32 #1
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.
Tedturb025 Settembre 2015, 16:51 #2
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..
metrino25 Settembre 2015, 16:53 #3
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.
Cfranco25 Settembre 2015, 23:43 #4
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
WarDuck26 Settembre 2015, 11:33 #5
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.
bobafetthotmail26 Settembre 2015, 14:18 #6
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.
pindol26 Settembre 2015, 16:00 #7
no ma aspettate un momento,

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

Pindol
bobafetthotmail26 Settembre 2015, 16:58 #8
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/...mmer-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.
pindol26 Settembre 2015, 17:06 #9
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/...mmer-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
WarDuck26 Settembre 2015, 18:39 #10
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.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^