I nuovi programmatori grafici dovrebbero imparare Vulkan invece di OpenGL?

Dal wiki : "l'API Vulkan è stata inizialmente definita" l'iniziativa OpenGL di prossima generazione "da Khrono" e che è "uno sforzo di riprogettazione fondato per unificare OpenGL e OpenGL ES in un'unica API comune che non sarà retroattiva compatibile con le versioni OpenGL esistenti ".

Quindi quelli che ora stanno entrando nella programmazione grafica dovrebbero essere meglio serviti per imparare Vulkan invece di OpenGL? Sembra che serviranno allo stesso scopo.

Quasi!

Sembra un po 'come chiedere "I nuovi programmatori dovrebbero imparare il C ++ invece che il C" o "I nuovi artisti dovrebbero imparare la pittura digitale invece della pittura fisica".

Soprattutto perché NON è compatibile con le versioni precedenti, i programmatori grafici sarebbero folli escludere l'API grafica più comune nel settore, semplicemente perché ce n'è una nuova. Inoltre, OpenGL fa cose diverse in modo diverso. È del tutto possibile che una società scelga OpenGL su Vulkan, specialmente all'inizio del gioco, e che la società non sia interessata a qualcuno che non conosce OpenGL, indipendentemente dal fatto che sappia o meno Vulkan.

La specializzazione è raramente un'abilità commerciabile.

Per coloro che non hanno bisogno di commercializzare le loro competenze in quanto tali, come gli sviluppatori indipendenti, sarebbe ancora PIÙ sciocco rimuovere uno strumento dalla loro cassetta degli attrezzi. Uno sviluppatore indipendente dipende ancora di più dalla flessibilità e dalla possibilità di scegliere ciò che funziona, piuttosto che ciò che viene finanziato. La specializzazione in Vulkan limita solo le tue opzioni.

La specializzazione è raramente un paradigma efficiente.

Se stai iniziando ora e vuoi fare il lavoro con la GPU (invece di usare sempre un motore di gioco come Unity), dovresti assolutamente iniziare imparando Vulkan. Forse dovresti imparare anche GL in seguito, ma ci sono un paio di ragioni per pensare a Vulkan.

1. GL e GLES sono stati progettati molti anni fa, quando le GPU funzionavano in modo abbastanza diverso. (La differenza più ovvia è il richiamo in modalità immediata delle chiamate rispetto alla piastrellatura e alle code dei comandi.) GL ti incoraggia a pensare in uno stile in modalità immediata e ha un sacco di legacy legft. Vulkan offre modelli di programmazione molto più vicini al funzionamento delle GPU contemporanee, quindi se impari Vulkan, avrai una migliore comprensione di come funziona davvero la tecnologia e di ciò che è efficiente e ciò che è inefficiente. Vedo molte persone che hanno iniziato con GL o GLES e hanno subito cattive abitudini come emettere chiamate di disegno separate per oggetto invece di usare VBO o, peggio ancora, usando elenchi di visualizzazione. È difficile per i programmatori GL scoprire cosa non è più incoraggiato.

2. Passare da Vulkan a GL o GLES è molto più semplice che viceversa. Vulkan rende esplicite molte cose che erano nascoste o imprevedibili in GL, come il controllo della concorrenza, la condivisione e lo stato di rendering. Spinge molta complessità dal driver all'applicazione: ma facendo ciò, dà il controllo all'applicazione e rende più semplice ottenere prestazioni prevedibili e compatibilità tra i diversi fornitori di GPU. Se hai del codice che funziona in Vulkan, è piuttosto facile portarlo su GL o GLES, e finisci con qualcosa che usa buone abitudini GL / GLES. Se hai un codice che funziona in GL o GLES, devi quasi ricominciare per farlo funzionare in modo efficiente in Vulkan: specialmente se è stato scritto in uno stile legacy (vedi punto 1).

