Sortie de OpenGL 3.1

C'est le 24 mars dernier que les spécifications de OpenGL 3.1 ont été mises au grand jour par le groupe Khronos, qui est chargé de la standardisation d'OpenGL depuis début 2007. C'était il y a à peine huit mois pourtant que l'API de rendu multiplate-formes se montrait sous sa version 3.0, en août dernier ; cet intervalle de sortie est l'un des plus courts dans l'histoire d'OpenGL.


Pour rappel, OpenGL est une API de rendu 3D exploitant les cartes graphiques pour un affichage temps réel optimal, vous trouverez d'ailleurs plusieurs tutoriels sur le Site du Zéro pour apprendre à l'utiliser. OpenGL se présente sous la forme de spécifications ouvertes que les constructeurs de cartes graphiques peuvent implémenter dans leurs pilotes afin d'offrir à leurs utilisateurs un support d'OpenGL. Il est important de distinguer OpenGL d'un moteur de rendu comme YafRay qui n'utilise pas d'accélération matérielle et ne fait que des rendus statiques, ce qui ne permet pas la création d'applications interactives, en revanche ce type de moteur génère des images de bien meilleure qualité.

Nouveautés d'OpenGL 3.1

OpenGL 3.0 était très attendu par de nombreux développeurs car il devait offrir un nouveau modèle objet (je rappelle au passage que les spécifications proposent une interface en langage C) et supprimer les fonctionnalités dépréciées telles que le mode de rendu direct (glBegin()), inadaptées aux architectures actuelles de GPU. Malheureusement diront certains, ça n'a pas été le cas, cette version était totalement rétro-compatible avec les précédentes ce qui n'a pas eu pour effet d'améliorer non seulement sa robustesse, mais aussi et surtout sa réputation.
C'est aujourd'hui chose accomplie : les fonctions dépréciées ont été supprimées et l'interface s'oriente vers modèle objet unifié qui offre une API similaire pour chaque type d'objet. Le fixed function pipeline tend à disparaître au profit de sa programmabilité. Le pipeline de rendu représente l'enchaînement des étapes nécessaires à l'affichage d'un polygone, depuis ses données géométriques jusqu'au contrôle du moindre pixel à l'écran en passant par la gestion des textures. Cette programmabilité du pipeline est possible au travers des shaders qui sont des petits programmes qui viennent remplacer certaines parties du pipeline de rendu, ce qui le rend modifiable au travers d'un simple bout de code et non plus statique comme avant. Pour plus d'informations sur le fonctionnement du FFP et des shaders, vous pouvez lire le tutoriel que j'y consacre ainsi que le schéma disponible sur cette page. L'utilisation des shaders se répand au point de devenir indispensable pour exploiter la plupart des dernières fonctionnalités de rendu intégrées à l'API. Cette version 3.1 sert surtout à marquer une rupture définitive avec les anciennes versions et à standardiser à l'échelle des spécifications d'OpenGL des fonctionnalités déjà existantes sous forme d'extensions. Voici une brève description de quelques-unes d'entre elles.

Geometry instancing

Le geometry instancing est une technique bien connue de regroupement (batching) de la géométrie afin d'améliorer les performances de rendu. Le principe est globalement assez simple, imaginez que vous souhaitiez rendre une scène comportant de nombreuses fois le même modèle géométrique, c'est-à-dire le même maillage (mesh en anglais), comme par exemple un champ d'astéroides. Il serait judicieux de regrouper les rendus de tous ces astéroides en « un seul » rendu, cela éviterait des itérations inutiles et surtout un trop grand nombre de changements d'état de la carte graphique. Côté implémentation, le geometry instancing d'OpenGL est accessible via l'extension GL_ARB_draw_instanced.
Cette fonctionnalité n'était pas présente dans la version 3.0 des spécifications, c'est donc ici une « nouveauté ».

Texture arrays

Comme son nom l'indique, il s'agit ici de tableaux de textures. L'idée ici peut être comparée à l'instancing, il s'agit de regrouper ce qui est relativement semblable afin de procéder à un traitement unifié et donc optimisé. Un tableau de textures va permettre de stocker un lot de textures à conditions que leur format et leur taille soient identiques. Leur contenu peut bien évidemment être différent. On dispose ensuite dans les shaders d'un accès rapide à l'ensemble des textures contenues dans un tableau, et ceci avec une seule unité de texturage.

Transform feedback

