👨‍👩‍👧 🧕🏻 🌎 Direct3D vs OpenGL: une histoire de confrontation 👩‍👩‍👦 📼 🗡️

À ce jour, il y a un débat sur Internet pour savoir quelle API graphique est la meilleure: Direct3D ou OpenGL? Malgré leur nature religieuse, de telles batailles verbales donnent des résultats utiles sous la forme de bonnes revues historiques du développement de graphiques accélérés par matériel.

Le but de cet article est de traduire une de ces excursions dans l'histoire.écrit par Jason L. McKesson en réponse à la question "Pourquoi les développeurs de jeux préfèrent-ils Windows?" Il est peu probable que ce texte réponde à la question posée, mais il décrit l'histoire du développement et la confrontation des deux API graphiques les plus populaires d'une manière très colorée et assez détaillée, j'ai donc conservé le balisage de l'auteur dans la traduction. Le texte a été écrit à la mi-2011 et couvre une période commençant peu de temps avant l'avènement de Direct3D et jusqu'au moment de la rédaction. L'auteur du texte original est un développeur de jeux expérimenté, un participant actif à StackOverflow et le créateur d'un manuel complet sur la programmation graphique 3D moderne. Donnons donc la parole à Jason.

Préface

Avant de commencer, je voudrais dire que j'en sais plus sur OpenGL que sur Direct3D. Dans ma vie, je n'ai pas écrit une seule ligne de code en D3D, mais j'ai écrit des manuels OpenGL. Mais ce dont je veux parler n'est pas une question de préjugés, mais d'histoire.

La naissance du conflit

Une fois, au début des années 90, Microsoft a regardé autour de lui. Ils ont vu que SNES et Sega Genesis sont très cool, vous pouvez jouer à beaucoup de jeux d'action et tout ça. Et ils ont vu le dos. Les développeurs ont écrit des jeux dosovskie comme console: près du fer. Cependant, contrairement aux consoles, où le développeur savait quel type de matériel l'utilisateur aurait, les développeurs DOS ont été obligés d'écrire sous de nombreuses configurations. Et c'est beaucoup plus compliqué qu'il n'y paraît.

Mais Microsoft avait un plus gros problème: Windows. Vous voyez, Windows voulait posséder le matériel complètement, contrairement à DOS, qui permettait aux développeurs de faire n'importe quoi. La possession de fer est nécessaire pour l'interaction entre les applications. Mais ce genre d'interaction est exactement ce qu'ils détestent.les développeurs de jeux car il consomme de précieuses ressources qu'ils pourraient utiliser pour toutes sortes de choses intéressantes.

Pour promouvoir le développement de jeux sur Windows, Microsoft avait besoin d'une API uniforme qui serait de bas niveau, fonctionnerait sur Windows sans perte de performances et serait compatible avec divers matériels . Une API unique pour les graphiques, le son et les périphériques d'entrée.

Ainsi DirectX est né.

Des accélérateurs 3D sont apparus quelques mois plus tard. Et Microsoft a eu des ennuis. Le fait est que DirectDraw, un composant graphique de DirectX, ne fonctionnait qu'avec des graphiques 2D: il allouait de la mémoire graphique et effectuait des opérations de bits rapides entre différents secteurs de la mémoire.

Par conséquent, Microsoft a acheté un logiciel tiers et l'a transformé en version Direct3D 3. Il a été grondéabsolument tout. Et il y avait une raison: la lecture du code sur D3D v3 ressemblait à un décodage du langage écrit d'une ancienne civilisation éteinte.

Le vieil homme John Carmack chez Id Software a regardé cette honte, a dit "Oui, c'est allé ...", et a décidé d'écrire en utilisant une autre API: OpenGL.

Cependant, l'autre côté de cette histoire déroutante était que Microsoft a travaillé avec SGI pour implémenter OpenGL pour Windows. L'idée était d'attirer les développeurs d'applications GL typiques pour les postes de travail: CAO, systèmes de modélisation et similaires. Les jeux étaient la dernière chose à laquelle ils pensaient. Cela concernait principalement Windows NT, mais Microsoft a décidé d'ajouter également OpenGL à Windows 95.