All'inizio ero preoccupato che Vulkan fosse molto più difficile da programmare e che, sebbene sarebbe stato OK per gli sviluppatori esperti di aziende più grandi, sarebbe stato un enorme ostacolo per gli indie e gli hobbisti. Ho posto questa domanda ad alcuni membri del gruppo di lavoro e mi hanno detto di avere alcuni punti dati delle persone con cui hanno parlato e che si sono già trasferiti a Vulkan. Queste persone vanno dagli sviluppatori di Epic che lavorano sull'integrazione UE4 agli sviluppatori di giochi hobbisti. La loro esperienza è stata che iniziare (ovvero avere un triangolo sullo schermo) ha comportato l'apprendimento di più concetti e un codice di targa più lungo, ma non è stato troppo complesso, nemmeno per le indie. Ma dopo essere arrivati ​​a quel punto, hanno trovato molto più semplice creare un'applicazione reale e spedibile, perché (a) il comportamento è molto più prevedibile tra le implementazioni di diversi fornitori e (b) arrivare a qualcosa che ha funzionato bene con tutti gli effetti attivati ​​non ha comportato altrettanti tentativi ed errori. Con queste esperienze di veri sviluppatori, mi hanno convinto che la programmazione contro Vulkan è praticabile anche per un principiante in grafica e che la complessità complessiva è minore una volta superato il tutorial e iniziando a creare demo o applicazioni che puoi dare ad altre persone.

Come altri hanno già detto: GL è disponibile su molte piattaforme, WebGL è un bel meccanismo di consegna, ci sono molti software esistenti che usano GL e ci sono molti datori di lavoro che assumono per quella competenza. Ci sarà nei prossimi anni, mentre Vulkan cresce e sviluppa un ecosistema. Per questi motivi, saresti sciocco escludere completamente l'apprendimento del GL. Tuttavia, avrai un tempo molto più facile con esso e diventerai un programmatore GL migliore (e un programmatore GPU migliore in generale), se inizi con qualcosa che ti aiuta a capire la GPU, invece di capire come hanno funzionato 20 anni fa.

Certo, c'è un'opzione in più. Non so se questo sia rilevante per te in particolare, ma penso che dovrei dirlo comunque per gli altri visitatori.

Per essere uno sviluppatore di giochi indie o un game designer o per fare esperienze VR, non è necessario imparare Vulkan o GL. Molte persone iniziano con un motore di gioco (Unity o UE4 sono popolari al momento). L'utilizzo di un motore del genere ti consentirà di concentrarti sull'esperienza che desideri creare, anziché sulla tecnologia che sta dietro. Nasconderà le differenze tra GL e Vulkan e non dovrai preoccuparti di quale sia supportato sulla tua piattaforma. Ti permetterà di conoscere le coordinate 3D, le trasformazioni, l'illuminazione e l'animazione senza dover affrontare tutti i dettagli grintosi contemporaneamente. Alcuni studi di gioco o VR funzionano solo su un motore e non hanno affatto un esperto GL a tempo pieno. Anche negli studi più grandi che scrivono i propri motori, le persone che fanno la programmazione grafica sono una minoranza,

Conoscere i dettagli di come interagire con una GPU è sicuramente un'abilità utile, che apprezzerà molti datori di lavoro, ma non dovresti avere la sensazione di dover imparare questo per entrare nella programmazione 3D; e anche se lo conosci, non sarà necessariamente qualcosa che usi ogni giorno.

L'apprendimento della programmazione grafica è molto più che l'apprendimento delle API. Si tratta di imparare come funziona la grafica. Trasformazioni di vertici, modelli di illuminazione, tecniche d'ombra, mappatura delle trame, rendering differito e così via. Questi non hanno assolutamente nulla a che fare con l'API che usi per implementarli.

Quindi la domanda è questa: vuoi imparare come usare un'API? O vuoi imparare la grafica ?