Derrière ce nom peu évocateur se cache un moyen de dessiner non pas sur un tampon chromatique, mais sur un tampon de sommets ! Plus communément appelés VBO, ces tampons vont pouvoir être la cible d'un rendu grâce au transform feedback. Mais pas question de rendre une image, on va ici rendre de la géométrie, c'est-à-dire des sommets ou autrement dit les points 3D qui forment un modèle. Les étapes de rendu dans le pipeline s'arrêtent avant l'étape de clipping, ce qui rend ce type de rendu très rapide. Si un vertex et/ou un geometry shader est actif, il est pris en compte et le processus s'arrête juste après l'exécution de ce dernier. Le transform feedback permet de sauvegarder de la géométrie et ensuite l'utiliser pour générer plusieurs images mais sans repasser par les étapes de traitement des sommets ; cette fois-ci on reprend le pipeline là où on l'avait laissé. Ces rendus sont également plus rapides que des rendus classiques car des étapes de rendu sont brûlées, car déjà effectuées et sauvegardées dans un VBO. Vous trouverez cette fonctionnalité via l'extension GL_EXT_transform_feedback.

Et les geometry shaders ?

Histoire de montrer OpenGL sous tous ses angles, autant montrer aussi les moins joyeux. Ce sont donc les geometry shaders, qui font pas mal de bruit autour d'eux ces derniers temps, qui sont absents de ces dernières spécifications. Les geometry shaders sont un type de shader à l'instar des vertex et pixel shaders qui agissent au niveau de la géométrie. Dans le pipeline de rendu ils se situent avant les pixel shaders mais après les vertex shaders. Ils permettent d'émettre de nouveaux polygones à partir des polygones qui leur parvient en entrée, cela offre la possibilité de complexifier la géométrie d'une scène pour un coût minimal de traitement. En effet, les polygones supplémentaires émis par un geometry shader sont plus rapides à traiter car ils doivent traverser moins d'étapes dans le pipeline de rendu que ceux envoyés initialement. Maintenant que nous avons l'eau à la bouche, revenons à la dure réalité : pas de geometry shaders pour OpenGL 3.1. Une explication à leur absence pourrait résider dans leur intérêt, qui ne se manifeste que dans de rares cas, ou encore dans le fait que ATI ne supporte pas l'extension. Que les possesseurs de cartes nVidia se rassurent, ils pourront quand même en profiter avec l'extension GL_EXT_geometry_shader4.

Une issue de secours pour la rétro-compatibilité

Afin d'assurer le bon fonctionnement des programmes utilisant des fonctionnalités qui ont été supprimées dans OpenGL 3.1, Khronos a mis en place un système permettant de les utiliser via... une extension ! Ainsi chaque implémentation pourra fournir l'extension GL_ARB_compatibility qui permettra l'accès à toutes les fonctionnalités supprimées depuis OpenGL 3.0.

OpenGL 3.1 à l'ombre de Direct3D ?

Direct3D est une célèbre bibliothèque de rendu 3D créée et maintenue par Microsoft. L'évolution de son interface ressemble plus à l'évolution de n'importe quelle bibliothèque, une nouvelle version sort régulièrement, proposant à chaque fois de nouvelles fonctionnalités, une interface modifiée, etc. Ceci lui offre l'avantage d'une évolution unifiée et stricte, chaque carte graphique étant ensuite jugée apte ou inapte à supporter les fonctionnalités apportées par la nouvelle mouture. En contrepartie ceci ne lui confère pas l'avantage du système d'extensions d'OpenGL, qui est de pouvoir exploiter au maximum les capacités d'une carte graphique. Chaque extension peut être considérée comme un morceau d'OpenGL, elle implémente ses propres fonctions et définit sa propre fonctionnalité. Le support d'OpenGL par une carte graphique ne se fait pas au niveau de la version de l'API mais individuellement pour chaque extension. Il est ainsi possible avec OpenGL d'exploiter une fonctionnalité récente, en passant simplement par l'extension adéquate et sans avoir besoin d'attendre la prochaine révision de l'API, comme c'est le cas avec Direct3D.
Bien que le système d'extensions d'OpenGL permette d'offrir les dernières technologies et fonctionnalités imaginées par les constructeurs de cartes graphiques, il n'en est pas moins qu'une révision de fond et une standardisation de toutes ces extensions devenait nécessaire afin de remettre de l'ordre et d'assurer une meilleure portabilité. C'est ce qui a été fait avec OpenGL 3.1, et tout le monde s'en porte mieux.

Histoire des événements et usages actuels des deux API

