AMD Asynchronous Shaders: più efficienza alle GPU

OK, ma partiamo dal presupposto che la cosa migliore per tutti è avere una libreria standard gestita da ente indipendente a cui i produttori adeguano le proprie GPU.
Perchè se poi ognuno fa la sua si torna ai tempi delle 3dfx in cui ogni gioco doveva essere rivisto per ogni scheda grafica, e se invece la libreria la gestisce uno solo poi finisce che va ad intralciare l'altro.

Il top del top sarebbe che a comandare fosse opengl.
E ogni gioco dovrebbe pagare una minima percentuale a copia come royalty ad openGL per garantire fondi per sviluppo e supporto.

ma siete sicuri che mantle e dx12 siano imparentati? a quanto leggo su wiki i due progetti sono separati, fatti in tempi diversi e da team diversi, hanno in comune solo gli obiettivi, ma allora anche opengl si è mossa per diminuire l'overhead della cpu ma non per questo ha copiato a dx12 o mantle...

E le glide sono la base di mantle?

Ragazzi, Non scordiamoci che le console sono due, e una di essa non userà certamente le dx12. Quindi userà mantle.

anche questo è vero! non ci pensavo.

Vulkan arriva in aiuto: non è limitato a una certa piattaforma (D3D su Windows/XBox), non è limitato dall'architettura (Mantle su AMD), e scala dai desktop ai dispositivi embedded (sostituendo in un sol colpo sia OpenGL che OpenGL ES).



Il dover pagare delle royalties sarebbe controproducente, in quanto verrebbe a mancare il fatto di essere lo standard "free" per eccellenza (senza contare che quasi sicuramente ucciderebbe implementazioni open-source/free-software come Mesa).
E comunque non è necessario: Khronos Group (l'ente che standardizza OpenGL/OpenCL/Vulkan e altra roba) è formato da grosse aziende del settore, quindi i soldi non mancano:
https://www.khronos.org/about

Se i soldi non mancano ottimo, avevo pensato alla cosa delle royalties perchè un progetto che va avanti a donazioni non riuscirebbe ad essere competitivo..

Vulkan sembra essere una ottima evoluzione, resta però il problema principale: farlo preferire ale DX12.. purtroppo questo è un problema di non facile soluzione..

L'idea di avere una sola API scalabile da sistemi desktop a sistemi embedded (oggiogiorno le gpu di smartphone e tablet hanno architetture simili alle gpu desktop) è sicuramente una gran furbata, in quanto uno sviluppatore che impara Vulkan è capace di realizzare programmi per una vasta gamma di dispositivi, ed è anche più facile riutilizzare librerie e/o motori grafici.

Comunque, alla fine, l'API è in gran parte irrilevante: tutti i moderni motori grafici supportano tranquillamente una vasta gamma di API, e considerando che le nuove API (D3D12, Vulkan, Metal e Mantle) sono praticamente tutte uguali tra di loro (cambia un po' la terminologia di ognuna, ma sono tutte basate sul concetto di Execution Queue e Command Buffers, più gestione manuale della memoria), i wrapper specifici per ogni API sono sempre più ridotti.

Valve probabilmente sarà la compagnia che spingerà più possibile all'uso di Vulkan, sopratutto considerando la loro spinta verso le Steam Machines e SteamOS: stanno già provvedendo a realizzare un debugger per il codice grafico, e hanno incaricato una compagnia di scrivere un driver Linux dimostrativo per le GPU Intel, in modo da aiutare gli sviluppatori il più possibile quando uscirà la specifica definitiva. Hanno pure confermato che Source 2 supporterà Vulkan di default.

Le consolle usano già API di questo tipo. All'uscita di Mantle AMD ha dichiarato di essersi ispirata alle consolle per portare questo tipo di ottimizzazione su PC.
Le DX12, su XboX, non avranno certo la stessa incidenza che avranno su PC.

certo ,lo standard e più facile su di esse ,visto che sono tutte uguali .(hardware).