Per fare cose con grafica con accelerazione hardware, devi imparare come usare un'API per accedere a quell'hardware. Ma una volta che hai la possibilità di interfacciarti con il sistema, l'apprendimento della grafica smette di concentrarsi su ciò che l'API fa per te e si concentra invece su concetti grafici. Illuminazione, ombre, bump-mapping, ecc.

Se il tuo obiettivo è apprendere concetti grafici, il tempo che passi con l'API è il tempo che non stai impiegando per apprendere concetti grafici . Come compilare shader non ha nulla a che fare con la grafica. Né come inviare loro uniformi, come caricare i dati dei vertici nei buffer, ecc. Questi sono strumenti e strumenti importanti per fare grafica.

Ma in realtà non sono concetti grafici. Sono un mezzo per raggiungere un fine.

Ci vuole molto lavoro e apprendimento con Vulkan prima che tu possa arrivare al punto in cui sei pronto per iniziare ad apprendere concetti grafici. Il passaggio dei dati agli shader richiede una gestione esplicita della memoria e una sincronizzazione esplicita dell'accesso. E così via.

Al contrario, arrivare a quel punto con OpenGL richiede meno lavoro. E sì, sto parlando di OpenGL moderno, basato sul core-shader.

Basta confrontare ciò che serve per fare qualcosa di semplice come cancellare lo schermo. In Vulkan, questo richiede almeno una certa comprensione di un gran numero di concetti: buffer di comando, code dei dispositivi, oggetti di memoria, immagini e vari costrutti WSI.

In OpenGL ... è tre funzioni: glClearColor, glClear, e il buffer di swap chiamata specifico per la piattaforma. Se stai usando OpenGL più moderno, puoi ridurlo a due: glClearBufferuive scambiare i buffer. Non è necessario sapere cos'è un framebuffer o da dove provenga la sua immagine. Lo si cancella e si scambiano i buffer.

Poiché OpenGL nasconde molto da te, ci vuole molto meno sforzo per arrivare al punto in cui stai effettivamente imparando la grafica piuttosto che imparare l'interfaccia con l'hardware grafico.

Inoltre, OpenGL è un'API (relativamente) sicura. Genererà errori quando si fa qualcosa di sbagliato, di solito. Vulkan no. Mentre ci sono livelli di debug che puoi usare per aiutare, l'API principale Vulkan non ti dirà quasi nulla a meno che non ci sia un errore hardware. Se si fa qualcosa di sbagliato, è possibile ottenere il rendering di immondizia o crash della GPU.

Insieme alla complessità di Vulkan, diventa molto facile fare accidentalmente la cosa sbagliata. Dimenticare di impostare una trama nel giusto layout può funzionare in un'implementazione, ma non in un'altra. Dimenticare un punto di sincronismo può funzionare a volte, ma poi improvvisamente fallire per apparentemente senza motivo. E così via.

Detto questo, l'apprendimento della grafica è molto più che l'apprendimento delle tecniche grafiche. C'è un'area in particolare dove vince Vulkan.

Prestazioni grafiche .

Essere un programmatore di grafica 3D di solito richiede qualche idea su come ottimizzare il codice. Ed è qui che nascondere le informazioni di OpenGL e fare cose alle tue spalle diventa un problema.

Il modello di memoria OpenGL è sincrono. L'implementazione può emettere comandi in modo asincrono, a condizione che l'utente non sia in grado di distinguere. Quindi, se esegui il rendering su qualche immagine, quindi prova a leggere da essa, l'implementazione deve emettere un evento di sincronizzazione esplicita tra queste due attività.

Ma per ottenere prestazioni in OpenGL, devi sapere che le implementazioni lo fanno, in modo da poterlo evitare . Devi capire dove l'implementazione genera segretamente eventi di sincronizzazione e quindi riscrivere il codice per evitarli il più possibile. Ma l'API stessa non lo rende ovvio; devi aver acquisito questa conoscenza da qualche parte.