Historiquement, OpenGL a été créé par Silicon Graphics, une société fournissant entre autres des solutions de rendu 3D professionnel. La réputation de la société dans le domaine jouant son rôle, l'utilisation de son API est donc devenue monnaie courante pour toutes les applications nécessitant un rendu temps réel. À l'époque Direct3D n'en était qu'à ses balbutiements. Mais, en 2001, la version 8.1 de l'API de Microsoft a mis un terme à la domination d'OpenGL sur les applications 3D temps réel, avec l'aide de quelques contrats entre la firme et des constructeurs de cartes graphiques tels que nVidia et ATI. En plus d'être à la hauteur de la version d'OpenGL de l'époque, Direct3D 8.1 plaçait la barre plus haut encore en proposant de nouveaux concepts, dont principalement : les shaders. Ces derniers constituaient une véritable avancée dans le domaine du rendu temps réel, ce qui a laissé OpenGL à la traine. Le niveau a rapidement été rattrapé par ce dernier, mais Direct3D a définitivement enfoncé le clou avec sa version 9, qui a eut l'effet de la 8.1 à la puissance deux. Depuis, Direct3D domine le marché du jeu vidéo, qui est de loin le plus vaste en ce qui concerne les applications 3D temps réel. OpenGL reste cependant très utilisé, assez peu dans le jeu vidéo, mais beaucoup en imagerie médicale par exemple. Malgré la position de force de Direct3D face à un concurrent qui se remet d'un mauvais pas, son usage reste limité aux plateformes Microsoft, ce qui est un énorme point faible, et l'assurance de vie d'OpenGL. C'est là que la puissance d'une spécification ouverte prend toute son ampleur face à une bibliothèque fermée : en effet, OpenGL est la seule alternative viable sur les plateformes non Microsoft, c'est-à-dire Linux, MacOS, etc., ce qui la rend largement répandue. Nous pouvons également citer la Playstation 3 de Sony qui utilise une version d'OpenGL spécialement prévue pour les systèmes embarqués : OpenGL ES.

On se retrouve en définitive avec deux API qui diffèrent de part leur domaine d'application et leur plateforme cible. C'est toujours bien d'avoir le choix lorsqu'on veut faire quelque chose, cela offre plus de liberté et nous permet de choisir une solution qui nous convient, au lieu de n'être dirigé que part un seul mouvement uniformiste. De plus, une concurrence est le meilleur moyen d'inciter les différents protagonistes à innover continuellement, sous peine de se retrouver définitivement hors jeu la plupart du temps.

Support actuel d'OpenGL 3.1 par les cartes graphiques

Déterminer si une carte supporte une version d'OpenGL revient à déterminer si cette carte supporte toutes les extensions comprises dans cette version. Parvenir à un support complet d'une version X devient alors difficile, beaucoup de constructeurs certifient que tel modèle de leurs cartes est compatible avec une ancienne version d'OpenGL simplement parce qu'une ou deux extensions ne sont pas supportées pour la version d'après. Mais il n'y a pas que la carte qui entre en jeu, les pilotes graphiques jouent également un rôle important ici. Les pilotes sont en grande partie responsables des extensions OpenGL disponibles pour la simple raison que c'est eux qui offrent une implémentation d'OpenGL pour le système sur lequel ils sont installés.
À l'heure actuelle seul nVidia propose un pilote graphique qui implémente un support en version bêta de OpenGL 3.1. La plupart des cartes modernes ont les capacitées suffisantes pour supporter toutes ses fonctionnalités, dont certaines sont accessibles par les extensions, le tout est d'attendre leur intégration dans les pilotes. Soit dit en passant, cela ne fait pas très longtemps que nVidia et ATI ont sorti des pilotes entièrement compatibles avec OpenGL 3.0.

Conclusion

OpenGL est projeté dans l'avenir avec cette version 3.1. On y trouve les plus gros changements depuis l'existence de l'API et une certaine assurance que Khronos compte bien la moderniser en lui faisant un petit peu de chirurgie plastique ; la première opération s'est déroulée avec succès, mais il y en a encore et il n'est pas question de se reposer sur ses lauriers. La mode est au lifting complet pour les API 3D temps réel, et OpenGL n'y échappe pas. Il est temps de laisser à l'abandon les anciennes techniques de rendu pour faire place aux shaders grâce à la programmabilité des cartes graphiques. OpenGL se dirige dans cette voie plus que jamais aujourd'hui, et nous le fait savoir au travers de sa dernière version.

Liens et références

• (en) Spécifications d'OpenGL : http://www.opengl.org/documentation/specs/ ;
• (en) The Khronos group : http://www.khronos.org/ ;
• (en) News d'OpenGL 3.1 chez Icare3D : http://www.icare3d.org/blog_techno/gpu [...] ications.html ;
• (en) News d'OpenGL 3.1 chez G-Truc : http://www.g-truc.net/#news0152 ;
• (fr) Tutoriels OpenGL sur le SdZ : http://www.siteduzero.com/tutoriel-2-346-opengl.html ;
• (fr) OpenGL sur Wikipédia : http://fr.wikipedia.org/wiki/OpenGL ;
• (fr) DirectX sur Wikipédia en : http://fr.wikipedia.org/wiki/DirectX ;
• (en) Site avancé sur la 3D : http://www.geeks3d.com/.