Pour attirer les développeurs de logiciels pour postes de travail sous Windows, Microsoft a décidé de les soudoyer avec un accès à de nouveaux accélérateurs 3D. Ils ont implémenté un protocole pour les pilotes clients installés: une carte graphique pourrait remplacer le logiciel OpenGL de Microsoft par leur implémentation matérielle. Le code utilisait automatiquement le matériel OpenGL, le cas échéant.

Cependant, à l'époque, les cartes graphiques grand public ne prenaient pas en charge OpenGL. Cela n'a pas empêché Carmack de porter Quake vers OpenGL sur un poste de travail SGI. Dans le fichier readme de GLQuake, vous pouvez lire ce qui suit:

, glquake OpenGL, texture objects. , , , . - , .

( 1997), opengl , glquake , intergraph realizm. 3dlabs , . 3dlabs glint permedia NT , glquake 3dlabs.

3dfx opengl32.dll, glquake, opengl. opengl- , « glquake».

Ce fut la naissance des pilotes miniGL. Ils ont finalement évolué vers des implémentations OpenGL à part entière dès que le matériel est devenu suffisamment puissant pour prendre en charge cette fonctionnalité dans le matériel. nVidia a été le premier à proposer une implémentation complète d'OpenGL. D'autres fournisseurs étaient encore lents, ce qui était l'une des raisons de la transition vers Direct3D, soutenue par une gamme plus large d'équipements. À la fin, seuls nVidia et ATI (qui est maintenant AMD) sont restés, et les deux avaient de bonnes implémentations OpenGL.

L'aube d'OpenGL

Ainsi, les participants sont définis: Direct3D contre OpenGL. C'est vraiment une histoire incroyable, compte tenu de la gravité du D3D v3.

L'OpenGL Architectural Review Board (ARB) est l'organisation responsable de la maintenance et du développement d'OpenGL. Ils publient de nombreuses extensions, contiennent un référentiel avec des extensions et créent de nouvelles versions de l'API. ARB est un comité composé d'un grand nombre d'acteurs de l'industrie de l'infographie et de certains fabricants de systèmes d'exploitation. Apple et Microsoft étaient également membres d'ARB à différents moments.

3Dfx entre en scène avec son Voodoo2. Il s'agit de la première carte vidéo qui vous permet de faire du multitexturing, qui n'était pas fourni auparavant dans OpenGL. Alors que 3Dfx était fortement opposé à OpenGL, nVidia, le prochain fabricant de la puce multitexturing (TNT1), était fou d'OpenGL. ARB a ensuite publié l'extension GL_ARB_multitexture, qui permettait d'accéder à plusieurs textures.

Pendant ce temps, Direct3D v5 apparaît. Maintenant, D3D est vraiment devenu une API , pas une sorte de non-sens. Quel est le problème? En l'absence de multitexturation.

Oups

Mais cela n'a pas causé autant d'inconvénients que cela pouvait se produire, car presque personne n'utilisait de textures multiples. Le multitexturing ne nuit presque pas aux performances et, dans de nombreux cas, la différence est invisible dans le contexte du multi-passage. Et bien sûr, les développeurs de jeux aiment beaucoup que leurs jeux fonctionnent en toute confiance sur l'ancien matériel, qui ne prend pas en charge plusieurs textures, de nombreux jeux sont donc sortis sans lui.

D3D poussa un soupir de soulagement.

Le temps a passé et nVidia a déployé la GeForce 256 (à ne pas confondre avec la toute première GeForce GT-250), interrompant la lutte sur le marché des cartes graphiques pour les deux prochaines années. Le principal avantage concurrentiel de cette carte était la capacité à effectuer des transformations de sommets et d'éclairage (transformation et éclairage, T&L) dans le matériel. Mais ce n'est pas tout: nVidia OpenGL aimait tellement que leur T & L-moteur effectivement été OpenGL. Presque littéralement! Si je comprends bien, certains de leurs registres ont reçu directement des valeurs numériques de variables de type GLenum.

