Quelques définitions

Illumination globale

Les techniques d’illuminations globales (GI) visent à améliorer le rendu d’une scène 3D, en prenant en compte aussi bien la lumière directe (les sources de lumières qui éclairent les objets) que la lumière indirecte (réflexion de la lumière sur les objets, qui éclaire d’autres objets). Ces techniques permettent d’obtenir des rendus réalistes, au prix d’un temps de calcul relativement long (parfois trop pour être compatible avec du rendu en temps réel). Un domaine de la recherche actuelle vise à développer de nouveaux algorithmes d’illumination globale compatible avec le temps réel (jeux 3D).

(source : Wikipédia – Illumination globale)

Illumination indirecte

Dans l’illumination directe (à gauche sur l’illustration suivante), la lumière provenant d’une source est directement réfléchie sur une surface, puis renvoyé vers la caméra. C’est le modèle classique de calcul de la lumière en 3D, que l’on retrouve par exemple dans le modèle de Phong. La lumière est alors décomposée en plusieurs composantes : la lumière ambiante (qui représente une illumination globale constante), la lumière diffuse (qui représente une diffusion de la lumière sur la surface) et la lumière spéculaire (qui représente une réflexion sur la surface).

(Source : Real-Time Global Illumination for Point Cloud Scenes)

Dans l’illumination indirecte, on considère que chaque surface qui reçoit de la lumière va à son tour en renvoyer. Il n’y a donc plus qu’une seule source de lumière, mais une infinité, correspondant à chaque surface qui renvoie de la lumière. Pour réaliser le rendu d’une scène, il faut donc procéder de la façon suivante :

1. pour chaque surface S1 visible par la caméra ;
2. pour chaque surface S2 visible depuis la surface S1 ;
3. calculer la lumière reçue par la surface S2 provenant de la source ;
4. calculer la lumière renvoyée par la surface S2 vers la surface S1 ;
5. calculer la lumière reçue par la surface S1 provenant de la surface S2 ;
6. calculer la lumière totale renvoyée par la surface S1 vers la caméra.

Chaque étape doit prendre en compte plusieurs paramètres. Pour (3), il faut par exemple prendre en compte la distance entre la source et la surface S2 et l’atténuation de la lumière en fonction de la distance. Pour (4), il faut prendre en compte les caractéristiques de la surface et sa capacité à réfléchir la lumière. Pour (5), il faut prendre en compte la distance entre les surfaces S1 et S2 et l’angle d’incidence. Pour (6), les capacités de réflexion de la surface S1 et la distance entre la surface S1 et la caméra.

Cette première approche simple peut largement être améliorée (et complexifiée), en prenant en compte par exemple que la lumière peut se réfléchir plusieurs fois sur des surfaces avant d’atteindre la caméra (particulièrement important lorsque les surfaces sont très réfléchissantes, comme du verre ou du métal poli), de la diffusion de la lumière dans le brouillard ou la poussière (lumière volumétrique, éclat lumineux), la présence de plusieurs sources lumineuses (voir des milliers de sources lumineuses dans le cas de particules incandescentes).

Lancé de rayons

Il existe plusieurs techniques de « lancés ». Elles reposent sur l’idée que la lumière est constituée de rayons qui vont partir de des sources lumineuses, se réfléchir, diffuser et réfracter sur les différentes surfaces (chaque surface pouvant renvoyer plusieurs rayons), puis atteindre la caméra. Dans les techniques de photon mapping, on part des sources lumineuses, on émet des rayons et on les suit jusqu’à la caméra (cette technique est décrite dans un autre article du blog de Simon et fera l’objet d’une traduction). Dans les techniques de lancé de rayons, on part de la caméra, on lance un rayon pour chaque pixel de l’image finale et l’on remonte jusqu’aux sources de lumière (illustration suivante).

(Source : Wikipédia – Raytracing)

Dans la technique du lancé de cônes (Cone Tracing), présentée dans l’article traduit, on remplace simplement les rayons par des cônes pour le calcul de l’illumination.

Occlusion ambiante

Cette technique fera également l’objet de plusieurs traductions du blog de Simon, je la détaillerai à ce moment là.

Simplement pour comprendre l’idée générale : lorsque deux surfaces sont proches (dans une fissure, un trou), la lumière indirecte diminue fortement et l’on observe des ombres douces. Plus les surfaces sont proches et fermées, plus l’ombrage sera important. L’illustration suivante représente la même scène sans (en haut) et avec l’occlusion ambiante (en bas). Remarquez en particulier l’ombre dans l’angle du mur et du sol et entre la sphère dans l’image du bas.

Cette technique améliore fortement la qualité du rendu et commence à être très utilisée dans les jeux. Un de ses points forts est que pour un objet statique (ou peu dynamique), l’occlusion ambiante ne varie pas (ou peu) et il est possible de la pré-calculer, le résultat étant mis dans une texture. Il suffit ensuite d’appliquer la texture sur l’objet lors du rendu, comme n’importe quelle autre texture.

Il existe plusieurs algorithmes de calcul de l’occlusion ambiante, mais pour comprendre le principe, voyons un exemple simple représenté dans l’illustration suivante. Pour chaque point d’une surface, on va lancer un nombre fixé de rayons qui vont parcourir une distance fixée aussi dans toutes les directions. On compte ensuite le nombre de rayons qui ne rencontrent pas une autre surface et on calcul le rapport entre le nombre de rayons ayant rencontrés une surface et le nombre de rayons lancés. Ainsi, dans l’illustration suivante, pour le point A, sur les six rayons lancés, aucun ne rencontre de surfaces, le rapport est de 0/6 = 0 %. Pour le point B, seul quatre rayons ne rencontrent pas de surfaces sur les six lancés, le rapport est de 4/6 = 66 %. Pour le point C, deux rayons ne rencontrent pas de surfaces, le rapport est de 2/6 = 33 %.

Il suffit ensuite d’atténuer la lumière pour chaque point en fonction du rapport calculé. Plus le rapport est proche de 0 %, plus la surface sera sombre et plus le rapport est proche de 100 %, plus la surface est claire.

Pour obtenir un bon rendu, on pourra augmenter le nombre de point et le nombre de rayons lancés, mais l’impact sur les performances sera important.

Partitionnement de l’espace

Voxel

