Molte delle risposte qui sono davvero molto buone. Ma il problema OpenGL e Direct3D (D3D) dovrebbe probabilmente essere affrontato. E questo richiede ... una lezione di storia.
E prima di iniziare, so molto di più su OpenGL di quanto non faccia Direct3D . Non ho mai scritto una riga di codice D3D in vita mia e ho scritto tutorial su OpenGL. Quindi quello che sto per dire non è una questione di parzialità. È semplicemente una questione di storia.
Nascita del conflitto
Un giorno, nei primi anni '90, Microsoft si guardò attorno. Hanno visto che SNES e Sega Genesis erano fantastici, con molti giochi d'azione e simili. E hanno visto DOS . Gli sviluppatori hanno codificato i giochi DOS come i giochi per console: diretti al metal. A differenza delle console, tuttavia, in cui uno sviluppatore che ha realizzato un gioco SNES sapeva quale hardware avrebbe avuto l'utente, gli sviluppatori DOS hanno dovuto scrivere per più configurazioni possibili. E questo è piuttosto più difficile di quanto sembri.
E Microsoft ha avuto un problema più grande: Windows. Vedi, Windows voleva possedere l'hardware, diversamente dal DOS che praticamente lasciava che gli sviluppatori facessero qualunque cosa. Possedere l'hardware è necessario per avere una cooperazione tra le applicazioni. La cooperazione è esattamente ciò che gli sviluppatori di giochi odiano perché occupa preziose risorse hardware che potrebbero usare per essere fantastici.
Al fine di promuovere lo sviluppo di giochi su Windows, Microsoft aveva bisogno di un'API uniforme di basso livello, eseguita su Windows senza essere rallentata da essa e, soprattutto, cross-hardware . Un'unica API per tutta la grafica, l'audio e l'hardware di input.
Così è nato DirectX .
Gli acceleratori 3D sono nati pochi mesi dopo. E Microsoft ha avuto un problema. Vedi, DirectDraw, il componente grafico di DirectX, si occupava solo della grafica 2D: allocare memoria grafica e fare bit-bit tra le diverse sezioni di memoria allocate.
Quindi Microsoft acquistò un po 'di middleware e lo trasformò in Direct3D versione 3. Fu universalmente smentito. E con una buona ragione; guardare il codice D3D v3 è come guardare nell'Arca dell'Alleanza.
Il vecchio John Carmack di Id Software ha dato un'occhiata a quella spazzatura e ha detto: "Fanculo!" e ho deciso di scrivere verso un'altra API: OpenGL.
Vedi, un'altra parte della bestia dalle molte teste che è Microsoft era stata impegnata a lavorare con SGI su un'implementazione OpenGL per Windows. L'idea qui era di corteggiare gli sviluppatori delle tipiche applicazioni GL: app per workstation. Strumenti CAD, modellazione, questo genere di cose. I giochi erano la cosa più lontana nella loro mente. Questa era principalmente una cosa di Windows NT, ma Microsoft ha deciso di aggiungerla anche a Win95.
Per attirare gli sviluppatori di workstation su Windows, Microsoft ha deciso di provare a corromperli con l'accesso a queste nuove schede grafiche 3D. Microsoft ha implementato il protocollo Installable Client Driver: un produttore di schede grafiche potrebbe sovrascrivere l'implementazione OpenGL del software Microsoft con una basata su hardware. Il codice potrebbe automaticamente utilizzare un'implementazione OpenGL hardware se disponibile.
All'inizio, tuttavia, i videocards di livello consumer non avevano il supporto per OpenGL. Ciò non ha impedito a Carmack di eseguire il porting di Quake su OpenGL (GLQuake) sulla sua workstation SGI. Come possiamo leggere dal readme di GLQuake:
Teoricamente, glquake verrà eseguito su qualsiasi OpenGL conforme che supporti le estensioni degli oggetti texture, ma a meno che non sia un hardware molto potente che accelera tutto il necessario, il gioco non sarà accettabile. Se deve attraversare percorsi di emulazione software, le prestazioni saranno probabilmente ben al di sotto di un frame al secondo.
In questo momento (marzo '97), l'unico hardware Opengl standard in grado di giocare ragionevolmente in glquake è un realismo intergrafico, che è una carta MOLTO costosa. 3dlabs ha migliorato significativamente le sue prestazioni, ma con i driver disponibili non è ancora abbastanza buono per giocare. Alcuni dei driver 3dlabs attuali per le schede glint e permedia possono anche arrestare in modo anomalo NT quando si esce da una corsa a schermo intero, quindi non consiglio di eseguire glquake sull'hardware 3dlabs.
3dfx ha fornito un opengl32.dll che implementa tutto il necessario per glquake, ma non è un'implementazione completa. È improbabile che altre applicazioni opengl funzionino con esso, quindi consideralo fondamentalmente un "driver glquake".
Questa è stata la nascita dei driver miniGL. Questi alla fine si sono evoluti in implementazioni OpenGL complete, poiché l'hardware è diventato abbastanza potente da implementare la maggior parte delle funzionalità OpenGL nell'hardware. nVidia è stata la prima a offrire un'implementazione OpenGL completa. Molti altri produttori hanno avuto difficoltà, motivo per cui gli sviluppatori hanno preferito Direct3D: erano compatibili su una gamma più ampia di hardware. Alla fine rimasero solo nVidia e ATI (ora AMD) ed entrambi avevano una buona implementazione OpenGL.
Ascendente OpenGL
Quindi è impostato il palcoscenico: Direct3D vs. OpenGL. È davvero una storia fantastica, considerando quanto D3D v3 fosse brutta.
OpenGL Architectural Review Board (ARB) è l'organizzazione responsabile della manutenzione di OpenGL. Rilasciano un numero di estensioni, gestiscono il repository delle estensioni e creano nuove versioni dell'API. L'ARB è un comitato composto da molti attori dell'industria grafica e da alcuni produttori di sistemi operativi. Apple e Microsoft sono state varie volte membri dell'ARB.
3Dfx esce con Voodoo2. Questo è il primo hardware in grado di eseguire il multitexturing, cosa che OpenGL non poteva fare prima. Mentre 3Dfx era fortemente contrario a OpenGL, NVIDIA, i produttori del prossimo chip grafico multitexturing (il TNT1), lo adorava. Quindi l'ARB ha rilasciato un'estensione: GL_ARB_multitexture, che consentirebbe l'accesso al multitexturing.
Nel frattempo, esce Direct3D v5. Ora, D3D è diventato una vera e propria API , piuttosto che qualcosa che un gatto potrebbe vomitare. Il problema? Nessun multitexturing.
Ops.
Ora, quello non farebbe male quasi quanto avrebbe dovuto, perché le persone non usavano molto il multitexturing. Non direttamente Il multitexturing ha danneggiato un po 'le prestazioni, e in molti casi non ne è valsa la pena rispetto al multi-passaggio. E, naturalmente, gli sviluppatori di giochi adorano assicurarsi che i loro giochi funzionino su hardware più vecchio, che non aveva il multitexturing, quindi molti giochi sono stati venduti senza di essa.
D3D è stato quindi dato un recupero.
Il tempo passa e NVIDIA implementa la GeForce 256 (non la GeForce GT-250; la prima GeForce), praticamente terminando la competizione nelle schede grafiche per i prossimi due anni. Il principale punto di forza è la capacità di trasformare i vertici e l'illuminazione (T&L) nell'hardware. Non solo, NVIDIA ha adorato OpenGL così tanto che il suo motore T&L era effettivamente OpenGL. Quasi letteralmente; a quanto ho capito, alcuni dei loro registri hanno effettivamente preso direttamente gli enumeratori OpenGL come valori.
Direct3D v6 esce. Finalmente il multitexture ma ... nessun T&L hardware. OpenGL aveva sempre avuto una pipeline T&L, anche se prima del 256 era implementata nel software. Quindi è stato molto facile per NVIDIA convertire semplicemente l'implementazione del software in una soluzione hardware. Non sarebbe fino a quando D3D v7 fino a quando D3D non avesse finalmente il supporto T&L hardware.
Dawn of Shaders, Twilight of OpenGL
Quindi, GeForce 3 è uscito. E sono successe molte cose contemporaneamente.
Microsoft aveva deciso che non sarebbero tornati in ritardo. Quindi, invece di guardare a ciò che NVIDIA stava facendo e poi copiarlo dopo il fatto, hanno preso la posizione sorprendente di andare da loro e parlare con loro. E poi si sono innamorati e hanno avuto una piccola console insieme.
Un divorzio disordinato è seguito in seguito. Ma questo è per un'altra volta.
Ciò che ciò significava per il PC era che GeForce 3 usciva contemporaneamente a D3D v8. E non è difficile capire come GeForce 3 abbia influenzato gli shader di D3D 8. I pixel shader di Shader Model 1.0 erano estremamente specifici per l'hardware di NVIDIA. Non è stato fatto alcun tentativo di astrarre l'hardware di NVIDIA; SM 1.0 era esattamente ciò che faceva GeForce 3.
Quando ATI ha iniziato a lanciarsi nella corsa della scheda grafica ad alte prestazioni con la Radeon 8500, si è verificato un problema. La pipeline di elaborazione dei pixel dell'8500 era più potente di quella di NVIDIA. Quindi Microsoft ha rilasciato Shader Model 1.1, che in pratica era "Qualunque cosa faccia l'8500".
Potrebbe sembrare un fallimento da parte di D3D. Ma il fallimento e il successo sono una questione di gradi. E l' epico fallimento stava accadendo nella terra di OpenGL.
NVIDIA adorava OpenGL, quindi quando GeForce 3 arrivò, rilasciò una serie di estensioni OpenGL. Estensioni OpenGL proprietarie : solo NVIDIA. Naturalmente, quando l'8500 si presentò, non poteva usarne nessuno.
Vedi, almeno nella terra D3D 8, potresti eseguire i tuoi shader SM 1.0 su hardware ATI. Certo, dovevi scrivere nuovi shader per sfruttare la freddezza dell'8500, ma almeno il tuo codice funzionava .
Per avere shader di qualsiasi tipo su Radeon 8500 in OpenGL, ATI ha dovuto scrivere una serie di estensioni OpenGL. Estensioni OpenGL proprietarie : solo ATI. Quindi avevi bisogno di un codepath NVIDIA e di un codepath ATI, solo per avere degli shader .
Ora, potresti chiedere: "Dov'era l'ARB OpenGL, di chi era il compito di mantenere aggiornato OpenGL?" Dove spesso finiscono molti comitati: essere stupidi.
Vedi, ho menzionato sopra ARB_multitexture perché influenza profondamente tutto ciò. L'ARB sembrava (dal punto di vista di un estraneo) voler evitare del tutto l'idea degli shader. Hanno pensato che se avessero schiaffeggiato abbastanza configurabilità sulla pipeline a funzione fissa, avrebbero potuto eguagliare la capacità di una pipeline shader.
Quindi l'ARB ha rilasciato l'estensione dopo l'estensione. Ogni estensione con le parole "texture_env" era ancora un altro tentativo di correggere questo invecchiamento. Controlla il registro: tra le estensioni ARB ed EXT, ne sono state realizzate otto . Molti sono stati promossi a versioni core OpenGL.
Microsoft faceva parte dell'ARB in quel momento; se ne andarono nel periodo in cui D3D 9 colpì. Quindi è del tutto possibile che stessero lavorando per sabotare OpenGL in qualche modo. Personalmente dubito di questa teoria per due motivi. Uno, avrebbero dovuto ottenere aiuto dagli altri membri dell'ARB per farlo, dato che ogni membro ottiene un solo voto. E, soprattutto, due, l'ARB non aveva bisogno dell'aiuto di Microsoft per rovinare tutto. Vedremo ulteriori prove di ciò.
Alla fine l'ARB, probabilmente minacciato sia da ATI che da NVIDIA (entrambi i membri attivi) alla fine ha tirato fuori la testa abbastanza a lungo da fornire veri e propri shader in stile assembly.
Vuoi qualcosa di ancora più stupido?
T&L hardware. Qualcosa che OpenGL aveva prima . Bene, è interessante Per ottenere le massime prestazioni possibili dai T&L hardware, è necessario archiviare i dati dei vertici sulla GPU. Dopotutto, è la GPU che vuole effettivamente utilizzare i dati del vertice.
In D3D v7, Microsoft ha introdotto il concetto di buffer di vertici. Questi sono allocati segmenti di memoria GPU per l'archiviazione dei dati dei vertici.
Vuoi sapere quando OpenGL ne ha ottenuto l'equivalente? Oh, NVIDIA, amante di tutte le cose OpenGL (purché siano estensioni NVIDIA proprietarie), ha rilasciato l'estensione della gamma di array di vertici al primo colpo di GeForce 256. Ma quando l'ARB ha deciso di fornire funzionalità simili?
Due anni dopo . Questo dopo che hanno approvato shader di vertici e frammenti (pixel in linguaggio D3D). Questo è il tempo impiegato dall'ARB per sviluppare una soluzione multipiattaforma per l'archiviazione dei dati dei vertici nella memoria della GPU. Ancora una volta, qualcosa di cui T&L hardware ha bisogno per raggiungere le massime prestazioni.
Una lingua per rovinarli tutti
Quindi, l'ambiente di sviluppo OpenGL è stato fratturato per un certo periodo. Nessuno shader cross-hardware, nessuna memoria vertice GPU cross-hardware, mentre gli utenti D3D hanno apprezzato entrambi. Potrebbe andare peggio?
Tu ... potresti dirlo. Entra in 3D Labs .
Chi sono, potresti chiedere? Sono una compagnia defunta che considero i veri assassini di OpenGL. Certo, l'inettitudine generale dell'ARB ha reso vulnerabile OpenGL quando avrebbe dovuto possedere D3D. Ma 3D Labs è forse il motivo principale per me per l'attuale stato di mercato di OpenGL. Cosa avrebbero potuto fare per causarlo?
Hanno progettato il linguaggio di ombreggiatura OpenGL.
Vedi, 3D Labs era una società morente. Le loro costose GPU venivano emarginate dalla crescente pressione di NVIDIA sul mercato delle workstation. E a differenza di NVIDIA, 3D Labs non aveva alcuna presenza nel mercato principale; se ha vinto NVIDIA, sono morti.
Che hanno fatto.
Quindi, nel tentativo di rimanere rilevanti in un mondo che non voleva i loro prodotti, 3D Labs si è presentato a una conferenza degli sviluppatori di giochi con presentazioni per qualcosa che hanno chiamato "OpenGL 2.0". Questa sarebbe una riscrittura completa da zero dell'API OpenGL. E questo ha senso; all'epoca l'API di OpenGL aveva un sacco di innesti (nota: quell'innesto esiste ancora). Guarda come funzionano il caricamento delle trame e la rilegatura; è semi-arcano.
Parte della loro proposta era un linguaggio di ombreggiatura. Naturalmente. Tuttavia, a differenza delle attuali estensioni ARB multipiattaforma, il loro linguaggio di shading era "di alto livello" (C è di alto livello per un linguaggio di shading. Sì, davvero).
Ora, Microsoft stava lavorando sul proprio linguaggio di ombreggiatura di alto livello. Che loro, in tutta l'immaginazione collettiva di Microsoft, chiamavano ... High Level Shading Language (HLSL). Ma il loro era un approccio fondamentalmente diverso alle lingue.
Il problema più grande con il linguaggio shader di 3D Labs era che era integrato. Vedi, HLSL era una lingua definita da Microsoft. Hanno rilasciato un compilatore per questo, e ha generato il codice assembly Shader Model 2.0 (o modelli shader successivi), che avresti inserito in D3D. Nei giorni D3D v9, H3SL non veniva mai toccato direttamente da D3D. Era una bella astrazione, ma era puramente opzionale. E uno sviluppatore ha sempre avuto l'opportunità di andare dietro il compilatore e modificare l'output per ottenere le massime prestazioni.
Il linguaggio 3D Labs non aveva nulla di tutto ciò. Hai dato all'autista un linguaggio simile al C e questo ha prodotto uno shader. Fine della storia. Non uno shader di assemblaggio, non qualcosa che dai da mangiare a qualcos'altro. L'oggetto OpenGL effettivo che rappresenta uno shader.
Ciò significava che gli utenti di OpenGL erano aperti ai capricci degli sviluppatori che stavano semplicemente imparando a compilare linguaggi simili a assembly. I bug del compilatore dilagavano nel nuovo battesimo OpenGL Shading Language (GLSL). Quel che è peggio, se sei riuscito a far compilare correttamente uno shader su più piattaforme (cosa da poco), sei stato comunque sottoposto agli ottimizzatori del giorno. Che non erano ottimali come potevano essere.
Mentre quello era il più grande difetto di GLSL, non era l'unico difetto. Di gran lunga .
In D3D e nei linguaggi di assemblaggio precedenti in OpenGL, è possibile combinare shader di vertici e frammenti (pixel). Finché comunicano con la stessa interfaccia, è possibile utilizzare qualsiasi shader di vertici con qualsiasi shader di frammenti compatibile. E c'erano persino livelli di incompatibilità che potevano accettare; uno shader di vertice potrebbe scrivere un output che lo shader di frammento non ha letto. E così via.
GLSL non aveva nulla di tutto ciò. Gli shader di vertici e frammenti sono stati fusi insieme in quello che 3D Labs ha chiamato un "oggetto programma". Quindi, se si desidera condividere programmi di vertici e frammenti, è necessario creare più oggetti programma. E questo ha causato il secondo problema più grande.
Vedi, 3D Labs pensava che fossero intelligenti. Hanno basato il modello di compilazione di GLSL su C / C ++. Prendi un .c o .cpp e lo compili in un file oggetto. Quindi prendi uno o più file oggetto e li colleghi in un programma. Ecco come si compila GLSL: compili il tuo shader (vertice o frammento) in un oggetto shader. Quindi metti quegli oggetti shader in un oggetto programma e li colleghi insieme per formare il tuo vero programma.
Mentre ciò ha consentito a potenziali idee interessanti come avere shader "di libreria" che contenevano codice aggiuntivo che gli shader principali potevano chiamare, ciò che in pratica significava che gli shader venivano compilati due volte . Una volta nella fase di compilazione e una volta nella fase di collegamento. Il compilatore di NVIDIA in particolare era noto per aver sostanzialmente eseguito la compilazione due volte. Non ha generato alcun tipo di intermediario del codice oggetto; l'ha appena compilato una volta e ha gettato via la risposta, quindi l'ha compilata di nuovo al momento del collegamento.
Quindi, anche se vuoi collegare il tuo shader di vertice a due diversi shader di frammenti, devi fare molto più compilazioni che in D3D. Soprattutto dal momento che la compilazione di un linguaggio di tipo C è stata eseguita offline , non all'inizio dell'esecuzione del programma.
Ci sono stati altri problemi con GLSL. Forse sembra sbagliato dare la colpa a 3D Labs, dal momento che l'ARB alla fine ha approvato e incorporato il linguaggio (ma nient'altro della loro iniziativa "OpenGL 2.0"). Ma era una loro idea.
Ed ecco la parte davvero triste: 3D Labs aveva ragione (principalmente). GLSL non è un linguaggio di shading basato su vettori come era allora HLSL. Questo perché l'hardware di 3D Labs era hardware scalare (simile al moderno hardware NVIDIA), ma alla fine erano proprio nella direzione in cui molti produttori di hardware sono andati con il loro hardware.
Avevano ragione a scegliere un modello di compilazione online per un linguaggio "di alto livello". D3D è persino passato a quello alla fine.
Il problema era che i 3D Labs avevano ragione nel momento sbagliato . E nel tentativo di evocare il futuro troppo presto, nel tentativo di essere a prova di futuro, hanno messo da parte il presente . Sembra simile a come OpenGL ha sempre avuto la possibilità di funzionalità T&L. Solo che la pipeline T&L di OpenGL era ancora utile prima di T&L hardware, mentre GLSL era una responsabilità prima che il mondo lo raggiungesse.
GLSL è una buona lingua ora . Ma per il momento? È stato orribile. E OpenGL ne ha sofferto.
Cadere verso l'apoteosi
Mentre sostengo che 3D Labs ha colpito il colpo fatale, è stato lo stesso ARB a guidare l'ultimo chiodo nella bara.
Questa è una storia di cui potresti aver sentito parlare. Al momento di OpenGL 2.1, OpenGL aveva riscontrato un problema. Aveva un sacco di legacy legft. L'API non era più facile da usare. C'erano 5 modi per fare le cose e non avevo idea di quale fosse il più veloce. Potresti "imparare" OpenGL con semplici tutorial, ma non hai davvero imparato l'API OpenGL che ti ha dato prestazioni reali e potenza grafica.
Quindi l'ARB decise di tentare un'altra reinvenzione di OpenGL. Questo era simile a "OpenGL 2.0" di 3D Labs, ma meglio perché dietro c'era l'ARB. Lo chiamavano "Longs Peak".
Cosa c'è di male nel prendere un po 'di tempo per migliorare l'API? Ciò era negativo perché Microsoft si era lasciata vulnerabile. Vedi, questo era al momento del passaggio a Vista.
Con Vista, Microsoft ha deciso di introdurre alcune modifiche indispensabili nei driver di visualizzazione. Hanno costretto i driver a presentare al sistema operativo per la virtualizzazione della memoria grafica e varie altre cose.
Mentre uno può discutere i meriti di questo o se fosse effettivamente possibile, il fatto rimane questo: Microsoft ha ritenuto che D3D 10 fosse solo Vista (e superiore). Anche se si disponesse di hardware in grado di D3D 10, non è possibile eseguire applicazioni D3D 10 senza anche eseguire Vista.
Potresti anche ricordare che Vista ... um, diciamo solo che non ha funzionato bene. Quindi avevi un sistema operativo poco performante, una nuova API che funzionava solo su quel sistema operativo e una nuova generazione di hardware che aveva bisogno di tale API e sistema operativo per fare qualcosa di più che essere più veloce della generazione precedente.
Tuttavia, gli sviluppatori potrebbero accedere alle funzionalità di classe D3D 10 tramite OpenGL. Bene, potrebbero se l'ARB non fosse stato impegnato a lavorare su Longs Peak.
Fondamentalmente, l'ARB ha trascorso un buon anno e mezzo o due anni di lavoro per migliorare l'API. Quando uscì OpenGL 3.0, l'adozione di Vista era in aumento, Win7 era dietro l'angolo per mettere Vista alle spalle e la maggior parte degli sviluppatori di giochi non si interessava comunque delle funzionalità della classe D3D-10. Dopotutto, l'hardware D3D 10 eseguiva correttamente le applicazioni D3D 9. E con l'ascesa delle porte da PC a console (o gli sviluppatori di PC che saltano per lo sviluppo della console. Scegliete), gli sviluppatori non hanno avuto bisogno delle funzionalità di classe D3D 10.
Ora, se gli sviluppatori avessero avuto accesso a tali funzionalità in precedenza tramite OpenGL su macchine WinXP, lo sviluppo di OpenGL avrebbe potuto ricevere un colpo indispensabile nel braccio. Ma l'ARB ha perso la loro opportunità. E vuoi sapere la parte peggiore?
Nonostante abbiano trascorso due anni preziosi nel tentativo di ricostruire l'API da zero ... hanno comunque fallito e sono tornati allo status quo (ad eccezione di un meccanismo di deprecazione).
Quindi non solo l'ARB ha perso una finestra cruciale di opportunità, ma non ha nemmeno svolto il compito che gli ha fatto perdere quella possibilità. Praticamente un fallimento epico tutt'intorno.
E questa è la storia di OpenGL contro Direct3D. Un racconto di occasioni mancate, grave stupidità, cecità intenzionale e semplice follia.