Direct3D v6 sort. Enfin, plusieurs textures sont arrivées à temps ... mais sans le T&L matériel. OpenGL toujoursil y avait un pipeline T&L, bien qu'avant GeForce 256, il était implémenté dans un logiciel. Par conséquent, pour nVidia, il s'est avéré assez simple de refaire l'implémentation logicielle en une solution matérielle. Dans D3D, le matériel T&L n'apparaissait que dans la septième version.

Dawn of the Shader Age, OpenGL dans le noir

Puis vint GeForce 3. En même temps, beaucoup de choses intéressantes se sont produites.

Microsoft a décidé qu'ils n'allaient plus être en retard. Par conséquent, au lieu de regarder ce que nVidia fera et de copier leur développement déjà post-factum, Microsoft a pris une décision étonnante: allez parler. Et ils sont tombés amoureux, et ils ont obtenu une petite console commune.

Le divorce bruyant s'est produit plus tard, mais c'est une histoire complètement différente.

Pour le marché des PC, cela signifie que GeForce 3 est sorti simultanément avec D3D v8, et il est facile de voir comment GeForce 3 a affecté les shaders D3D v8. Les pixel shaders de Shader Model 1.0 étaient trèsconsidérablement affûté pour les équipements nVidia. Aucune tentative n'a été faite pour faire abstraction de nVidia du fer. Le Shader Model 1.0 a été conçu pour la GeForce 3.

Lorsque ATI a fait irruption dans la course aux performances graphiques avec sa Radeon 8500, il y avait un problème. Le pipeline Radeon 8500 pixels s'est avéré être plus puissant que le nVidia. Par conséquent, Microsoft a publié le Shader Model 1.1, qui était essentiellement à quoi

sert le 8500. Cela ressemble à une défaite D3D, mais le succès et l'échec sont des termes relatifs. En fait, un échec épique attendait OpenGL.

NVidia aimait beaucoup OpenGL, donc après la sortie de GeForce 3, ils ont sorti tout un tas d'extensions pour OpenGL. Propriétaireextensions qui ne fonctionnaient que sur nVidia. Naturellement, lorsque la carte 8500 est apparue, elle ne pouvait en utiliser aucune.

Ainsi, sur D3D 8, vous pouvez au moins exécuter des shaders SM 1.0. Bien sûr, pour utiliser toute la fraîcheur du 8500, j'ai dû écrire de nouveaux shaders, mais le code a au moins fonctionné .

Pour obtenir des shaders sur la Radeon 8500 en OpenGL, ATI a dû développer plusieurs extensions pour OpenGL. Extensions propriétaires qui ne fonctionnaient que sur ATI. En conséquence, pour que les développeurs puissent déclarer qu'ils ont vissé des shaders à leur moteur, ils ont dû écrire un code séparé pour nVidia et un code séparé pour ATI.

Vous pouvez demander: "Et où était le comité ARB qui devrait soutenir OpenGL à flot?" Et c'est là que se retrouvent de nombreux comités: ils étaient assis et stupides.

Veuillez noter que j'ai mentionné ARB_multitexture ci-dessus car cette extension est profondément impliquée dans toute la situation. Il a semblé à un observateur extérieur qu'ARB voulait généralement éviter l'idée de shaders. Ils ont décidé que s'ils injectaient suffisamment de configurabilité dans un pipeline fixe, alors ses capacités seraient équivalentes à celles d'un pipeline de shader programmable.

ARB a publié les extensions une par une. Chaque extension avec les mots «texture_env» dans le nom était une tentative de patcher cette conception vieillissante. Regardez la liste des extensions: huit de ces extensions ont été publiéesmorceaux, et beaucoup d'entre eux ont été traduits dans la fonctionnalité de base OpenGL.

À cette époque, Microsoft faisait partie d'ARB et ne l'a laissé que pour la sortie de D3D 9, donc Microsoft a peut-être saboté OpenGL d'une manière ou d'une autre. Personnellement, je doute de cette théorie pour deux raisons. Premièrement, ils devraient obtenir le soutien des autres membres du Comité, car chaque membre ne dispose que d'une voix. Deuxièmement, et plus important encore, le Comité n'a pas eu besoin de l'aide de Microsoft pour tout foutre en l'air, dont nous verrons la preuve plus tard.