Le principe des voxels est relativement simple : ils sont l’équivalent en 3D des pixels pour la 2D. Un exemple bien connu d’utilisation des voxels est le jeu Minecraft, dans lequel chaque élément (terrain, objets) sont représentés par des cubes.

(Source : Wikiépdia – Minecraft)

Les voxels sont particulièrement gourmand en termes de performances et sont encore peu utilisés pour les jeux vidéos. Ils sont particulièrement adaptés pour le rendu de volumes transparents (verre, liquide, fumée, nuage) ou de géométries très complexes (pour le rendu d’un mesh complexe, une approche utilisant une version low poly du mesh et une texture des Displacement/Normal/Bump mapping).

Octree

Un octree est une structure permettant de partitionner l’espace dans un arbre, permettant par exemple de faciliter la recherche d’un élément par rapport à sa position 3D. La construction d’un tel arbre est simple : à chaque itération, le cube représentant une partie de l’espace est divisé en 8 cubes.

(Source : GPU Gems 2 – Octree Textures on the GPU)

L’intérêt des octrees avec les voxels est que l’on va pouvoir utiliser une structure « creuse » : les zones qui sont vides ne seront pas divisées en cubes plus petits, simplifiant ainsi les algorithmes de recherche et la mémoire.

• utiliser deux boucles for imbriquées pour parcourir chaque pixel du widget et calculer la couleur correspondante, en faisant varier les paramètres S et V dans l’espace colorimétrique HSV ;
• utiliser deux gradient (à l’aide de la classe QLinearGradient), le premier, horizontal, allant du blanc à gauche à la teinte choisie à droite, et le second, vertical, allant du transparent en haut au noir en bas.

Je vais présenter ici comment implémenter un benchmark avec Qt pour tester la rapidité de ces différentes méthodes et présenter deux autres méthodes pour accélérer le rendu : l’accès direct au tampon mémoire contenant l’image finale et l’accélération matériel sur carte graphique.

Création du programme Benchmark

Qt offre différents outils facilitant la création de tests unitaires et de benchmarks, rassemblés dans le module QtTest. Différents tutoriels permettent de se familiariser progressivement avec ce module.

Benchmark.pro

Pour créer notre programme Benchmark, commençons par créer un fichier de projet Benchmark.pro. Ce fichier de projet contient les déclarations de base suivantes : la liste des modules utilisés (core, gui puisse que l’on teste les fonctions de dessin et testlib) et le nom et le type de binaire généré (une application Benchmark dans notre cas) :

On ajoute ensuite la liste des fichiers à inclure dans notre projet. On va simplement créer une classe Benchmark : on ajoute donc les fichiers d’en-tête et d’implémentation :

benchmark.h

La classe Benchmark hérite de QObject (pour pourvoir utiliser le système de signaux et slots) et contient deux slots privés, un pour chaque méthode que l’on souhaite tester. Ces slots seront automatiquement appelés à l’exécution du programme. A part cela, le contenu de la classe est minimaliste :

benchmark.cpp

Dans le fichier d’implémentation, on ajoute chaque méthode dans les slots correspondants :

Il faut également ajouter la macro QTEST_MAIN, qui crée une fonction main, qui aura pour fonction de créer une instance de la classe Benchmark et d’exécuter les slots privés :

Méthode des deux boucles for

Pour mesurer le temps d’exécution d’une méthode, on utilise la macro BENCHMARK. Le temps du reste du code contenu dans le slot mais en dehors du bloc précédent la macro n’est pas évalué. Pour vérifier que le code généré correctement les nuances de gris, on enregistre les images produites :

Méthode des deux gradients linéaires

Le code étant expliqué dans la solution de l’exercice, je n’entre pas dans le détail ici.

Résultat du benchmark

Lorsque le programme est exécuté, des messages sont générés automatiquement à chaque étape du processus. L’en-tête décrit simplement le nom du programme et les versions de QtTest et de Qt utilisées :

Le premier slot que lance le programme est un slot spécifique, initTestCase, généré par défaut et ne faisant rien. Ce slot permet, si on le souhaite, d’initialiser des objets pour l’ensemble du programme :

Vient ensuite les différents slots que l’on a créé. Le premier est hsvGradient. Lorsque le temps d’exécution du slots est trop petit, la mesure risque de ne pas être précise. Pour palier à cet inconvénient, le code contenu dans le bloc de code suivant la macro BENCHMARK peut être exécuté plusieurs fois, le temps indiqué correspondant au temps moyen mesuré. Ici, le slot hsvGradient a été exécuté deux fois et le temps moyen est de 47 millisecondes :

Pour le slot doubleLinearGradient, le code a été exécuté une seule fois et le temps mesuré est de 57 millisecondes. On voit donc ici que cette méthode est plus lente que la première version (sur le système testé ! C’est à dire Linux dans mon cas. Sous Windows ou Max OS X, il est possible que les résultats soient différents). Cette différence peut s’expliquer par le fait que la génération de deux gradients et la gestion de la transparence est plus lente que l’accès directe aux pixels, sur le système de rendu par défaut (le système Raster) :

Le programme exécute ensuite un slot pour libérer les ressources initialisées dans la fonction initTestCase :

Pour terminer, le programme indique le nombre de slot exécutés sans incident (passed), ceux qui ont échoué (failed) et ceux qui n’ont pas été exécutés (skipped) :

Rendu dans un tampon mémoire

Dans la première méthode, on utilise la fonction Qimage::setPixel pour modifier chaque pixel un par un. Cette méthode permet d’utiliser une interface sécurisée et simple. Malheureusement, les calculs (calcul de l’adresse mémoire correspondant au pixel, conversion de l’espace colorimétrique HSV en RGB) et tests effectués en interne (la position du pixel est bien dans l’image ? Les valeurs de la couleurs sont-elles correctes ?) peuvent ralentir fortement l’exécution.
Il est alors possible d’optimiser le rendu en accédant directement à la mémoire à l’aide de pointeurs : on créer un bloc mémoire de taille suffisante que l’on alloue à une image puis on accède à chaque octet un par un.

