25/03/2006 OpenGL 2.1 et futur
RSS Feed ~ Comment: by email - on Twitter ~ Share: Twitter - Facebook - Linked In - Google+ - Permanent link
Lors de la GDC 2006, s'est déroulé une journée de tutoriaux sur OpenGL comme chaque année. Une partie de cette journée a été consacré à OpenGL 2.1 et l'avenir d'OpenGL, elle nous est relayée par Dave Astle sur GameDev.net et je vous relaye à mon tout avec quelques compléments.
On nous apprend tout d'abord qu'OpenGL charge de propriétaire, pour passer dans les mains du Khronos Group. Ceci était attendu, voir espéré, suite aux mauvaises nouvelles du coté de SGI, actuel propriétaire d'OpenGL, qui pourrait déposé le bilan cette année.
Pour ce qui est d'OpenGL 2.1, ARB_pixel_buffer_object et EXT_texture_sRGB viennent compléter le core d'OpenGL.
ARB_pixel_buffer_object reprend l'API des vertex buffer object (ARB_vertex_buffer_object) pour charger des pixels en mémoire. Cette fonctionnalité est disponible à partir des Radeon de première génération et des GeForce2 mx.
Pour EXT_texture_sRGB, le format sRGB représente un système de couleurs non linéaire standardisé par l'International Electrotechnical Commission (IEC) sous la référence IEC 61966-2-1. Concrètement, pour une couleur sur 8 bits avec une texture usuelle, les 8 bits de données sont convertis dans un interval [0, 1] de manière linéaire. Avec un système de couleur sRGB se n'est plus le cas, les texels subissent une correction équivalente à du gamma 2.2. Le screenshot ci-dessous illustre le procédé. Ce format est disponible chez nVidia pour les GeForce FX et supérieur depuis les drivers 80.
Intégré à OpenGL avec la version 2.0 par la promotion de ARB_texture_float, les textures flottantes subissent une modification mineure. Si la carte ne supporte pas les textures flottantes, OpenGL retourne maintenant une erreur au lieu de tenter une conversion en entier.
Deux nouvelles extensions sont prévues. La première, ARB_framebuffer_object est la promotion de EXT_framebuffer_object, EXT_framebuffer_multisample et EXT_framebuffer_blit qui décrivent la notion de framebuffer object introduit récemment et qui a conquit les développeurs OpenGL. Les framebuffer objects sont particulièrement utiles et efficaces pour le rendu sur texture. Ils viennent remplacer l'immonde WGL_ARB_pbuffer mais ne sont disponible qu'à partir du GeForce FX et de Radeon 9500. La seconde est nommée ARB_synch_object et apporte des perspectives très intéressante au niveau de la synchronisation entre le CPU et le GPU. Jusqu'à présent, seuls deux mécanismes permettent de gérer cette synchronisation, glFinish et glFlush. glFlush force les commandes émises précédemment à commencer leur exécution et glFinish force l'achèvement de toutes les commandes OpenGL. Cette extension permet de forcer l'achèvement d'une partie du code. Par exemple, lors de l'upload des vertrices, cette extension permet de s'assurer que les données ont bien été envoyées dans la mémoire de la carte graphique avant de les modifier. Cette extension est basée sur NV_fence, disponible pour toutes les cartes nVidia depuis le GeForce 256.
Enfin dernière évolution: GLSL 1.2. Pas de geometry shaders (nommés primitive shaders pour OpenGL) pour le moment, mais on pouvait s'y attendre du fait du processus de développement d'OpenGL basé sur la promotion. Il faudra attendre l'arrivé des extensions propriétaires qui seront disponible en même temps que les cartes. Au niveau des changements, il y a tout d'abord la possibilité d'accéder à un mipmap spécifique. Un nouveau qualificatif nommé "centroid" nous permettra de contrôler un texel lorsqu'il n'est pas couvert par un fragment ce qui pourrait être utile pour des tâches de filtrage ou éventuellement pour l'occlusion culling. Il est également état d'un nouvel attribut pour les fragments shaders lors de l'utilisation des points sprites basé sur un attribut déjà existant sous OpenGL ES. Je n'ai malheureusement pas trouvé cet attribut dans les spécifications de GLSL ES.
Au niveau du langage lui-même, GLSL devient plus souple au niveau des conversions. Il était avant impossible d'appeler la fonction void exemple(float parameter) ainsi exemple(1) car 1 est un entier. Avec GLSL 1.2, la conversion sera automatiquement faite. Ce mécanisme fonctionne avec toutes les types primitifs ce qui inclut vec3, ivec2, mat4 par exemple mais le nombre de composantes doit correspondre. ivec3 peut-être convertie en vec3 par exemple mais pas en ivec4. Les tableaux disposent également de nouvelles possibilités au niveau des comparaisons ou de l'affectation qui seront direct si les tableaux ont la même taille. GLSL 1.2 supportera les matrices non carrés et deux nouvelles fonctions : transpose() et outerProduct(). Enfin pour utiliser GLSL 1.2, il faudra utiliser #version 120.
OpenGL 2.1 sera annoncé au SIGGRAPH 2006.
De plus, de nombreuses informations sur les sujets de réflexions de l'ARB ont étés présentés notamment sur OpenGL 3.0 qui devrait être divisé en deux profiles. Un premier reprend OpenGL tel que nous le connaissons et un deuxième apportera une vague de changement pour créer OpenGL LM (Lean and Mean), une version agressive d'OpenGL prévu pour concurrencer Direct3D sur le secteur des jeux. OpenGL est un API très souple voir trop souple ce qui limite les optimisations et complexifier l'implémentation. OpenGL LM retirera toutes les parties d'OpenGL qui ne sont pas directement implémenté dans les cartes graphiques. Concrètement et dans l'état du projet, OpenGL LM ne supporterait que les VBOs pour le transfère de la géométrie. Un nouvel objet serait créé pour la gestion de tous les états. Le fixe pipeline disparaîtrait et le model objet d'OpenGL devrait charger. Ainsi, à la place des unsigned int pour les noms d'objets nous utiliserions des GLobject qui ne seraient rien d'autres que des void*. Toutes les nouveautés d'OpenGL LM devraient voir le jour sous forme d'extensions dans un premier temps. Voici qui est intéressant, OpenGL LM reprend le principe de DirectX 10 d'une API simplifiée mais sans layer, le tout en laissant OpenGL backward compatible.