En conséquence, ARB, très probablement sous la pression d'ATI et de nVidia (les deux sont des participants actifs), s'est finalement réveillé et a introduit des shaders d'assembleur dans la norme.

Vous voulez une histoire encore plus farfelue?

T&L matériel. C'est ce qu'OpenGL avait à l'origine.. Pour obtenir les meilleures performances T&L matérielles possibles, vous devez stocker les données de sommet sur le GPU. Pourtant, le GPU est le principal consommateur de données de vertex.

Dans D3D v7, Microsoft a introduit le concept de tampons de vertex, qui alloue des morceaux de mémoire dans le GPU et y place des données de vertex.

Vous voulez savoir quand une fonctionnalité équivalente est apparue dans OpenGL? Oui, nVidia, en tant que plus grand fan d'OpenGL, a publié son extension pour stocker des tableaux de vertex sur le GPU à l'époque de la sortie de GeForce 256. Mais quand ARB a-t-il introduit une telle fonctionnalité?

Deux ans plus tard. C'était aprèsde la façon dont il a approuvé les vertex et les shaders de fragment (pixel en termes de D3D). Il a fallu tellement de temps à ARB pour développer une solution multiplateforme pour le stockage des données de vertex dans la mémoire du GPU. Et c'est ce dont T&L a besoin pour atteindre des performances maximales.

Une langue pour tous les tuer

Ainsi, OpenGL est cassé depuis un certain temps. Il n'y avait pas de shaders multiplateforme et de stockage de vertex indépendant du matériel dans le GPU, tandis que les utilisateurs de D3D appréciaient les deux. Cela pourrait-il empirer?

On pourrait dire que oui. Rencontre: 3D Labs .

Vous demandez: qui sont-ils? C'est une entreprise morte que je considère comme le véritable tueur d'OpenGL. Bien sûr, l'échec général du Comité a rendu OpenGL vulnérable, alors qu'il était censé déchirer le D3D en lambeaux. Mais à mon avis, 3D Labs est peut-être la seule raison de la position actuelle d'OpenGL sur le marché. Qu'ont-ils fait pour cela?

Ils ont développé un langage de shader pour OpenGL.

3D Labs était une entreprise mourante. Leurs GPU coûteux ont été évincés du marché des stations de travail par la pression toujours croissante de nVidia. Et contrairement à nVidia, les 3D Labs n'ont pas été introduits sur le marché grand public; La victoire de nVidia signifierait la mort de 3D Labs.

Que s'est-il finalement passé?

Dans un effort pour être à flot dans un monde qui n'a pas besoin de leurs produits, 3D Labs s'est présenté à la Game Developer Conference avec une présentation de ce qu'ils ont appelé "OpenGL 2.0". C'était une API OpenGL réécrite à partir de zéro. Et cela avait du sens, car à cette époque, l'API OpenGL était pleine de déchets (qui, cependant, reste là à ce jour). Regardez au moins comment le chargement et la liaison des textures sont ésotériquement.

Une partie de leur proposition était un langage plus nuancé. Oui, il l'est. Cependant, contrairement aux extensions multiplateformes existantes, leur langage de shader était «de haut niveau» (C est un niveau élevé pour le langage de shader).

Dans le même temps, Microsoft travaillait sur son propre langage de shader. Ce qu'ils, y compris toute leur imagination collective, appelaient ... High Level Shader Language (HLSL). Mais leur approche de la langue était fondamentalement différente.

Le plus gros problème avec 3D Labs était qu'il était intégrable. Microsoft a complètement déterminé sa propre langue. Ils ont publié un compilateur qui a généré le code d'assemblage pour les shaders SM 2.0 (ou supérieur), qui, à son tour, pourrait être alimenté en D3D. À l'époque de D3D v9, HLSL n'a jamais touché directement D3D. C'était une bonne abstraction mais facultative. Le développeur a toujours eu l'occasion de prendre l'échappement du compilateur et de le peaufiner pour des performances maximales.