ATTENTION : ce type d’approche peut comporter certains risques : en cas d’erreur dans le code, il est possible que l’on écrive dans une zone mémoire qui ne correspond pas à l’image. Aucun test n’est effectué pour vérifier que le pointeur pointe vers une zone valide. L’application peut devenir instable. De plus, il est possible que le code ne soit pas portable et donne des résultats différents en fonction des systèmes d’exploitation utilisés (je l’ai testé uniquement sur Linux, pensez à bien enregistrer tous vos documents avant de lancer le programme sur un autre système:) ).

La première chose a faire est de créer une zone mémoire de taille suffisante : un pixel étant codé sur 32 bits (un octet par composante de la couleur et quatre composantes : rouge, vert, bleu et alpha), il faudra donc réserver un bloc mémoire de width * height * 4 pour contenir toute l’image :

Il n’est pas nécessaire d’initialiser chaque octet du bloc mémoire (avec memset par exemple) puisque l’algorithme utilisé garanti que chaque octet sera initialisé durant l’exécution de celui-ci.

Pour commencer, on crée un pointeur pointant vers le premier octet du bloc mémoire :

On utilise deux boucle for, comme dans la première méthode, pour parcourir chaque pixel (en fait, on parcourt le bloc mémoire linéairement, en « déplaçant » le pointeur octet par octet et non en accédant aux coordonnées (x, y) comme dans le cas d’une image) :

Les valeurs de composantes RGB sont calculés par la méthode présentée dans la version QML de la solution de l'exercice :