Con Vulkan ... sei tu quello che deve emettere quegli eventi di sincronizzazione. Pertanto, è necessario essere consapevoli del fatto che l'hardware non esegue i comandi in modo sincrono. Devi sapere quando devi emettere quegli eventi e quindi devi essere consapevole che probabilmente rallenteranno il tuo programma. Quindi fai tutto il possibile per evitarli.

Un'API esplicita come Vulkan ti obbliga a prendere questo tipo di decisioni sulle prestazioni. E quindi, se impari l'API Vulkan, hai già una buona idea di quali cose saranno lente e quali saranno veloci.

Se devi fare un po 'di lavoro con framebuffer che ti costringe a creare un nuovo renderpass ... le probabilità sono buone che questo sia più lento che se potessi inserirlo in un sottopasso separato di un renderpass. Ciò non significa che non puoi farlo, ma l'API ti informa in anticipo che potrebbe causare un problema di prestazioni.

In OpenGL, l'API in sostanza ti invita a modificare i tuoi allegati framebuffer, volenti o nolenti. Non ci sono indicazioni su quali cambiamenti saranno veloci o lenti.

Quindi, in tal caso, l'apprendimento di Vulkan può aiutarti a imparare meglio come rendere la grafica più veloce. E sicuramente ti aiuterà a ridurre il sovraccarico della CPU.

Ci vorrà ancora molto più tempo prima di arrivare al punto in cui è possibile apprendere le tecniche di rendering grafico.

L'appello principale di OpenGL (almeno per me) è che funziona su molte piattaforme. Attualmente, Vulkan non funziona su OSX e Apple ha un'API concorrente chiamata Metal. È molto probabile che ci vorrà del tempo prima che Apple supporti Vulkan e, quando lo fanno, il supporto Vulkan potrebbe arrivare solo al loro hardware più recente. OpenGL supporta già la maggior parte dell'hardware e continuerà a farlo.

Dipende da quello che vuoi fare. Se vuoi imparare la programmazione grafica solo per te stesso, non importa davvero cosa scegli.

Se stai pensando al lavoro professionale, consiglio Vulkan. È più vicino all'hardware e penso che la conoscenza di ciò che fa l'hardware sia importante per i programmatori grafici.

Vulkan è più vicino all'hardware perché OpenGL fa molte cose sotto il cofano che in Vulkan fai manualmente, come eseguire la coda di comandi. Anche la gestione della memoria dipende dall'applicazione e non dal driver. Devi preoccuparti di allocare memoria per uniforms(variabile che passi dalla CPU alla GPU), di rintracciarli. Hai più cose di cui preoccuparti, ma dà anche più libertà sull'uso della memoria. Può sembrare spaventoso e travolgente, ma in realtà non lo è. È solo la prossima API che devi imparare.

Comprendere queste cose aiuterà anche a capire come funziona la GPU. Cosa ti consentirà di fare alcune ottimizzazioni sia su Vulkan che su OpenGL.

E un'altra cosa che mi viene in mente, se stai iniziando a imparare la programmazione grafica probabilmente quando cerchi un lavoro come un Vulkan sarà più popolare (forse più popolare di OpenGL). Inoltre, per quanto ne so la maggior parte delle aziende che utilizzano alcune API grafiche ci scrivono le proprie funzioni, quindi c'è la possibilità che sul lavoro non si scriverà in OpenGL né in Vulkan ma la conoscenza della GPU sarà sempre utile.

Sono "impegnato nella" programmazione grafica da alcuni mesi.

In questo momento sono ancora al liceo e posso dirti che sto quasi sempre cercando di sviluppare applicazioni multipiattaforma. Questo è in effetti il ​​mio problema numero uno con Vulkan: non è sviluppato per funzionare su tutte le piattaforme. Lavoro con OpenGL in Java e lo faccio da oltre 6 mesi.