3D Labs n'avait rien de tout cela. Vous donnez au pilote un langage de type C, et cela crée un shader. C’est tout. Pas de shader assembleur, rien qui puisse être alimenté à autre chose. Seul un objet OpenGL représentant un shader.

Pour les utilisateurs d'OpenGL, cela signifiait qu'ils étaient sujets aux caprices des développeurs d'OpenGL qui venaient d'apprendre à compiler des langages de type assembleur. Les compilateurs de langage de shader OpenGL (GLSL) font rage à propos des bogues. Pour aggraver les choses, si vous pouviez obtenir le shader à compiler correctement sur différentes plates-formes (ce qui en soi était une grande réussite), il était toujours soumis à des optimiseurs de ces temps qui n'étaient pas aussi optimaux qu'ils pourraient l'être.

C'était un gros mais pas le seul inconvénient de GLSL. Loin du seul.

Dans D3D, comme dans les anciens langages d'assembleur OpenGL, vous pouvez mélanger et faire correspondre les vertex et les shaders de fragments de toutes les manières possibles. Vous pouvez utiliser n'importe quel vertex shader avec n'importe quel fragment shader compatible s'ils interagissent via la même interface. De plus, même une certaine incompatibilité était autorisée: par exemple, le vertex shader pouvait produire une valeur qui n'était pas utilisée par le fragment shader.

Il n'y avait rien de tel dans GLSL. Les shaders de vertex et de fragments se sont fusionnés, formant quelque chose appelé "objet logiciel" 3D Labs. Par conséquent, pour l'utilisation conjointe de plusieurs vertex et fragments shaders dans différentes combinaisons, il était nécessaire de créer plusieurs objets de programme. Cela a causé le deuxième plus gros problème.

3D Labs pensait qu'ils étaient les plus intelligents. Ils ont pris C / C ++ comme base pour le modèle de compilation GLSL. C'est lorsque vous prenez un fichier c et le compilez dans un fichier objet, puis prenez plusieurs fichiers objet et composez-les dans un programme. Voici comment GLSL compile: vous compilez d'abord un vertex ou un fragment shader en un objet shader, puis vous placez ces objets dans un objet programme et vous les assemblez pour finalement former un programme.

En théorie, cela a permis à des éléments sympas comme les shaders de «bibliothèque» d'apparaître qui contiennent du code appelé par le shader principal. En pratique, cela a abouti à la compilation de deux shaders: Une fois au stade de la compilation et une deuxième fois au stade de la compilation. En particulier, le compilateur de nVidia était célèbre pour cela. Il n'a généré aucun code objet intermédiaire; il a compilé au début, jeté le résultat et compilé à nouveau au stade de la compilation.

Ainsi, afin d'attacher le vertex shader à deux fragments de shaders différents, il a fallu en compiler beaucoup plus qu'en D3D. Surtout si l'on considère que toute la compilation se fait hors ligne , et pas avant que le programme ne soit exécuté directement.

GLSL a eu d'autres problèmes. Il serait peut-être faux de blâmer toute la faute sur 3D Labs, car finalement ARB a approuvé et inclus le langage des shaders dans OpenGL (mais rien d'autre des suggestions de 3DLabs). Cependant, l'idée originale était toujours pour 3D Labs.

Et maintenant, la chose la plus triste: les laboratoires 3D avaient raison (surtout). GLSL n'est pas un langage vectoriel comme HLSL à cette époque. Cela est arrivé parce que le matériel de 3D Labs était scalaire (comme le matériel moderne de nVidia), et ils avaient tout à fait raison de choisir la direction que de nombreux fabricants d'équipements ont ensuite suivie.

Ils avaient raison avec le choix du modèle de compilation pour le langage "de haut niveau". Même D3D est finalement arrivé à cela.