Ensuite, pour chaque composante, on affecte la valeur calculée (sous forme de uchar pour être sur qu'elle occupe bien à un octet en mémoire) à l'octet pointé par le pointeur (en dé-référençant celui-ci) puis on « avance » le pointeur d’un octet :

On fait de même pour les autres composantes :

Pour terminer, on enregistre l’image générée :

Résultat du benchmark

Les messages de sortie d’application générés par le slot drawInBuffer indique que cette méthode est plus rapide d’un facteur 10 que les deux autres méthodes, avec un temps d’exécution moyen de 3,9 millisecondes :

Optimisation de l’algorithme

Jusqu’à présent, nous avons simplement travailler sur l’implémentation pour optimiser le rendu des nuances de gris. Une autre approche consiste à travailler sur l’algorithme utilisé et d’essayer de diminuer les calculs effectués.
Quelque soit l’approche utilisée, il sera nécessaire de parcourir l’ensemble des pixels du widget, soit explicitement, comme dans le cas de la première méthode présentée, soit implicitement, comme dans le cas des deux QLinearGradient. On ne pourra donc pas optimiser cette partie (on peut au mieux éviter de parcourir plusieurs fois chaque pixel, comme on fait avec la méthode avec les deux QLinearGradient).
On peut remarquer que, dans chaque méthode présentée jusqu’ici, on travaille avec des nombres réels, ce qui n’est pas optimal. L’idéal serait de travailler qu’avec des nombres entiers, mieux gérés par les processeurs, et d’effectuer que des opérations élémentaires : addition, soustraction et multiplication.

Regardons en détail ce que l’on souhaite faire lorsque l’on parcourt un ligne pour une composante en particulier. La composante est une valeur entière allant de 0 à 255 (ou de 255 à 0) pour les pixels allant de 0 à N (avec N > 256 pour être sur d’afficher toutes les nuances). Il faut donc parcourir chaque pixel et incrémenter, quand c’est nécessaire, la composante. Si on représente cela avec un graphique 2D, on obtient :

avec x, l’index des pixels, et y, la composante de la couleur (source : Wikipédia).

Le lecteur averti aura compris l’idée sous-jacente : calculer la composante de la couleur revient à dessiner une ligne dans un espace (x, y) discret. Or, il existe un algorithme très performant pour réaliser cela : l’algorithme de Bresenham. Il suffit juste de remplacer y par la composante de la couleur. Le lecteur se reportera à l’article de Wikipédia pour l’explication du principe de cet algorithme.

L’implémentation de l’algorithme est assez triviale à partir du pseudo-code. On fera attention aux notations utilisées, qui correspondent au pseudo-code, c’est à dire que y1 correspondent à la composante de la couleur et non à la position verticale du pixel. La variable i est utilisée pour parcourir verticalement l’image dans une boucle for :

L'image générée est un gradient allant du noir au blanc :

Pour générer toutes les nuances, il va falloir imbriquer deux fois algorithme, le premier allant du blanc à la teinte choisie (première ligne de pixels) et le second allant de la teinte (pixel de la première ligne) au noir (pixel de la dernière ligne). Il faut également gérer chaque composante indépendamment.

Pour terminer, il est possible de combiner cette méthode avec la méthode utilisant un tampon mémoire. Le code est très proche du précédent.

Résultat du benchmark

La méthode utilisant l’algorithme amélioré permet de gagner un facteur 3 à 4 par rapport aux premières méthodes :

La version combinant les deux approches permet un gain de performance d’un facteur 4 par rapport à la méthode utilisant un tampon mémoire et un facteur 50 par rapport au premières méthodes :

Accélération matériel sur carte graphique

Pour réaliser le rendu des nuances de gris sur carte graphique, on utilise une classe dérivée de QGLWidget. Il suffit de dessiner un rectangle s’adaptant à la taille du widget, le reste du travail de rendu est réalisé dans le fragment shader : on calcule le rapport entre la position du pixel et la largeur du widget (passé en paramètre) pour calculer la nuance de gris correspondante :

Pour que le fragment shader soit appliqué sur chaque pixel du widget, il suffit de dessiner un quadrilatère sur la totalité de la surface :

Les différents paramètres utilisés dans le fragment shader sont définis à l’aide des fonctions uniformLocation et setUniformValue. Par exemple, pour mettre à jour la taille du widget :

Par contre, je n’ai pas réussit à utiliser les fonctions de benchmarks de Qt Test pour tester la rapidité du rendu par cette méthode. Pour pouvoir mesurer le temps, j’ai ajouté un calcul du nombre de FPS (frame par seconde) avec un simple compteur, incrémenté à chaque cycle et remis à zéro toutes les secondes :

Pour mettre à jour la widget, j’utilise un QTimer avec un délai de 0.

ATTENTION : Il en faut pas laisser le programme tourner trop longtemps avec cette méthode. Le programme tourne en boucle et utilise la carte graphique au maximum de ses capacités, ce qui augmente progressivement sa température. Personnellement, je n’ai pas pris le risque de tester si cela pouvait endommager la carte graphique.

Performances

J’ai réalisé le test sur un ordinateur portable équipé d’une carte Nvidia 8600M GT avec 512 Mo et un widget de 256 x 256 pixels. Avec cette configuration, les mesures donnent un FPS moyen de 5000 fps avec de pointes à 5200 fps, c’est à dire des temps de rendu de l’ordre de 0,2 millisecondes (soit 250 fois plus rapide que les premières versions).

Les sources

Télécharger les sources des benchmarks.

Télécharger les sources de la version OpenGL.

Vous pouvez commenter cet article sur le forum

Les nouvelles extensions

L’extension ARB_debug_output (GL 4.1)

Dans la version OpenGL 4.1, a été ajouté l’extension ARB_debug_output, qui est une promotion de l’extension GL_AMD_debug_output proposée par AMD. Cette extension ajoute la possibilité de créer des contextes avec un mode de débogage. En l’activant, un système d’événements est activé et permet d’obtenir des informations variées, par exemple sur les problèmes rencontrés lors de la compilation des shaders GLSL, des appels de fonction non valides ou des problèmes potentiels de performance. Les messages générés par ce système peuvent être stockés dans une pile (« message log ») ou être récupérés par une fonction callback définie par l’utilisateur.

L’extension KHR_debug (GL 4.3)

Dans le but d’uniformiser les différentes versions d’OpenGL (en particulier avec OpenGL ES), l’évolution d’OpenGL tend à reprendre des fonctions provenant d’OpenGL ES. C’est le cas de l’extension KHR_debug dans OpenGL 4.3 qui est une promotion de l’extension ARB_debug_output d’OpenGL 4.1 et des extensions EXT_debug_marker et EXT_debug_label d’OpenGL ES. Cette extension ajoute ainsi des fonctions pour annoter les événements ou des groupes de commandes OpenGL.

Création d’un contexte de débogage (GL 4.1)

La première chose à faire pour utiliser un contexte de débogage est de vérifier que l’extension ARB_debug_output est bien prise en charge. Un exemple de code pour vérifier une extension est donné dans le tutoriel Les extensions OpenGL.

Pour créer un contexte de débogage, il faut simplement créer un contexte en appelant la fonction CreateContextAttribs avec le paramètre CONTEXT_DEBUG_BIT. En fonction du système d’exploitation, on aura donc un code équivalent à celui-ci :

Les fonctionnalités de débogage sont activées en utilisant la constante GL_DEBUG_OUTPUT. Celle-ci peut être activée ou désactivée avec glEnable et glDisable. Par défaut, cette constante est activée dans un contexte de débogage et désactivée dans le cas contraire.

Plusieurs niveaux de débogage sont possibles en fonction de la création ou non d’un contexte de débogage et de si l’on active GL_DEBUG_OUTPUT :

• si on ne crée pas un contexte de débogage et que l’on active GL_DEBUG_OUTPUT, les messages envoyés et le contenu sont laissés à l’appréciation des implémentations d’OpenGL, mais l’appel des fonctions de débogage ne produit pas d’erreur ;
• si on crée un contexte de débogage et que l’on n’active pas GL_DEBUG_OUTPUT, aucun message de débogage n’est lancé ;
• si on crée un contexte de débogage et que l’on active GL_DEBUG_OUTPUT, toutes les fonctionnalités de débogage sont activées.

Créer des contextes de débogage à partir d’une bibliothèque (GL 4.1)

Il existe plusieurs bibliothèques graphiques qui permettent de travailler sur des contextes OpenGL (SFML, SDL, Qt, etc.). Voyons comment créer un contexte de débogage dans ces cas d’utilisation.

Avec FreeGlut

FreeGlut fournit directement une constante pour créer un contexte en mode débogage : GLUT_DEBUG.

Avec Qt

La bibliothèque Qt fournit des outils pour créer et manipuler directement des fenêtres contenant un contexte OpenGL avec le module QtOpenGL. Pour créer un contexte spécifique d’une version OpenGL, il suffit simplement d’utiliser la fonction setVersion de la classe QGLFormat :

Pour plus de détails, voir l’article How to use OpenGL Core Profile with Qt sur le wiki de Qt.

Avec SFML 2.0

La bibliothèque SFML permet de demander lors de la création d’une fenêtre la version du contexte OpenGL à utiliser avec la classe sf::ContextSettings. S’il n’est pas possible de créer un contexte avec les paramètres demandés, SFML va créer un contexte le plus proche possible. Il est donc important de vérifier la version de contexte réellement créée.

Pour plus de détails, voir l’article Using OpenGL in a SFML window sur le site de SFML.

Avec SDL 1.3

La bibliothèque SDL fournit les constantes SDL_GL_CONTEXT_MAJOR_VERSION pour définir la version du contexte que l’on souhaite utiliser.

Pour plus de détails, voir l’article Creating a Cross Platform OpenGL 3.2 Context in SDL sur le site de SFML.

Les modes de synchronisation (GL 4.1)

Par défaut, les appels de fonction OpenGL sont asynchrones, ce qui veut dire que les fonctions peuvent simplement envoyer les commandes aux contextes OpenGL puis passent à l’instruction suivante dans le code. Par exemple, le code suivant peut poser des problèmes puisque rien ne garantit que l’on mesure réellement le temps d’exécution de la commande :

Lorsque l’on débogue une application utilisant OpenGL, il peut alors y avoir un décalage entre l’appel d’une fonction et une erreur générée. Pour faciliter le débogage, il est possible de changer le mode de synchronisation pour forcer OpenGL à attendre la fin de la commande avant de passer à l’instruction suivante dans le code. Cette fonctionnalité garantit la synchronisation dans un contexte, mais pas la synchronisation entre plusieurs contextes, qui reste sous la responsabilité de l’application.

Il est possible de tester le mode avec glIsEnabled et de le désactiver avec glDisable. Activer cette fonctionnalité peut être très coûteux en termes de performance et doit être utilisée uniquement pour le débogage.

La pile des évènements (GL 4.1)

La pile des évènements, appelée « message log » contient les messages lancés dans un contexte de débogage. Cette pile est de taille limitée, ce qui signifie que si elle est pleine, les événements les plus anciens seront perdus. Il faut donc la vider régulièrement en lisant les messages. Lorsque l’on utilise plusieurs contextes, chaque contexte possède sa propre pile des événements.

La fonction glGetIntegerv permet d’obtenir des informations sur les capacités et le contenu de la pile.

Les messages contenus dans la pile (GL 4.1)

Les messages dans la pile contiennent plusieurs informations comme l’origine du message, son type et son importance.

Origine du message :

• GL_DEBUG_SOURCE_API : le message est lancé lors d’un appel d’une fonction OpenGL ;
• GL_DEBUG_SOURCE_WINDOW_SYSTEM : le message est lancé par le gestionnaire de fenêtre ;
• GL_DEBUG_SOURCE_SHADER_COMPILER : le message est lancé par le compilateur de shader ;
• GL_DEBUG_SOURCE_THIRD_PARTY : le message est lancé par une bibliothèque externe ;
• GL_DEBUG_SOURCE_APPLICATION : le message est lancé par l’application (voir la partie « Envoyer un message personnalisé ») ;
• GL_DEBUG_SOURCE_OTHER : le message ne provient pas d’une des sources précédentes.

Type de message (l’utilisation des constantes spécifiques d’OpenGL 4.3 sera décrite dans la partie « L’extension KHR_debug » de ce billet) :

• GL_DEBUG_TYPE_ERROR : message d’erreur récupérable avec glEvent ;
• GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR : utilisation fonction dépréciée ;
• GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR : appel qui provoque un comportement indéfini ;
• GL_DEBUG_TYPE_PORTABILITY : problèmes de portabilité ;
• GL_DEBUG_TYPE_PERFORMANCE : notifications de performance ;
• GL_DEBUG_TYPE_OTHER : ne correspond pas aux types précédents ;
• GL_DEBUG_TYPE_MARKER : annotation (GL 4.3) ;
• GL_DEBUG_TYPE_PUSH_GROUP : entrée dans un groupe (GL 4.3) ;
• GL_DEBUG_TYPE_POP_GROUP : sortie d’un groupe (GL 4.3).

Importance du message :

• GL_DEBUG_SEVERITY_NOTIFICATION : les messages qui ne concernent pas les performances et les erreurs ;
• GL_DEBUG_SEVERITY_LOW : les alertes de performance concernant les changements redondants de contextes, les comportements indéfinis triviaux ;
• GL_DEBUG_SEVERITY_MEDIUM : les alertes de performance sévères, les alertes de compilation ou de linkage GLSL, utilisation d’un comportement déprécié ;
• GL_DEBUG_SEVERITY_HIGH : les erreurs OpenGL, les comportements indéfinis dangereux, les erreurs de compilation ou de link GLSL.

Les messages sont identifiés de façon unique grâce à la combinaison de leur type, leur source et un numéro d’identification.

Le dernier élément composant un message est une chaîne de caractères terminée par le caractère NULL (chaîne de caractères, style C) et donnant des informations plus détaillées sur le message.

Lire les messages dans la pile (GL 4.1)

La fonction glGetDebugMessageLog permet de lire un ou plusieurs messages contenus dans la pile.

Pour récupérer un message :

Pour récupérer les dix premiers messages :

Pour effacer tous les messages dans la pile :

Une erreur GL_INVALID_VALUE est lancée si le paramètre bufSize est négatif.

Envoyer un message personnalisé (GL 4.1)

Il est possible d’envoyer un message personnalisé avec la fonction glDebugMessageInsert. Cela permet d’écrire des bibliothèques graphiques ou de transmettre des erreurs entre différentes parties d’une application.

Les paramètres sont équivalents aux autres fonctions. Si length est négatif, alors message est une chaîne de caractères terminée par NULL.

Par exemple :

La fonction glDebugMessageInsert peut générer les erreurs suivantes :

• INVALID_ENUM : type n’est pas une valeur valide ou source ne vaut pas DEBUG_SOURCE_APPLICATION ou DEBUG_-
  SOURCE_THIRD_PARTY ;
• INVALID_VALUE : severity n’est pas une valeur valide ;
• INVALID_VALUE : le nombre de caractères de message est supérieur à MAX_DEBUG_MESSAGE_LENGTH.

Les filtres de messages (GL 4.1)

Dans de nombreux cas, il est souhaitable de pouvoir limiter les messages, pour éviter de perdre des messages s’ils sont trop nombreux et éviter de devoir gérer un trop grand nombre de messages. Il est alors possible d’ajouter un ou plusieurs filtres, pour supprimer certains types de messages ou au contraire n’en garder que certains. Les filtres appliqués ne seront actifs que sur les nouveaux messages et non sur ceux qui sont déjà sur la pile.

La fonction glDebugMessageControl permet d’ajouter un filtre :

Les paramètres source, type et severity prennent l’une des valeurs décrites au-dessus (GL_DEBUG_SOURCE_API, GL_DEBUG_SOURCE_WINDOW_SYSTEM, GL_DEBUG_SOURCE_SHADER_COMPILER, GL_DEBUG_SOURCE_THIRD_PARTY, GL_DEBUG_SOURCE_APPLICATION ou GL_DEBUG_SOURCE_OTHER pour source, GL_DEBUG_TYPE_ERROR, GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR, GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR, GL_DEBUG_TYPE_PORTABILITY, GL_DEBUG_TYPE_PERFORMANCE ou GL_DEBUG_TYPE_OTHER pour type et GL_DEBUG_SEVERITY_LOW, GL_DEBUG_SEVERITY_MEDIUM ou GL_DEBUG_SEVERITY_HIGH pour severity) ou GL_DONT_CARE pour ne pas prendre en compte le paramètre.

Le paramètre ids permet de donner un tableau d’identifiants de taille count. Si le paramètre count est supérieur à 0, alors le filtre s’applique aux messages dont les identifiants correspondent aux valeurs données dans le tableau ids. Dans ce cas, les paramètres source et type ne doivent pas être GL_DONT_CARE et severity doit être GL_DONT_CARE.

Le paramètre enabled permet de préciser si le filtre supprime les messages correspondant aux critères (GL_FALSE) ou les garde (GL_TRUE).

Par exemple, pour garder tous les messages :

Par exemple, pour ne garder que les messages importants :

Pour désactiver les messages correspondant à l’appel de fonctions dépréciées :

Pour ne garder que les messages correspondant à une liste d’identifiants donnés :

La fonction GLDebugMessageControl peut générer les erreurs suivantes :

• INVALID_ENUM : utilisation d’une valeur incorrecte pour source, type ou severity ;
• INVALID_VALUE : count est négatif ;
• INVALID_OPERATION : count est positif, mais source ou type valent DONT_CARE ou severity ne vaut pas DONT_CARE.

Pour éviter d’avoir à écrire deux codes, pour les versions debug et release, il est possible de créer une macro définissant ou non une fonction appelant les filtres :

Les fonctions callback (GL 4.1)

Une autre possibilité pour récupérer les messages est de créer une fonction callback qui sera appelée dès qu’un message est lancé. Les messages ne sont alors plus mis dans la pile et ne peuvent être lus avec glGetDebugMessageLog. Par contre, les filtres ajoutés avec GLDebugMessageControl continuent de fonctionner.

Une fonction callback doit avoir la signature suivante :

Les paramètres source, type, id, severity et message correspondent aux paramètres des messages comme décrit au-dessus. Le paramètre length est la taille de la chaîne de caractères message. La mémoire allouée pour le paramètre message est gérée directement par OpenGL. Sa portée correspond à la fonction callback, donc il est nécessaire de copier le message si on souhaite l’utiliser en dehors de la fonction. Le paramètre userParam est un pointeur vers des données pouvant être utilisées dans le corps de la fonction et passées lorsque l’on attache la fonction callback à un contexte.

Elle ne doit pas appeler de fonction OpenGL ou du système de fenêtrage. Cette fonction est appelée par un thread différent du thread appelant la fonction GL, il faut donc faire particulièrement attention au respect du thread-safe.
Lorsque l’on travaille avec plusieurs contextes OpenGL, il faut fournir une fonction callback pour chaque contexte pour lesquels on souhaite capturer les messages. Dans une application multithread, il est possible d’avoir une fonction callback sur un contexte appelé par plusieurs threads différents, mais l’application est responsable du respect du thread-safe.

Par exemple, la fonction suivante permet d’afficher dans la console les informations des messages reçus.

La fonction glDebugMessageCallback permet d’attacher une fonction callback à un contexte. Elle prend en paramètre la fonction callback et un pointeur vers des données utilisateurs. Sa signature est la suivante :

Le code d’exemple suivant présente comment attacher une fonction callback et modifier les données utilisateurs entre deux messages.

Pour supprimer une fonction callback, il suffit d’appeler glDebugMessageCallback avec des valeurs nulles ;

La fonction glGetPointerv permet de récupérer la fonction callback en utilisant le paramètre GL_DEBUG_CALLBACK_FUNCTION et les données userParam avec GL_DEBUG_CALLBACK_USER_PARAM :

Les annotations de débogage (GL 4.3)

Un des problèmes que l’on peut rencontrer lorsque l’on débogue une application est de savoir quels objets provoquent une erreur. Il est nécessaire alors de garder une table contenant les identifiants des objets. Dans OpenGL 4.3 a été ajouté les annotations de débogage (debug label), qui permettent d’attacher une chaîne de caractères à n’importe quel objet OpenGL grâce à la fonction glObjectLabel :

Le paramètre name correspond au numéro retourné par les fonctions create. Le paramètre identifier indique le type d’objet correspondant à name. Il peut prendre les valeurs suivantes :

• BUFFER
• FRAMEBUFFER
• PROGRAM_PIPELINE
• PROGRAM
• QUERY
• RENDERBUFFER
• SAMPLER
• SHADER
• TEXTURE
• TRANSFORM_FEEDBACK
• VERTEX_ARRAY

La fonction glObjectLabel peut générer les erreurs suivantes :

• INVALID_ENUM : si identifier n’est pas une valeur valide ;
• INVALID_VALUE : si name ne correspond pas à un objet valide de type identifier ;
• INVALID_VALUE : si la taille de la chaîne de caractères label est plus grande que MAX_LABEL_LENGTH.

La fonction glGetObjectLabel permet de récupérer l’annotation associée avec un objet identifié par identifier et name :

Cette fonction peut retourner les erreurs suivantes :

• INVALID_ENUM : si identifier ne correspond pas à un type d’objet valide ou si name ne correspond pas à un objet valide de type donné ;
• INVALID_VALUE : si bufSize est négatif.

En plus de la fonction glObjectLabel, la fonction glObjectPtrLabel permet d’annoter un objet de synchronisation (un objet de synchronisation permet de tester si des commandes OpenGL sont en cours ou terminées ; voir le chapitre 4 – Event model des spécifications d’OpenGL 4.3 pour plus de détails).

La fonction glObjectPtrLabel peut générer les erreurs suivantes :

• INVALID_VALUE : si ptr ne correspond pas à un objet de synchronisation valide ;
• INVALID_VALUE : si la taille de la chaîne de caractères label est plus grande que MAX_LABEL_LENGTH.

La fonction glGetObjectPtrLabel permet de récupérer le label d’un objet de synchronisation :

Les groupes de débogage (GL 4.3)

Les groupes permettent d’annoter un ensemble de fonctions OpenGL. Un message GL_DEBUG_TYPE_PUSH_GROUP est envoyé lorsque l’on entre dans le groupe puis GL_DEBUG_TYPE_POP_GROUP lorsque l’on sort. Il est également possible d’utiliser plusieurs groupes, qui seront alors hiérarchisés dans une pile de groupes. Les filtres appliqués sont actifs sur le groupe courant et les groupes qui seront inclus dans ce groupe. Au démarrage, la pile contient un groupe par défaut. Ce système permet ainsi de retrouver plus facilement l’origine des messages.

Les fonctions glPushDebugGroup et glPopDebugGroup permettent de débuter et finir un groupe.

Le message généré contient la chaîne de caractères message, l’identifiant id, le type sera DEBUG_TYPE_PUSH_GROUP ou DEBUG_TYPE_POP_GROUP, la source devra être GL_DEBUG_SOURCE_APPLICATION ou GL_DEBUG_SOURCE_THIRD_PARTY et severity sera GL_DEBUG_SEVERITY_NOTIFICATION.

La fonction glPushDebugGroup peut générer les erreurs suivantes :

• INVALID_ENUM : si la source ne correspond pas à DEBUG_SOURCE_APPLICATION ou DEBUG_SOURCE_THIRD_PARTY ;
• INVALID_VALUE : si la taille de message est supérieure à MAX_DEBUG_MESSAGE_LENGTH ;
• STACK_OVERFLOW : si le nombre de groupes dépasse MAX_DEBUG_GROUP_STACK_DEPTH – 1.

La fonction glPopDebugGroup peut générer une erreur STACK_UNDERFLOW si la pile de groupes ne contient que le groupe par défaut.

Notes sur les implémentations

Les situations pouvant générer des messages et le contenu de ces messages sont laissés à l’appréciation des implémentations. On observe donc des différences de comportement entre les différentes implémentations.
Pour le moment, la taille de la pile semble être de 128 messages et la taille des messages au maximum de 1024 octets chez AMD et NVIDIA.

Exemples de situations et de message générés

Lorsque l’on attache un tampon mémoire sur un objet ne correspondant pas à un tampon, NVIDIA ne donne aucun message alors que AMD retourne un message signalant une fonction dépréciée :

glBindBuffer in a Core context performing invalid operation
with parameter « name » set to ‘0x5′ which was removed
from Core OpenGL (GL_INVALID_OPERATION)

Lorsque l’on appelle une fonction dépréciée ou avec une combinaison dépréciée de paramètres, par exemple glPolygonMode(GL_FRONT, GL_LINE), NVIDIA et AMD retournent une erreur GL_INVALID_ENUM :

// NVIDIA
GL_INVALID_ENUM error generated. Polygonmodes for « face » are
disabled in the current profile.
// AMD
Using glPolygonMode in a Core context with parameter
« face » and enum ‘0x404′ which was removed from
Core OpenGL (GL_INVALID_ENUM)

Les messages peuvent également servir lorsqu’il n’y a pas d’erreur, par exemple pour faire le suivi des appels de fonction. Par exemple, lorsque l’on attache un tampon mémoire et que les données sont correctement envoyées, NVIDIA lance le message suivant en GL_DEBUG_SEVERITY_LOW alors que AMD ne lance rien.

Buffer detailed info: Buffer object 3 (bound to
GL_ELEMENT_ARRAY_BUFFER_ARB, usage hint
is GL_ENUM_88e4) will use VIDEO memory as
the source for buffer object operations.

Lorsqu’on appelle la fonction glDrawElement pour lancer un rendu alors que la mémoire graphique est pleine, NVIDIA va générer le message suivant :

Unknown internal debug message . The NVIDIA
OpenGL driver has encountered an out of memory
error. This application might behave inconsistently and fail.

Pour terminer, une situation posant des problèmes de performance. Lorsque l’on utilise un nombre important de Vertex Array Object de petites tailles, NVIDIA lancera un message signalant une perte de performance alors que AMD ne donne aucun message.

Sources et remerciements

Certains exemples (en particulier les messages d’erreurs générés dans certaines situations) proviennent du livre OpenGL Insight de Patrick Cozzi et Christophe Riccio, dont certains chapitres sont accessibles gratuitement sur le site du livre. Merci également à Christophe Riccio pour ses revues des spécifications d’OpenGL qu’il publie sur g-truc. Vous pouvez également consulter les spécifications d’OpenGL 4.3, en particulier le chapitre consacré au débogage : « Chapter 20 – Debug Output ».
Merci à f-leb pour sa relecture orthographique.

Dans Qt4, les fonctionnalités d’OpenGL sont implémentées dans un module spécifique, QtOpenGL. Ce module était utilisé par différentes classes pour bénéficier de l’accélération matérielle. Il existe plusieurs méthodes pour activer l’accélération matérielle :

• pour activer par défaut l’utilisation de OpenGL, utiliser la ligne de commande « -graphicssystem opengl » ou la fonction QApplication::setGraphicsSystem(« opengl ») ;
• pour QGraphicsView (QtGraphics) ou QDeclarativeView (QtQuick), utiliser la fonction setViewport(new QGLWidget) ;
• on peut également utiliser QPainter directement sur un QGLWidget ;
• avec le QML Viewer, utilisez la commande « -opengl ».

L’organisation des modules
Dans Qt4, on a donc un problème dans l’organisation des modules. Beaucoup de classes de QtGui peuvent dépendre des classes appartenant à QtOpenGL alors que ce module dépend normalement de QtGui.
C’est pour cela que de nouvelles classes font leur apparition dans Qt5 et que les différents modules ont été réorganisés :

• les classes QOpenGL appartiennent au module QtGui et fournissent les fonctionnalités de base permettant l’accélération matérielle pour toute les classes de rendu de Qt ;
• la classe QWidget n’est plus le parent de toutes les classes de rendu. Cette classe et ses dérivées (QGraphicsView) sont transférées dans le module « widgets » ;
• QtQuick 2 utilise maintenant scenegraph à la place de QWidget et la classe QDeclarativeView devient QQuickView et OpenGL est utilisé par défaut ;
• QtOpenGL continue d’exister pour fournir la classe QGLWidget et ses dérivés. Le code OpenGL Qt4 est donc compatible avec Qt5 ;
• le module Qt3d fait son apparition pour fournir un moteur 3D plus avancé. Ce module est suffisamment important et fera donc l’objet d’un article spécifique.

Remarque : il faut faire attention de ne pas confondre le module QtOpenGL, contenant les classes commençant par QGL, et le module QtGui, contenant les classes commençant par QOpenGL (sans t).

Les classes de QtGui dans Qt5
Le module QtGui de Qt5 réutilise des classes existantes du module QtOpenGL de Qt4. Les noms sont explicites :

1. QOpenGLBuffer ;
2. QOpenGLContext ;
3. QOpenGLFramebufferObject ;
4. QOpenGLFramebufferObjectFormat ;
5. QOpenGLShader ;
6. QOpenGLShaderProgram.

Plusieurs nouvelles classes font leur apparition :

1. QOpenGLContextGroup : groupe de contextes OpenGL pouvant partager des ressources. Cette classe est gérée automatiquement par les objets QOpenGLContext ;
2. QOpenGLFunctions : fournit un accès indépendant de la plateforme aux fonctions d’OpenGL ;
3. QOpenGLPaintDevice : permet de dessiner dans un contexte OpenGL avec QPainter ;
4. QOpenGLStaticContext : manque de documentation ;
5. QOpenGLContextData : manque de documentation ;
6. QWindowsGLContext : manque de documentation.

Que faut-il modifier pour utiliser OpenGL dans Qt5
Tout d’abord, il faut Qt5. Le plus simple est d’utiliser les dépôts PPA sur Ubuntu : https://launchpad.net/~forumnokia/+archive/fn-ppa. Qt5 sera installé dans le répertoire /opt/qt5. Pour ajouter cette version de Qt dans QtCreator, il faut aller dans le menu « Outils » puis « Options… », allez dans « Compiler et exécuter… » puis l’onglet « Versions de Qt ». Cliquer sur « Ajouter » et aller chercher le fichier « /opt/qt5/bin/qmake ». Voilà, Qt5 est prêt à être utilisé.

Normalement, vous pouvez utiliser vos projets directement, mais il est préférable de prendre l’habitude d’ajouter le module « widgets » (remarque : l’ajout des modules core et gui n’est pas obligatoire puisqu’ils sont inclus par défaut) :

Amusez-vous bien !

Quelques rappels
Les geometry shaders sont optionnels et s’intercalent entre les vertex shaders et les fragment shaders. Ils travaillent sur des primitives (triangle, ligne, points, avec un maximum de 6 vertices) et permettent de générer d’autres primitives. Ils sont disponibles dans le Core depuis OpenGL 3.2 / GLSL 1.5 ou avant avec l’extension GL_ARB_geometry_shader4 (en ajoutant le code #extension GL_EXT_geometry_shader4 : enable dans le geometry shader).

Lors de l’appel à glDrawArray ou glDrawElement, il faut que le type spécifié corresponde au type d’entrée du geometry shader. Les correspondances autorisées sont :

1. points : GL_POINTS
2. lines : GL_LINES, GL_LINE_LOOP ou GL_LINE_STRIP
3. triangles : GL_TRIANGLES, GL_TRIANGLE_FAN ou GL_TRIANGLE_STRIP
4. lines_adjacency : GL_LINES_ADJACENCY
5. triangles_adjacency : GL_TRIANGLES_ADJACENCY

Les nouveaux types ADJACENCY (GL_LINES_ADJACENCY, GL_LINE_STRIP_ADJACENCY, GL_TRIANGLES_ADJACENCY et GL_TRIANGLE_STRIP_ADJACENCY) permettent d’accéder aux vertices des primitives voisines de la primitive en cours de traitement.

Un exemple simple
L’exemple choisit est tres tres classique. Il permet d’afficher le mailage d’un mesh, les vecteurs normaux des faces et de calculer les vecteurs normaux de chaque face (flat mode). Cet exemple me permet également d’introduire quelques classes simples, pour lire un fichier .obj (version simplifiee), calculer les vecteurs normaux, initialiser un contexte GL avec Qt.

Pour l’affichage des vecteurs normaux et des triangles, on a besoin des positions et des normales, que l’on passent donc aux shaders en attributs.

Pour afficher les vecteurs normaux dans le geometry shader, on prend un seul vertex en entree (input = points) et l’on retourne une ligne (output = lignes, size = 2), dont le premier point est la position du vertex et le second point est la position du vertex auquel on ajoute le vecteur normal (multiplie par une constante, passee comme uniform, pour modifier la longueur du vecteur)

Pour afficher les triangles, on recupere un triangle en entree (input = triangles) et l’on retourne 3 lignes (output = lignes, size = 6). Chaque points correspond a la position d’un vertex decale legerement par le vecteur normal (pour que les lignes soient bien visibles et ne soient pas cachees par les triangles).

Télécharger le projet d’exemple

A suivre…

1. Shrink, explosion, subdivision, silhouette, hedgehog
2. Explosion, cheveux
3. Instanciation et culling
4. Instanciation et culling

L’instanciation
Lorsque l’on souhaite afficher de nombreux objets, la première approche pourrait être de faire plusieurs appels à glDrawArrays et glDrawElements. Le nombre d’appels aux fonctions de dessin peut cependant diminuer fortement les performances. Une optimisation possible est d’utiliser glMultiDrawArrays ou glMultiDrawElements, qui prennent des tableaux de données et permettent donc de faire qu’un seul appel. Cependant, il est nécessaire d’envoyer les données correspondantes à tous les objets que l’on souhaite créer, ce qui peut saturer la bande passante du GPU.

L’instanciation proprement dite permet de créer plusieurs instances d’un objet. On envoie les données que pour un seul objet, ce qui réduit la bande passante.

Pour personnaliser chaque instance, on fournit un tableau de données (Instanced Array), chaque élément du tableau correspondant à une instance. On pourra passer ainsi modifier la position des instances, les paramètres de texture pour personnaliser les instances, ajouter du bruit, etc. Le paramètre divisor permet de spécifier quand on passe à l’élément suivant dans un buffer. Pour divisor = 0, chaque vertex lit un nouvel élément dans le buffer. Avec divisor = 1, chaque instance lit un nouvel élément. Avec divisor = 2, un nouvel élément est lu toutes les 2 instances, etc.

Un exemple simple
Le code d’exemple affiche des cubes en utilisant glDrawElementsInstanced. Le curseur permet de sélectionner le nombre d’instances à créer. Le bouton permet de basculer entre la vue des cubes pleins et en fil de fer. Les FPS et le nombre d’instances sont indiqués dans le titre de la fenêtre. Je peux obtenir plus de 10 000 instances en même temps à 30 FPS (soit plus de 120 000 triangles) sur mon portable équipé d’une 8600M GT.

Pour ceux qui testeraient avec du matériel plus puissant, il est possible d’augmenter le nombre d’instance maximal en modifiant le facteur multiplicateur à la ligne 127 du fichier glwidget.cpp ou la valeur maximale du QSlider à la ligne 22 du fichier mainwindow.cpp. J’ai pu ainsi créer plus de 400 000 instances (4,8 millions de triangles) avant d’arriver à 30 FPS sur une tour équipée d’une GTX 460.

Télécharger le projet d’exemple

Au suivre…
* gpu gems chap 7
* http://sol.gfxile.net/instancing.html