Qu'est-ce qu'une API ? Comment les graphismes sont-ils générés dans les jeux vidéo auxquels nous jouons chaque jour ? Quelles différences y a-t-il entre les différentes API pour générer du graphisme ? Quelles sont les plus performantes et les plus pratiques à utiliser ? Ce mémoire sert à illustrer les Application Programming Interface 3D les plus utilisées, comprendre comment elles fonctionnent et à les comparer pour déterminer quelles sont les plus aptes à être utilisées pour le jeu vidéo.
Une Application Programming Interface est un ensemble normalisé de classes, méthodes et fonctions qui sert de façade par laquelle un logiciel offre ses services à un autre logiciel. Le programmeur qui utilise une API se doit de connaître les différentes manières d'interagir avec les autres logiciels. Les nombreuses technologies que le programmeur peut développer, tels les systèmes d'exploitation, les systèmes de gestion de base de données et même les langages de programmation comportent une interface de programmation. Une interface de programmation est souvent mise en œuvre par une bibliothèque logicielle qui fournit une solution à un problème informatique en faisant abstraction de son fonctionnement.
Nous nous focaliseront principalement sur les API 3D les plus connues, telles OpenGL ou Direct3D après avoir dressé une liste des API 3D bas niveau et haut niveau qui ont été créées jusqu'à aujourd'hui.
Toutes les API 3D prennent en charge ce que l'on appelle le « pipeline de rendu ». Le pipeline 3D est la succession des opérations réalisées par une carte graphique nécessaires au rendu d'un lot de données sur un tampon chromatique ensuite affiché à l'écran. La plupart des pipelines 3D utilisent la technique de rastérisation qui tire parti de l'accélération matérielle fournie par les cartes graphiques. A noter que les étapes suivantes peuvent légèrement varier entre les différentes API et leurs nombreuses versions.
Les triangles ont toujours été la base avec laquelle les scènes 3D en temps réel sont dessinées. Le programme principal remplis des buffers de la mémoire gérés par l'API avec des tableaux de vertex. Ces vertex sont projetés dans l'espace écran (screen space) par les vertex shaders, assemblés en triangles et « rasterizés » (pixellisés) en fragments de la taille d'un pixel (par conséquent, 1 fragment = 1 pixel). Ensuite, ces fragments se voient assigner des couleurs (par des fragment shaders) et sont dessinés sur le framebuffer.
Les GPU modernes doivent leur flexibilité au fait de déléguer les étapes de « projection dans le screen-space » (vertex shader) et « assignation d'une couleur » (fragment shader) à des petits programmes, envoyés au GPU, appelés shaders.
Une tâche de rendu (rendering job) apparaît dans le pipeline sous la forme d'un ou plusieurs groupes (set) de vertex buffers. Chaque groupe est rempli avec des tableaux d'attributs par vertex, appelés vertex attributes. Ces attributs sont utilisés en tant qu'input du vertex shader, ils incluent la position des vertex dans l'espace 3D et au moins un set de coordonnées de textures (UV) qui projettent le vertex sur au moins une texture. Les groupes de vertex fournissant des données au rendering job dont collectivement appelés les vertex arrays. Lorsqu'un render job est lancé, un tableau d'éléments supplémentaire (element array) est fourni aux vertex arrays : un tableau d'index qui indique quels sont les vertex qui vont entrer dans le pipeline, dont l'ordre contrôle la manière selon laquelle les vertex sont assemblés en triangle.
Un rendering job a également des « états uniformes » (uniform states) qui fournissent au shader des données partagées en lecture seule à toutes les étapes « programmables » du pipeline. Cela permet au shader de prendre des paramètres qui ne changent pas entre les vertex. Les uniform states peuvent être des textures (des array de 1,2 ou 3 dimensions) qui peuvent être utilisés par les shaders. Ces textures sont généralement utilisées pour appliquer des images sur des surfaces, mais aussi comme simples tableaux (lookup tables) pour des fonctions pré-calculées ou bien pour stocker d'autres informations (normales, opacité, etc…) pouvant être utilisées pour divers types d'effets.
Le GPU commence en lisant chaque vertex sélectionné parmi les tableaux de vertex en le passant dans le vertex shader, un programme qui prend un set de vertex attributes en argument et renvoie un nouveau set de vertex attributes qui définit autant de valeurs que prendra en compte le rasterizer. Le vertex shader calcule la position des vertex projetés sur le screen space et peut renvoyer aussi d'autres valeurs comme la couleur ou les coordonnées de textures, qui sont ensuite interpolées par le rasterizer entre chaque sommet (le long de la surface).
Le GPU relit ensuite les vertex projetés sous forme de triangles, en les prenant dans l'ordre spécifié par l'element array et en les groupant par paquets de trois. Les vertices peuvent ensuite être groupés de trois façons différentes :
Le rasterizer prend chaque triangle, le découpe, rejette les éléments qui sont en dehors de l'écran et brise les petites parties restantes en fragments de la taille d'un pixel. Les ouputs du vertex shader sont interpolés le long de la surface rasterisée de chaque triangle en assignant un dégradé des valeurs à chaque pixel.
Les fragments générés passent ensuite dans un autre programme appelé le fragment shader. Il reçoit les valeurs de l'output du vertex shader (précédemment interpolés par le rasterizer). La couleur et la profondeur en output sont écrites dans le framebuffer, la plupart des opérations du fragment shader concernant le texture mapping et l'éclairage. Comme le fragment shader fonctionne indépendamment pour chaque pixel dessiné, il peut effectuer des effets spéciaux plus sophistiqués, mais il est également le point le plus sensible en termes de performances dans le pipeline graphique.
Le framebuffer est la destination de l'output d'une tâche de rendu, ce qui est bien plus qu'une simple image 2D : en étant combinée à au moins un color buffer, un framebuffer peut avoir un depth buffer et/ou un stencil buffer (un masque), chacun pouvant éventuellement filtrer les fragment shaders avant qu'ils ne soient dessinés dans le framebuffer : un test de profondeur (depth testing) pour éventuellement ignorer des fragments, puis un test sur le stencil buffer (stencil testing) servant à contraindre une zone particulière du framebuffer, pour « découper » le rendering job.
OpenGL est lancé en 1992 par Silicon Graphics, qui à l'époque pilotait les composants graphiques qui étaient utilisés dans leurs stations de travail haut de gamme. Cette API multiplateforme est très utilisée dans de nombreuses applications dont les jeux vidéo. Elle sert à communiquer avec les GPU programmables, dans le but de rendre des images 3D en temps réel. Après la démocratisation des cartes graphiques par GLQuake, OpenGL est devenu un standard aux côtés de Direct3D.
En 2006, Khronos Group obtient les droits d'OpenGL, la met à jour, la développe pour le web (WebGL et OpenGL ES) et démocratisent des librairies implémentant du langage C, permettant au GPU d'être utilisé pour des calculs génériques. On parle alors de « calculs génériques sur le processeur graphique », autrement dit GPGPU, comme OpenCL de Khronos Group. Ces librairies ne remplacent pas les API mais sont utilisées à leurs côtés, en partageant des buffers de la mémoire du GPU avec les API et transmettre des données entre les programmes GPU et le pipeline graphique. Une version nommée OpenGL ES a été conçue spécifiquement pour les applications embarquées (téléphones portables, agenda de poche, consoles de jeux portables…).
OpenGL a des méthodes d'affichage très rapides et il est toujours premier à avoir accès aux nouvelles fonctionnalités GPU via les extensions des fabricants. OpenGL donne au programmeur un accès direct à toutes les nouvelles fonctionnalités graphiques sur toutes les plateformes.
OpenGL est pris en charge sur de nombreuses plateformes de jeu, incluant Mac, Windows, Linux, PS3, Wii, iPhone, PSP, DS… sauf la Xbox.
OpenGL est un standard ouvert et non commercial créé pour permettre aux utilisateurs sur n'importe quelle plateforme d'expérimenter des graphismes de la plus haute qualité que leur matériel peut donner. Mais comme Direct3D devient la seule API graphique pour le jeu prise en charge sur Windows, Microsoft gagne la mainmise sur le jeu PC. Le marché des jeux vidéo a besoin de concurrence et de liberté pour faire baisser les prix et pour augmenter la qualité, mais le monopole de Microsoft exerce un effet néfaste aussi bien pour les joueurs que pour les développeurs de jeu.
Il n'y a pas vraiment de désavantages à utiliser OpenGL, mais le fait que la plupart des développeurs de jeux vidéo soient tombés sous le charme de DirectX et dans le tourbillon vicieux des effets de réseau tend à faire oublier OpenGL à ceux qui se lancent dans le développement de jeux vidéo.
Mais quelle est donc la différence entre Vulkan et Open GL ES ? Pour commencer, OpenGL ES est la version mobile d'OpenGL avec moins de fonctionnalités que cette dernière. Aujourd'hui, lorsqu'un développeur veut sortir un titre sur PC et mobile, il doit utiliser un moteur 3D compatible avec OpenGL pour PC et OpenGL ES pour mobile. Il y a néanmoins quelques différences entre ces deux API avec moins de fonctionnalités sur mobile et il faut par conséquent produire deux développements différents. Vulkan, quant à lui, homogénéise le développement grâce à une seule version de l'API, puisque beaucoup moins de modifications sont nécessaires entre le développement de la version PC et celui de la version mobile. Il n'y a pas de version dédiée au mobile parce que l'API graphique est unifiée, ce qui veut dire que pour créer un moteur 3D à destination des PC ou bien des smartphones et des tablettes, les développeurs utilisent la même.
Vulkan dispose de nombreux avantages face à OpenGL ES, mais il ne le remplace pas pour autant, car ce dernier continue d'évoluer parallèlement à OpenGL. Les développeurs ont ainsi le choix d'utiliser soit Vulkan, soit OpenGL ES pour créer leur moteur 3D. Les deux principaux avantages de Vulkan sont la hausse des performances et la baisse de consommation.
La hausse des performances est due à plusieurs facteurs : déjà, le passage par le pilote graphique est beaucoup moins fréquent, contrairement à OpenGL ES où chaque commande de rendu doit passer par le pilote, ce qui provoque de la latence, une charge de processeur supplémentaire (overhead) et par conséquent une diminution des performances. Pour la gestion de la mémoire et des threads, Vulkan permet d'éviter de passer par le pilote, ce qui nous renvoie à la définition d'une API bas-niveau : elle peut piloter directement le GPU. Vulkan permet aussi d'augmenter les performances grâce à un net meilleur support des processeurs multicœurs en supportant par défaut de multiples threads. Il peut donc optimiser l'utilisation d'un processus doté de multiples cœurs pour mieux répartir la charge et ainsi tirer parti des performances maximales. Il est désormais possible d'afficher des milliers et des centaines de milliers d'objets sur une scène sans soumettre totalement le processeur grâce à cette nouveauté, toute en conservant une fluidité plus que respectable.
Pour un jeu vidéo qui n'est pas très gourmand en ressources, Vulkan peut légèrement diminuer la consommation de l'appareil avec un processeur moins utilisé et donc beaucoup plus optimisé. Au final Vulkan pourrait nous faire profiter de jeux PC et mobiles de plus en plus similaires en termes de fonctionnalités et de graphismes, car il permettra aux développeurs de moteurs 3D d'utiliser une seule et même base commune pour les différents titres destinés aux PC et les titres destinés aux mobiles. Les quelques différences persistantes dues à la présence de l'écran tactile sur mobile ou une puissance plus faible tendront à disparaître avec le temps.
Quelques inconvénients viennent toutefois contrebalancer les avantages à utiliser Vulkan. Il est plus difficile de créer des scènes 2D ou 3D à cause de SPIR-V, un langage de programmation plus complexe que les langages que les développeurs utilisaient autrefois pour créer leurs scènes, même s'il permet de réaliser des moteurs 3D nettement plus optimisés. Vulkan pourrait suivre Android Extension Pack au fond d'un tiroir, mais le fait que les trois API sur mobile, à savoir Vulkan, Metal sur iOS et Direct3D sur Windows soient de bas-niveau devrait faciliter le portage entre plateformes, contrairement à une API haut-niveau.
Aussi, il faut réunir trois conditions pour faire tourner un jeu supportant Vulkan sur un appareil mobile : un OS, un GPU et un pilote compatible. Le terminal doit disposer d'Android 6.0 Marshmallow ou supérieur et d'un GPU (puce graphique) compatible. On peut prendre pour exemple les puces PowerVR d'Imagination Technologies, Mali d'ARM, les Adreno des séries 400 et 500 de Qualcomm ou des Tegra de chez Nvidia.
En théorie, tous les GPU compatibles OpenGL ES 3.1 peuvent supporter Vulkan, mais en pratique, le concepteur de la puce doit avoir au préalable développé un pilote spécial et que le constructeur du terminal déploie ce pilote par le biais d'une mise à jour.
Direct3D fait partie de la famille de DirectX. Mais qu'est-ce que DirectX ? DirectX représente un ensemble de pilotes (drivers) pour plusieurs fonctions. Son intérêt particulier consiste à regrouper tous les drivers et à leur associer une même programmation, il représente donc une interface entre les drivers et les programmes qui l'utilisent. Le programmeur n'a donc plus à prendre en compte tous les drivers existants en faire en sorte que le jeu fonctionne avec chacun d'entre eux. Il peut donc programmer en utilisant les routines DirectX qui se chargera de faire fonctionner chaque élément auquel le programme fait appel. On peut dresser une liste de drivers regroupés par DirectX, qui a tendance à s'élargir à chaque nouvelle version :
Ici nous nous intéresserons principalement à Direct3D, qui est une des fonctions de DirectX les plus en vogue actuellement. Cette API se divise en deux couches :
Elle implémente deux types d'affichage :
Les différentes étapes du pipeline de Direct3D 11 (la dernière version) s'enchaînent comme suit :
Direct3D est distribué et maintenu par Microsoft. Il est conçu pour mieux fonctionner sur les ordinateurs Windows et est l'API prédominante utilisée par les développeurs de jeux vidéo.
Les méthodes d'affichage de Direct3D sont moins rapides que celles d'OpenGL, et les accès aux fonctionnalités ne sont que des instantanés occasionnels sur les plus récentes versions de Windows. La technologie de tesselation que Microsoft encourage n'est en fait qu'une extension d'OpenGL.
Un développeur de jeu vidéo doit bien choisir l'API avec laquelle il va créer son jeu. Il doit la choisir en fonction de la plateforme sur laquelle sera joué le jeu en priorité, mais aussi en fonction de la difficulté des langages de programmation proposés avec cette API. Le fait que DirectX soit très connu incite les développeurs à créer des jeux sur Windows avec cette API mais on passe à côté de toutes les qualités qu'OpenGL a à offrir. Avoir une API multiplateforme est un plus incontestable dans un marché où plusieurs supports peuvent accueillir des jeux vidéo. A moins de développer un jeu spécifiquement pour les machines de Microsoft et donc d'utiliser DirectX, il serait préférable pour le développeur lambda de jeter un œil à toutes les fonctionnalités intéressantes qu'OpenGL peut fournir en termes de performances, portabilité et facilité de programmation. L'avenir du jeu vidéo serait tellement plus serein si on ne se réduisait pas à une seule technologie produite par une seule société pour un seul type de support. Enfin, il semble que la démocratisation du jeu mobile incite les développeurs à créer des API pour mobile aussi. OpenGL ES existait déjà mais il a fallu que Vulkan arrive pour n'avoir qu'une seule version de jeu à préparer pour qu'elle tourne correctement à la fois sur PC et sur mobile. Vulkan peut donc être vu comme une version « améliorée » d'OpenGL spécialisée dans le mobile. Au final chacun est libre de choisir l'API qu'il veut mais il doit juste bien s'adapter, au jeu, au joueur, au support et surtout au développeur.
Yanis Berry a obtenu un Bac S au Lycée Marguerite de Valois en 2010. Après deux ans en class préparatoire MPSI-MP au Lycée Guez de Balzac, il se tourne finalement vers une formation DUT SRC (Services et Réseaux de Communication) à l'IUT d'Angoulême. En 2014, après avoir obtenu son DUT, il fait une 3ème année de Licence Informatique au Pôle Sciences et Technologies de la Rochelle. En 2015 il entre à l'Ecole Nationale des Jeux et Médias Interactifs Numériques (ENJMIN) à Angoulême pour un Master JMIN en section Programmation.