Le problème est que 3D Labs avait raison au mauvais moment . Et dans leurs tentatives d'entrer dans l'avenir prématurément, dans leurs tentatives de se préparer pour l'avenir, ils ont mis de côté le présent. Cela ressemble à la fonctionnalité T&L d'OpenGL, qui a toujours été présente. Sauf que le pipeline OpenGL T&L était utileet avant l'avènement du matériel T&L, GLSL était un fardeau avant que le reste du monde ne le rattrape.

GLSL est une bonne langue maintenant . Mais qu'était-ce à ce moment-là? Il était terrible. Et OpenGL en a souffert.

En route vers l'apothéose

Je soutiens l'idée que 3D Labs a porté un coup mortel à OpenGL, mais le dernier clou dans le cercueil a été marqué par ARB lui-même.

Vous avez peut-être entendu cette histoire. À l'époque d'OpenGL 2.1, OpenGL avait de gros problèmes. Il portait une énorme charge de compatibilité. L'API n'était plus facile à utiliser. Une chose pourrait être faite de cinq manières différentes et on ne sait pas laquelle est la plus rapide. Vous pouvez "apprendre" OpenGL avec des didacticiels simples, mais vous n'avez pas appris l'OpenGL qui offre une puissance et des performances graphiques véritables.

ARB a décidé de faire une autre tentative pour inventer OpenGL. C'était comme «OpenGL 2.0» de 3D Labs, mais mieux parce que ARB était derrière cette tentative. Ils l'ont appelé "Longs Peak".

Qu'y a-t-il de si mal à passer un peu de temps à améliorer l'API? La mauvaise nouvelle est que Microsoft est dans une position assez précaire. C'était le moment de passer à Vista.

Sous Vista, Microsoft a décidé d'apporter des modifications attendues depuis longtemps aux pilotes graphiques. Ils ont forcé les pilotes à se tourner vers l'OS pour la virtualisation de la mémoire graphique et bien d'autres.

Vous pouvez discuter longtemps sur les mérites de cette approche, et si elle était même possible, mais le fait demeure: Microsoft a fait D3D 10 uniquement pour Vista et supérieur. Même sur un matériel compatible D3D, il était impossible d'exécuter une application D3D sans Vista.

Vous vous souvenez peut-être que Vista ... disons que cela n'a pas très bien fonctionné. Nous avions donc un système d'exploitation tranquille, une nouvelle API qui ne fonctionnait que sur ce système d'exploitation et une nouvelle génération de matériel qui avait besoin de cette API et de ce système d'exploitation pour faire plus que simplement dépasser la génération précédente en termes de performances.

Cependant, les développeurs pourraient utiliser la fonctionnalité de niveau D3D 10 via OpenGL. Autrement dit, ils pourraient le faire si ARB n'était pas occupé à travailler sur Long Peaks.

ARB a passé un bon an et demi à deux ans à travailler sur l'amélioration de l'API. Au moment de la sortie d'OpenGL 3.0, la transition vers Vista était terminée, Windows 7 était en route et les développeurs de jeux ne se souciaient plus de la fonctionnalité du niveau D3D 10. Au final, l'équipement pour D3D 10 fonctionnait parfaitement avec les applications sur D3D 9. Avec l'augmentation du rythme de portage du PC vers console (ou avec la transition des développeurs PC vers le marché des consoles), les développeurs avaient de moins en moins besoin de la fonctionnalité de D3D 10.

Si les développeurs pouvaient accéder à cette fonctionnalité même sur Windows XP, le développement d'OpenGL pourrait obtenir une vivacité de vie. Mais ARB a raté cette occasion. Voulez-vous savoir quel est le pire?

ARB a échouéinventer l'API à partir de zéro malgré deux années précieuses à essayer. Par conséquent, ils ont renvoyé le statu quo, ajoutant seulement un mécanisme pour déclarer la fonctionnalité obsolète.

En conséquence, ARB a non seulement raté les opportunités clés , mais a également omis de faire le travail qui les a conduits à cette omission. Ce fut un échec épique dans toutes les directions.

C'est l'histoire de la confrontation entre OpenGL et Direct3D. L'histoire d'opportunités manquées, de la plus grande stupidité, de l'insouciance délibérée et des absurdités banales.