Un altro problema che ho riguarda le affermazioni di Vulkan è come afferma di essere migliore. Mentre OpenGL certamente non aggiorna il loro sito Web molto spesso. Continuano a rilasciare costantemente aggiornamenti e non vedo l'ora che arrivino nuovi aggiornamenti che funzionano più velocemente o funzionano meglio con il nuovo hardware.

Detto questo, mentre lavoro principalmente con OpenGL capisco i principi di base di DirectX e Vulkan. Anche se non lavoro ampiamente con loro, in particolare Vulkan in quanto è molto difficile da imparare e non ben strutturato per la programmazione come OpenGl e DirectX.

Infine, vorrei aggiungere che la specializzazione in un singolo campo come uso principalmente Java e OpenGL non è straordinariamente commerciabile standalone. Se volessi trovare un lavoro presso un'azienda che produceva giochi, per la maggior parte OpenGL sarebbe usato solo per creare giochi per lo sviluppo di Linux e Android e possibilmente OSX. DirectX per Windows e console <Che Vulkan può sostituire in alcuni casi.

Non posso resistere per sempre agli aggiornamenti di OpenGL e non lo farò. Ma è la mia preferenza per lo sviluppo.

Vorrei darti la mia prospettiva per principianti grafica sull'argomento. Quello che ho realizzato (in molti anni lavorando come ingegnere in un altro campo) è che i concetti fondamentali sono la parte più importante. Una volta che hai una solida conoscenza di questi, l'apprendimento dell'ultima brillante nuova API è la parte meno difficile. Non so se sei un giovane hobbiest che cerca di programmare il nuovo Skyrim o se stai cercando un lavoro nel campo CG.

Ti dico quello che penso sia l'approccio migliore secondo me per imparare la computer grafica "come un professionista".

1. Impara l'algebra lineare e la geometria come un professionista. Senza questo, dimentica qualsiasi API o grafica di fantasia
2. Acquista un buon libro sulla computer grafica (ad es. Fondamenti di computer grafica )
3. Mentre studi il libro, crea un ambiente di programmazione con qualcosa che ti permetta di disegnare su un'immagine e implementare gli algoritmi! Può essere Java 2D o C ++ e SDL o persino Python e Pygame per quello che conta. A questo punto devi mettere in moto le tue marce a rotazione con più viste della videocamera prima di provare a ottenere 10000 FPS
4. Ora prendi OpenGL, Vulkan o DirectX e ripeti il ​​tuo esempio di fantasia (vedi sopra).

Iniziare a preoccuparsi delle prestazioni prima di capire come disegnare una linea è come preoccuparsi dell'aerodinamica della tua auto prima di ottenere la patente di guida.

Sono autodidatta in C ++ senza alcuna istruzione formale e negli ultimi 15 anni ho imparato sia OpenGL 1.0 che Modern OpenGL e DirectX 9c, 10 e 11. Non sono entrato in DirectX 12 e volevo prova la mia mano a Vulkan. Ho completato solo alcuni tutorial di base per disegnare un semplice triangolo o un semplice cubo rotante con Vulkan. Come con DirectX 11 e OpenGL 3.3+, ho scritto motori di gioco 3D completamente funzionanti e li ho persino usati per costruire giochi semplici.

Devo dire che dipende dall'ambiente generale della persona che sta imparando. Se stai solo entrando nella programmazione grafica 3D, direi che i principianti possono saltare a OpenGL o DirectX 11 poiché ci sono molti tutorial, risorse, esempi e applicazioni già funzionanti. L'apprendimento della grafica 3D non è affatto un argomento facile.

Se ci allontaniamo dall'aspetto di programmazione di esso e ci concentriamo solo sulla nozione di quale tipo di tecniche vengono utilizzate coinvolgendo i diversi livelli di matematica che portano a set di dati e strutture e algoritmi di dati; c'è molto che devi sapere e capire prima di poter persino provare a costruire un Game Engine 3D o usarne uno esistente in modo efficace.

