Beaucoup de réponses ici sont vraiment très bonnes. Mais le problème OpenGL et Direct3D (D3D) devrait probablement être résolu. Et cela nécessite ... une leçon d'histoire.
Et avant de commencer, j'en connais beaucoup plus sur OpenGL que sur Direct3D . Je n'ai jamais écrit une ligne de code D3D de ma vie et j'ai écrit des tutoriels sur OpenGL. Donc, ce que je vais dire n’est pas une question de partialité. C'est simplement une question d'histoire.
Naissance du conflit
Un jour, au début des années 90, Microsoft a regardé autour de lui. Ils ont vu la SNES et Sega Genesis être géniaux, avec beaucoup de jeux d’action et autres. Et ils ont vu DOS . Les développeurs ont codé les jeux DOS comme des jeux de console: directement sur du métal. Contrairement aux consoles cependant, où un développeur qui a créé un jeu SNES connaissait le matériel dont disposerait l'utilisateur, les développeurs DOS devaient écrire pour plusieurs configurations possibles. Et c'est plutôt plus difficile qu'il n'y paraît.
Et Microsoft avait un plus gros problème: Windows. Vous voyez, Windows voulait posséder le matériel, contrairement à DOS qui laissait les développeurs faire n'importe quoi. Posséder le matériel est nécessaire pour assurer la coopération entre les applications. La coopération est exactement ce que les développeurs de jeux détestent, car elle nécessite d’importantes ressources matérielles qu’ils pourraient utiliser pour devenir géniaux.
Afin de promouvoir le développement de jeux sous Windows, Microsoft avait besoin d’une API uniforme, de bas niveau, fonctionnant sous Windows sans être ralentie, et surtout multi-matériels . Une seule API pour tous les graphiques, le son et le matériel d'entrée.
Ainsi, DirectX est né.
Les accélérateurs 3D sont nés quelques mois plus tard. Et Microsoft a eu des ennuis. Voir DirectDraw, le composant graphique de DirectX, ne traitait que des graphiques 2D: allouer de la mémoire graphique et effectuer des mélanges de bits entre différentes sections de mémoire allouées.
Donc, Microsoft a acheté un peu de middleware et l'a transformé en Direct3D Version 3. Il a été universellement critiqué. Et avec raison. Regarder le code D3D v3, c'est comme regarder l'arche de l'alliance.
Le vieux John Carmack d'Id Software a jeté un coup d'œil à cette corbeille et a dit: "Fous ça!" et a décidé d'écrire vers une autre API: OpenGL.
Vous voyez, une autre partie de la bête aux multiples têtes que Microsoft avait été occupée à travailler avec SGI sur une implémentation OpenGL pour Windows. L'idée ici était de courtiser les développeurs d'applications GL typiques: les applications de poste de travail. Les outils de CAO, la modélisation, ce genre de chose. Les jeux étaient la chose la plus distante dans leur esprit. Il s’agissait principalement de Windows NT, mais Microsoft a également décidé de l’ajouter à Win95.
Afin d'attirer les développeurs de stations de travail vers Windows, Microsoft a décidé d'essayer de les corrompre en leur donnant accès à ces nouvelles cartes graphiques 3D. Microsoft a mis en œuvre le protocole Installable Client Driver: un fabricant de cartes graphiques pourrait remplacer l'implémentation logicielle OpenGL de Microsoft par une implémentation matérielle. Le code pourrait automatiquement utiliser une implémentation OpenGL matérielle, le cas échéant.
À l'origine, les cartes vidéo grand public ne prenaient pas en charge OpenGL. Cela n'a pas empêché Carmack de simplement porter Quake sur OpenGL (GLQuake) sur son poste de travail SGI. Comme on peut le lire dans le readme de GLQuake:
Théoriquement, glquake fonctionnera sur tout OpenGL conforme prenant en charge les extensions d’objets de texture, mais à moins que ce ne soit un matériel très puissant qui accélère tout ce qui est nécessaire, le jeu ne sera pas acceptable. S'il doit passer par un chemin d'émulation de logiciel, les performances seront probablement bien inférieures à une image par seconde.
En mars 1997, le seul matériel opengl standard capable de jouer de manière raisonnable est un réalisme intergraphe, une carte TRES chère. 3dlabs a amélioré leurs performances de manière significative, mais avec les pilotes disponibles, il n'est toujours pas assez bon pour jouer. Certains des pilotes 3dlabs actuels pour les cartes glint et permedia peuvent également provoquer le blocage de NT lors de la sortie d'un fonctionnement en plein écran. Je vous déconseille donc d'exécuter glquake sur du matériel 3dlabs.
3dfx a fourni un opengl32.dll qui implémente tout ce dont glquake a besoin, mais ce n'est pas une implémentation opengl complète. Il est très peu probable que d'autres applications opengl fonctionnent avec cette application, considérez-la donc fondamentalement comme un «pilote glquake».
Ce fut la naissance des pilotes miniGL. Celles-ci ont finalement évolué vers des implémentations OpenGL complètes, à mesure que le matériel devenait suffisamment puissant pour implémenter la plupart des fonctionnalités OpenGL dans le matériel. nVidia a été le premier à proposer une implémentation OpenGL complète. De nombreux autres fournisseurs ont eu des difficultés, raison pour laquelle les développeurs ont préféré Direct3D: ils étaient compatibles avec une gamme plus étendue de matériel. Finalement, seuls nVidia et ATI (maintenant AMD) sont restés et les deux ont eu une bonne implémentation OpenGL.
OpenGL Ascendant
Ainsi, la scène est définie: Direct3D vs OpenGL. C'est vraiment une histoire incroyable, compte tenu de la gravité de D3D v3.
L’OpenGL Architectural Review Board (ARB) est l’organisation responsable de la maintenance de OpenGL. Ils émettent un certain nombre d'extensions, maintiennent le référentiel d'extensions et créent de nouvelles versions de l'API. L'ARB est un comité composé de nombreux acteurs de l'industrie graphique, ainsi que de fabricants de systèmes d'exploitation. Apple et Microsoft ont été à plusieurs reprises membres de l'ARB.
3Dfx sort avec le Voodoo2. C'est le premier matériel capable de faire du multitexturing, ce qu'OpenGL ne pouvait pas faire auparavant. Alors que 3Dfx était fermement opposé à OpenGL, NVIDIA, fabricant de la prochaine puce graphique multitexturation (la TNT1), a adoré. L'ARB a donc publié une extension: GL_ARB_multitexture, qui permettrait d'accéder au multitexturing.
Pendant ce temps, Direct3D v5 est sorti. Maintenant, D3D est devenu une API réelle , plutôt que ce qu'un chat pourrait vomir. Le problème? Pas de multitexturing.
Oops.
Maintenant, celui-ci ne ferait pas autant mal qu'il aurait dû, car les utilisateurs n'utilisaient pas beaucoup le multitexturing. Pas directement. Le multitexturing nuit beaucoup aux performances et, dans de nombreux cas, cela ne valait pas la peine comparé au multi-dépassement. Et bien sûr, les développeurs de jeux aiment faire en sorte que leurs jeux fonctionnent sur du matériel plus ancien, qui ne faisait pas appel au multitexturation, et de nombreux jeux livrés sans ce matériel.
D3D se voit donc accorder un sursis.
Le temps passe et NVIDIA utilise la GeForce 256 (pas la GeForce GT-250; la toute première GeForce), qui met pratiquement fin à la concurrence dans les cartes graphiques pour les deux prochaines années. Le principal argument de vente est la possibilité d'effectuer la transformation de sommet et l'éclairage (T & L) dans le matériel. De plus, NVIDIA a tellement aimé OpenGL que leur moteur T & L était effectivement OpenGL. Presque littéralement; si je comprends bien, certains de leurs registres prenaient en réalité directement les énumérateurs OpenGL comme valeurs.
Direct3D v6 est sorti. Multitexture enfin mais ... pas de matériel T & L. OpenGL avait toujours eu un pipeline T & L, même avant le 256, il était implémenté dans le logiciel. Il était donc très facile pour NVIDIA de convertir leur implémentation logicielle en solution matérielle. Ce ne serait pas avant D3D v7 avant que D3D ait enfin pris en charge le matériel T & L.
Aube des Shaders, crépuscule d'OpenGL
Ensuite, GeForce 3 est sorti. Et beaucoup de choses se sont passées en même temps.
Microsoft avait décidé qu'ils ne seraient plus en retard. Ainsi, au lieu de regarder ce que faisait NVIDIA et de le copier après coup, ils ont pris l’étonnante position de s’adresser à eux et de leur parler. Et puis ils sont tombés amoureux et ont eu une petite console ensemble.
Un divorce compliqué s'ensuivit plus tard. Mais c'est pour une autre fois.
Cela signifiait pour le PC que GeForce 3 était sorti simultanément avec D3D v8. Et il n’est pas difficile de voir comment GeForce 3 a influencé les shaders de D3D 8. Les pixel shaders de Shader Model 1.0 étaient extrêmement spécifiques au matériel de NVIDIA. Aucune tentative n'a été faite pour extraire le matériel de NVIDIA; SM 1.0 était exactement ce que la GeForce 3 faisait.
Lorsque ATI a commencé à se lancer dans la course aux cartes graphiques de performance avec la Radeon 8500, un problème est survenu. Le pipeline de traitement des pixels du 8500 était plus puissant que celui de NVIDIA. Ainsi, Microsoft a publié Shader Model 1.1, qui était essentiellement "Quoi que fasse le 8500".
Cela peut sembler être un échec de la part de D3D. Mais l'échec et le succès sont une affaire de degrés. Et un échec épique se produisait dans OpenGL-land.
NVIDIA aimait OpenGL, alors quand GeForce 3 est apparue, ils ont sorti de nombreuses extensions OpenGL. Extensions propriétaires OpenGL: NVIDIA uniquement. Naturellement, lorsque le 8500 est arrivé, il ne pouvait en utiliser aucun.
Voir, au moins dans D3D 8 Land, vous pouvez exécuter vos shaders SM 1.0 sur du matériel ATI. Bien sûr, vous deviez écrire de nouveaux shaders pour profiter de la fraîcheur du 8500, mais au moins votre code fonctionnait .
Afin d’avoir des shaders de tout type sur Radeon 8500 dans OpenGL, ATI devait écrire un certain nombre d’extensions OpenGL. Extensions propriétaires OpenGL: ATI uniquement. Il fallait donc un chemin de code NVIDIA et un chemin de code ATI, juste pour avoir des shaders .
Maintenant, vous pourriez demander: "Où était l'OpenGL ARB, qui était chargé de maintenir OpenGL à jour?" Là où beaucoup de comités finissent souvent par être stupides.
Vous voyez, j'ai mentionné ARB_multitexture ci-dessus parce que cela prend en compte tout cela. L'ARB semblait (du point de vue d'un étranger) vouloir éviter complètement l'idée de shaders. Ils ont estimé que s’ils plaçaient suffisamment de possibilités de configuration sur le pipeline à fonction fixe, ils pourraient égaler la capacité d’un pipeline de shader.
Donc, l'ARB a publié extension après extension. Chaque extension avec les mots "texture_env" était une nouvelle tentative de correction de cette conception vieillissante. Vérifiez le registre: entre les extensions ARB et EXT, huit de ces extensions ont été réalisées. Beaucoup ont été promus aux versions de base d'OpenGL.
Microsoft faisait partie de l'ARB à cette époque; ils sont partis à peu près au moment où D3D 9 a frappé. Il est donc tout à fait possible qu'ils travaillent à saboter OpenGL d'une manière ou d'une autre. Personnellement, je doute de cette théorie pour deux raisons. Premièrement, ils auraient dû obtenir l’aide d’autres membres de la CRÉA, car chaque membre n’avait qu’une voix. Et plus important encore, l'ARB n'a pas eu besoin de l'aide de Microsoft pour tout gâcher. Nous verrons d'autres preuves de cela.
Finalement, ARB, probablement sous la menace d'ATI et de NVIDIA (deux membres actifs), a finalement tiré la tête assez longtemps pour fournir de véritables shaders de type assemblage.
Tu veux quelque chose d'encore plus stupide?
Matériel T & L. Quelque chose avait été ouvert par OpenGL . Eh bien, c'est intéressant. Pour tirer le maximum des performances possibles de T & L matériel, vous devez stocker vos données de sommet sur le GPU. Après tout, c’est le GPU qui souhaite utiliser vos données de sommet.
Dans D3D v7, Microsoft a introduit le concept de mémoire tampon Vertex. Ce sont des bandes de mémoire GPU allouées pour stocker les données de sommet.
Vous voulez savoir quand OpenGL a obtenu son équivalent? Oh, NVIDIA, étant un amoureux de tout ce qui concerne OpenGL (tant qu’il s’agit d’extensions propriétaires NVIDIA), a publié l’extension de la plage de sommets au moment de la première utilisation de la GeForce 256. Mais quand l'ARB a-t-il décidé de fournir une fonctionnalité similaire?
Deux ans plus tard . C'était après qu'ils aient approuvé les shaders de vertex et de fragment (pixel en langage D3D). C’est le temps qu’a pris l’ARB à développer une solution multiplate-forme pour stocker les données de vertex dans la mémoire du processeur graphique. Là encore, T & L a besoin de matériel pour atteindre des performances optimales.
Une langue pour tous les ruiner
L’environnement de développement OpenGL a donc été fracturé pendant un certain temps. Pas de shaders cross-hardware, pas de stockage de vertex GPU cross-hardware, alors que les utilisateurs de D3D ont profité des deux. Cela pourrait-il empirer?
Tu ... tu pourrais dire ça. Entrez 3D Labs .
Qui sont-ils, vous pourriez demander? C’est une entreprise disparue que je considère comme le véritable tueur d’OpenGL. Bien sûr, l’inefficacité générale de l’ARB a rendu OpenGL vulnérable alors qu’il aurait dû posséder D3D. Mais 3D Labs est peut-être la principale raison qui me fait penser à l'état actuel du marché d'OpenGL. Qu'est-ce qu'ils auraient pu faire pour causer ça?
Ils ont conçu le langage de masquage OpenGL.
Vous voyez, 3D Labs était une entreprise mourante. Leurs GPU onéreux étaient marginalisés par la pression croissante de NVIDIA sur le marché des stations de travail. Et contrairement à NVIDIA, 3D Labs n’était pas présent sur le marché grand public; si NVIDIA gagnait, ils mourraient.
Ce qu'ils ont fait.
Ainsi, dans le but de rester pertinents dans un monde qui ne voulait pas de leurs produits, 3D Labs s'est présenté à une conférence de développeurs de jeux avec des présentations pour ce qu'ils ont appelé "OpenGL 2.0". Ce serait une réécriture complète de l’API OpenGL à partir de zéro. Et cela a du sens; L'API d'OpenGL était très cruelle à l'époque (note: cette crue existe toujours). Il suffit de regarder comment le chargement et la liaison des textures fonctionnent. c'est semi-arcanique.
Une partie de leur proposition était un langage ombré. Naturellement. Cependant, contrairement aux extensions ARB multi-plateformes actuelles, leur langage d’ombrage était «de haut niveau» (C est un niveau élevé pour un langage d’ombrage. Oui, vraiment).
Maintenant, Microsoft travaillait sur son propre langage d’ombrage de haut niveau. Dans l’ensemble de l’imaginaire collectif de Microsoft, ils ont appelé le langage HLSL (High Level Shading Language). Mais leur approche des langues était fondamentalement différente.
Le plus gros problème avec le langage de shader de 3D Labs était qu'il était intégré. Voir, HLSL était un langage défini par Microsoft. Ils ont publié un compilateur et généré un code d'assemblage Shader Model 2.0 (ou des modèles de shader ultérieurs), que vous alimenteriez dans D3D. Dans les jours D3D v9, HLSL n'a jamais été directement touché par D3D. C'était une belle abstraction, mais c'était purement facultatif. Et un développeur a toujours eu l’occasion de passer derrière le compilateur et d’ajuster le résultat pour obtenir des performances maximales.
Le langage 3D Labs n'avait rien de tout cela. Vous avez donné au conducteur le langage semblable à C et cela a produit un shader. Fin de l'histoire. Pas un assembleur, pas quelque chose qui nourrit autre chose. L'objet OpenGL réel représentant un shader.
Cela signifiait que les utilisateurs d'OpenGL étaient ouverts aux caprices des développeurs qui venaient de se familiariser avec la compilation de langages de type assembleur. Les bogues du compilateur ont été généralisés dans le GLSL (OpenGL Shading Language) récemment baptisé. Pire, si vous réussissiez à faire compiler correctement un shader sur plusieurs plates-formes (ce qui n'est pas une mince affaire), vous restiez soumis aux optimiseurs du jour. Lesquelles n'étaient pas aussi optimales qu'elles pourraient l'être.
Bien que c’était la plus grande faiblesse de GLSL, ce n’était pas la seule. De loin .
Dans D3D et dans les langages d'assemblage plus anciens d'OpenGL, vous pouvez mélanger et assortir des shaders de vertex et de fragment (pixel). Tant qu'ils communiquent avec la même interface, vous pouvez utiliser n'importe quel vertex shader avec n'importe quel fragment compatible. Et il y avait même des niveaux d'incompatibilité qu'ils pouvaient accepter; un vertex shader pourrait écrire un résultat que le fragment shader n'a pas lu. Et ainsi de suite.
GLSL n'avait rien de tout cela. Les shaders de vertex et de fragment ont été fusionnés dans ce que 3D Labs a appelé un "objet programme". Donc, si vous voulez partager des programmes de sommets et de fragments, vous devez créer plusieurs objets de programme. Et cela a causé le deuxième plus gros problème.
Vous voyez, 3D Labs pensait qu'ils étaient intelligents. Ils ont basé le modèle de compilation de GLSL sur C / C ++. Vous prenez un fichier .c ou .cpp et le compilez dans un fichier objet. Ensuite, vous prenez un ou plusieurs fichiers objet et les liez dans un programme. C'est ainsi que GLSL se compile: vous compilez votre shader (sommet ou fragment) en un objet shader. Ensuite, vous placez ces objets shader dans un objet programme et vous les liez ensemble pour former votre programme réel.
Bien que cela ait permis des idées intéressantes potentielles comme avoir des shaders "de bibliothèque" contenant du code supplémentaire que les shaders principaux pouvaient appeler, cela signifiait en pratique que les shaders étaient compilés deux fois . Une fois au stade de la compilation et une fois au stade de la liaison. Le compilateur de NVIDIA en particulier était connu pour exécuter essentiellement la compilation deux fois. Cela n'a pas généré une sorte d'intermédiaire de code objet; il l'a juste compilé une fois et a jeté la réponse, puis l'a compilé à nouveau au moment de la liaison.
Ainsi, même si vous souhaitez lier votre vertex shader à deux fragments différents, vous devez effectuer beaucoup plus de compilation que dans D3D. D'autant que la compilation d'un langage de type C a été réalisée hors ligne , et non au début de l'exécution du programme.
Il y avait d'autres problèmes avec GLSL. Peut-être semble-t-il erroné de blâmer 3D Labs, puisque l'ARB a finalement approuvé et incorporé le langage (mais rien de plus de son initiative "OpenGL 2.0"). Mais c'était leur idée.
Et voici la partie vraiment triste: 3D Labs avait raison (principalement). GLSL n’est pas un langage d’ombrage à base de vecteur comme HLSL l’était à l’époque. En effet, le matériel de 3D Labs était un matériel scalaire (similaire au matériel NVIDIA moderne), mais ils étaient finalement dans la même direction que de nombreux fabricants de matériel.
Ils avaient raison de choisir un modèle de compilation en ligne pour un langage de "haut niveau". D3D a même opté pour cela.
Le problème était que 3D Labs avait raison au mauvais moment . Et en essayant d'appeler trop tôt l'avenir, en essayant d'être à l'épreuve du futur, ils ont écarté le présent . Cela ressemble à la manière dont OpenGL a toujours eu la possibilité d’utiliser la fonctionnalité T & L. Sauf que le pipeline T & L d'OpenGL était toujours utile avant le matériel T & L, tandis que GLSL était un passif avant que le monde ne le rattrape.
GLSL est une bonne langue maintenant . Mais pour le moment? C'était horrible. Et OpenGL en a souffert.
Tomber vers l'apothéose
Bien que je maintienne que 3D Labs a porté le coup fatal, c’est l’ARB lui-même qui enfoncerait le dernier clou dans le cercueil.
C'est une histoire dont vous avez peut-être entendu parler. À l'époque d'OpenGL 2.1, OpenGL rencontrait un problème. Il y avait beaucoup d'héritage cruel. L'API n'était plus facile à utiliser. Il y avait 5 façons de faire les choses, et aucune idée de ce qui était le plus rapide. Vous pouvez "apprendre" OpenGL avec de simples tutoriels, mais vous n'avez pas vraiment appris l'API OpenGL qui vous donnait des performances et une puissance graphique réelles.
Ainsi, l'ARB a décidé de tenter une autre réinvention d'OpenGL. Cela ressemblait à "OpenGL 2.0" de 3D Labs, mais c'était mieux car ARB était derrière. Ils l'appelaient "Longs Peak".
Pourquoi est-il si difficile de prendre un peu de temps pour améliorer l'API? C'était mauvais parce que Microsoft s'était laissé vulnérable. Voir, ce fut au moment du passage Vista.
Avec Vista, Microsoft a décidé d’apporter certaines modifications indispensables aux pilotes d’affichage. Ils ont obligé les pilotes à se soumettre au système d'exploitation pour la virtualisation de la mémoire graphique et diverses autres choses.
Bien que l’on puisse en débattre sur le bien-fondé ou sur la possibilité de le faire, il n'en reste pas moins que Microsoft considère D3D 10 comme étant Vista (et supérieur) uniquement. Même si votre matériel était compatible avec D3D 10, vous ne pouvez pas exécuter d’applications D3D 10 sans exécuter également Vista.
Vous vous souviendrez peut-être aussi que Vista ... hum, disons simplement que cela n'a pas bien fonctionné. Vous disposiez donc d’un système d’exploitation sous-performant, d’une nouvelle API qui ne fonctionnait que sur ce système d’exploitation et d’une nouvelle génération de matériel nécessitant cette API et ce système d’exploitation pour être plus rapide que la génération précédente.
Cependant, les développeurs pouvaient accéder aux fonctionnalités D3D 10-class via OpenGL. Eh bien, ils le pourraient si la CRÉA n’avait pas été occupée par Longs Peak.
Fondamentalement, la CRÉF a consacré un bon travail d’une année et demie à deux ans à améliorer l’API. Au moment où OpenGL 3.0 est sorti, l'adoption de Vista était terminée, Win7 était sur le point de laisser Vista derrière eux, et la plupart des développeurs de jeux ne se souciaient de toute façon pas des fonctionnalités de la classe D3D-10. Après tout, le matériel D3D 10 exécutait parfaitement les applications D3D 9. Et avec la montée en puissance des ports de console à console (ou de développeurs de PC qui se lancent dans le développement de consoles. Faites votre choix), les développeurs n’avaient pas besoin de fonctionnalités D3D 10.
Désormais, si les développeurs avaient déjà accès à ces fonctionnalités via OpenGL sur des machines WinXP, le développement OpenGL aurait peut-être reçu un coup de pouce bien nécessaire. Mais les ARB ont raté leur chance. Et voulez-vous connaître le pire?
Bien qu'ils aient passé deux précieuses années à tenter de reconstruire l'API à partir de zéro ... ils ont quand même échoué et sont simplement revenus au statu quo (à l'exception d'un mécanisme de dépréciation).
Ainsi, non seulement la CRÉA a raté une fenêtre d'opportunité cruciale , mais elle n'a même pas accompli la tâche qui lui a fait perdre de vue cette occasion. Quasiment épique échouer tout autour.
Et c'est l'histoire d'OpenGL contre Direct3D. Une histoire d'opportunités manquées, de stupidité flagrante, d'aveuglement volontaire et de folie simple.