Ora, se capisci già tutta la matematica e la teoria alla base e hai qualche esperienza di programmazione, puoi utilizzare API, librerie e applicazioni già esistenti come Unity o Unreal Engine e scrivere semplicemente il codice sorgente e gli script necessari per far funzionare la tua applicazione .

Quindi dalla mia comprensione e dal modo in cui lo vedo è questo se stai cercando di costruire un gioco veloce solo per il gusto di costruirlo; andare con i frame già esistenti che renderebbero i tempi di produzione molto più piccoli. D'altra parte, se vuoi capire il funzionamento interno di come sono progettati i motori di gioco / motori di fisica / motori di animazione e simulatori e vuoi costruirne uno tu stesso, allora è qui che puoi scegliere tra scegliere la tua API come DirectX, OpenGL o Vulkan. Uno dei fattori determinanti qui sarebbe anche la tua conoscenza di programmazione esistente. Ciò che intendo con questo è se non sai nulla di chiamate multi-thread, sincrone vs asincrone, recinti di memoria, corse di dati, semafori e parallelismo (programmazione parallela),

Lo menziono perché se non sai come gestire correttamente la tua memoria insieme ai tuoi thread e ai tuoi tempi di accesso; Vulkan ti morderà il culo! Dove OpenGL e DirectX ti terranno la mano fino a consumare molta più potenza della CPU.

Ora, se il tuo livello di conoscenza della programmazione è decente e hai i seguenti background matematici che coinvolgono tutti i livelli di Algebra, Geometria, Trigonometria, Algebra booleana, Probabilità, Statistica, Vettore - Algebra basata su matrice, Calcolo I, II, .... Infinty (lol). Calcolo vettoriale, algebra lineare, sistemi di equazioni lineari, geometria analitica con calcolo vettoriale di calcoli multi-variabili, teoria dei numeri e dei set, set di dati e strutture, analisi computazionale, progettazione computazionale e algoritmica. Quindi puoi entrare nei concetti di ciò che serve per creare un vero motore di gioco e questo è senza alcuna matematica applicata o equazioni di fisica di cui avrai bisogno. Una volta che hai quel background e sufficiente esperienza di programmazione, in particolare la gestione della memoria e l'aritmetica del puntatore, puoi iniziare a costruire il tuo Game Engine.

Quindi la cosa qui è che devi capire tutti gli aspetti di ciò che serve per creare un Game Engine per fare una programmazione grafica avanzata. Se stai facendo solo grafica 2D, la vita non è troppo difficile come puoi farlo in Python senza nessuna delle API di cui sopra! Ma se vuoi essere serio e progettare un motore di gioco completo che sia robusto con molti set di funzionalità, la scelta qui sarebbe o C o C ++ e usando OpenGL, Direct X o Vulkan. Ognuno di loro andrebbe bene. Ora, se stai costruendo il motore da Scratch e stai cercando il motore in esecuzione più "efficiente" con la minima quantità di risorse generali, allora vorresti scegliere Vulkan. Ma se segui questa strada dovresti almeno sapere tutto quello che ho menzionato sopra e alcuni!

Come puoi vedere, Vulkan non è davvero orientato verso i programmatori principianti in questo campo. Devi avere una vasta conoscenza di tutta la matematica, i paradigmi di programmazione, tutti i diversi tipi di set di dati e algoritmi tra cui threading, sincronizzazione della memoria, programmazione parallela. E anche allora basta che l'applicazione carichi un semplice triangolo 2D sullo schermo. Cosa si può fare in circa 100 righe di codice in OpenGL o 250 righe di codice in DirectX richiede quasi 1.000 righe di codice in Vulkan!

Vulkan lascia tutto a te in quanto responsabile di tutti gli aspetti di come stai usando Vulkan nella tua applicazione. Non c'è mano che regge, non ti ostacola, ti permetterà di spararti nel piede o ti permetterà di impiccarti comprando un cappio ricorsivo!

Ora questo non vuol dire che i principianti o quelli che sono nuovi in ​​questo campo non dovrebbero imparare Vulkan, ma ciò che suggerirei per loro è questo: prima Impara abbastanza di OpenGL e o DirectX per bagnarti i piedi per vedere come un l'applicazione di base è strutturata solo per il rendering di un triangolo semplice o di un cubo rotante. Acquisire familiarità con le loro API e i loro schemi ricorrenti delle loro strutture. Mentre apprendi che potresti imparare Vulkan sul lato in parallelo, in questo modo puoi vedere come ciascuno dei tre sta eseguendo la stessa attività, ma sai come lo fanno in modo diverso, quindi puoi anche confrontare i risultati tra le diverse API e da lì puoi quindi scegliere quale preferisci. Questo metodo ti darebbe anche un altro strumento nella tua casella degli strumenti e potresti persino scrivere la tua applicazione per supportare tutti e 3 e avere il "

Alla fine spetta a quella persona scegliere quale percorso vogliono percorrere, e da lì il loro successo sarà determinato dalla loro dedizione, studio costante, duro lavoro, prove ed errori e, soprattutto, dai loro fallimenti. Se non fallisci, allora non hai successo! Hai successo solo se hai fallito, hai trovato i tuoi errori, li hai riparati, sono passati e sono tornati su e ho fatto tutto da capo!

Dovresti prima imparare OpenGL, poiché è lo standard per la grafica, su così tante piattaforme.

Anche se esiste una biblioteca più recente, capire le basi e lavorare con un linguaggio che viene utilizzato in tutto il settore, è molto importante ... Soprattutto dal momento che Vulkan non verrà utilizzato nelle grandi aziende da allora.

1. Nessuno vuole adattarsi immediatamente e finire per rovinarsi con un framework / libreria non stabile.

2. Dovrebbero assumere / riqualificare i loro attuali programmatori Open-GL, e non è necessario.

Inoltre, ho sentito che OpenGL e Vulkan non sono esattamente gli stessi. Ho sentito che Vulkan è un'API di livello inferiore, e più vicina al codice macchina, di OpenGL.

Questa risposta che ho appena trovato sembra avere molte informazioni interessanti

https://gamedev.stackexchange.com/questions/96014/what-is-vulkan-and-how-does-it-differ-from-opengl

Un'altra cosa da considerare è il problema che si è verificato con OpenGL 1.

Da OpenGL 1 a OpenGL 2 sono state apportate modifiche MAJOR, e poiché molte persone stavano usando OpenGL1 e l'hardware lo supportava, è necessaria un'importante compatibilità con le versioni precedenti da implementare in alcune applicazioni / motori e che a volte è davvero doloroso per gli sviluppatori continuare a supportarlo .

Oltre al supporto, la lingua è cambiata così tanto che hai dovuto imparare nuove cose.

Questo è successo con framework come JavaFX (da 1.xa 2.x) e Play! Framework (anche da 1.xa 2.x). Modifiche complete al framework, nel senso che dobbiamo imparare di nuovo ... tutto ...

Quindi essenzialmente quello che dovresti fare è aspettare che Vulkan sia STABILE. Ciò significa attendere fino probabilmente alla patch 2.0. L'IT non significa che non puoi conoscere le basi di Vulkan, ma sappi solo che potrebbe cambiare. Suppongo che un gruppo come Kronos fornirebbe un'API molto stabile sin dall'inizio, soprattutto perché ci sono molti ingegneri Nvidia e AMD che lavorano su Vulkan, inclusa una persona di alto livello che sovrintende al progetto apparentemente, così come The base of Mantle; tuttavia, come qualsiasi software, noi programmatori vedremo quanto funziona bene dall'inizio, ma molti sono cauti e in attesa di vedere cosa succede.