Introduction au GLSL

Date de publication : 10/09/2007 , Date de mise à jour : 10/09/2007

Version PDF (Miroir) Version hors-ligne (Miroir)

. Introduction
1. Qu'est-ce qu'un shader ?
1.1. La programmation GPU
1.1.1. En assembleur ?
1.1.2. Plusieurs types de shaders
2. Que permettent-ils de faire ?
2.1. Qu'est-ce que le traitement d'un vertex et d'un pixel ?
2.2. Un exemple concret ?
3. Et techniquement parlant ?
3.1. Quel IDE pour la programmation de shaders ?
. Conclusion

. Introduction

1. Qu'est-ce qu'un shader ?

À l'origine pensé par Pixar pour ses animations vidéos, les shaders ont fait leur apparition dans le domaine du jeu vidéo assez récemment et sont aujourd'hui indispensables pour qui veut réaliser des effets graphiques un temps soit peu évolués. Le GLSL est un langage de programmation de shaders conçu par OpenGL, pour OpenGL. Sa syntaxe est basée sur celle du langage C, langage que j'utiliserais d'ailleurs pour mes exemples de code lorsque nous devrons faire intervenir l'API OpenGL dans la gestion des shaders.

1.1. La programmation GPU

Le GPU est le processeur de votre carte graphique, c'est lui qui calcule vos rendus 3D. La programmation GPU revient donc à programmer nos calculs de rendus 3D. Les shaders servent à programmer, et donc à contrôler, le pipeline de rendu par défaut de votre carte graphique, appelé le FFP. Les shaders sont des programmes, ils possèdent donc un code source, une compilation et une exécution. Ils se différencient toutefois des programmes écrits en C, C++ ou autre langage réservé à une exécution CPU, de part leur compilation et leur exécution. La compilation d'un shader est effectuée lors du lancement de votre application, et l'exécution se passe au niveau du GPU, contrairement à vos applications habituels qui elles sont traitées par le CPU, et c'est ce qui fait la puissance et la flexibilité des shaders.

1.1.1. En assembleur ?

Quand on parle de la programmation d'un processeur, on pense généralement à l'assembleur. Il existe effectivement des langages assembleur pour programmer un GPU, mais nous ne les traiterons pas dans ce tutoriel. Le GLSL a été développé par l'ARB pour l'API graphique OpenGL afin d'offrir une plus grande souplesse dans la programmation de shaders. À titre de comparaison, DirectX a également développé son propre langage haut niveau pour la programmation de shaders, il s'agit du HLSL (High Level Shading Language). Voici un exemple du langage GLSL :

void main(void)
{
    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_Position = gl_Vertex * gl_ModelViewMatrix;
}

Il s'agit là d'un simple vertex shader.

1.1.2. Plusieurs types de shaders

Il est important de distinguer deux types de shaders différents, remplissant chacun des fonctions bien définies et aucunement identiques :

les vertex shaders : ce sont des shaders qui interviennent lors du traitement de chaque sommet. Dans les vertex shaders vous pourrez modifier le calcul des différents attributs de vos sommets ;
les pixel shaders : aussi appelés fragment shaders, ils permettent de traiter le rendu de chaque pixel qui s'affichera à l'écran. Plus précisément, ils traitent le pixel avant qu'il ne soit dessiné à l'écran, lorsqu'il n'est encore qu'un fragment.

Les shaders vous permettent donc de programmer le traitement de chaque sommet ainsi que de chaque pixel que vous dessinerez.

Une nouvelle génération de shaders vient de faire son apparition avec le G80 (GeForce8) de nVidia, les geometry shaders. Cette technologie étant assez nouvelle et peu répandue, je n'en parlerai pas.

2. Que permettent-ils de faire ?

Les shaders permettent donc de programmer la fonction de traitement d'un vertex ainsi que d'un pixel. Mais à quoi cela rime-t-il ? Quel utilité cela peut-il bien avoir ?

2.1. Qu'est-ce que le traitement d'un vertex et d'un pixel ?

Voilà une bien bonne question. Quand vous envoyez des données de sommet à OpenGL via les commandes glVertex*(), glColor*(), glTexCoord*(), glNormal*(), ... (ou par des tableaux via gl*Pointer() ) OpenGL les stocke et les associe à un ou plusieurs triangles bien définis. Le traitement de ce triangle se décompose par le traitement de ses 3 sommets, puis par une interpolation des données de ses sommets pour obtenir un triangle plein. Ce sont ces deux dernières étapes qui sont traitées respectivement par le vertex et le pixel shader. Le traitement d'un vertex consiste à lui appliquer des transformations matricielles pour obtenir les données des sommets définitives qui seront ensuite interpolées. Le pixel shader reçoit des données interpolées de couleur et autres attributs traités dans le vertex shader, il définit ensuite grâce aux informations reçues quelle sera la couleur finale du pixel. Quel est l'intérêt des shaders ? Pensez bien qu'il y en a un. Il y a deux grands avantages à utiliser les shaders. Le premier est qu'ils permettent une énorme flexibilité de rendu. En gérant le rendu de chaque pixel vous avez un contrôle quasi absolu sur vos rendus 3D et vous pouvez ainsi réaliser beaucoup d'effets impressionnants sans trop vous compliquer la vie. Le second intérêt réside dans leur principe même. Étant exécutés par la carte graphique, les shaders n'utilisent pas le processeur (CPU), ce dernier peut alors souffler un peu et se concentrer sur la gestion du reste de votre application. Dans cette optique de décharger le processeur, les shaders ont également un énorme intérêt si l'on utilise un langage assez "gourmand" en CPU, comme le C# ou le Java, qui sont moins rapides que le C par exemple.

2.2. Un exemple concret ?

Il est temps de vous montrer à quoi ressemble un rendu utilisant les shaders, bien que vous en ayez déjà probablement vu. Voici deux captures d'écran de la même scène, l'une utilisant le FFP standard, l'autre, des shaders. <image>http://www.siteduzero.com/uploads/fr/files/64001_65000/64880.jpg</image> Rendu standard <image>http://www.siteduzero.com/uploads/fr/files/64001_65000/64881.jpg</image> Rendu avec shaders (source du modèle 3D et des textures : http://mdeverdelhan.developpez.com/tutoriel/dynamiclight/tutoriel6/)

3. Et techniquement parlant ?

Malgré quelques explications en début de chapitre, il est important que vous sachiez avec un peu plus de précision comment fonctionne l'implémentation théorique des shaders au sein d'une application OpenGL. Il est impératif de distinguer deux choses :

la programmation d'un shader en GLSL ;
son utilisation au sein d'une application OpenGL.

Ces deux choses sont totalement différentes, il est primordial de bien faire leur distinction. Nous avons d'une part la programmation du shader lui-même, c'est-à-dire le codage de la fonction qu'il remplira, l'effet graphique qu'il produira, et d'autre part la définition de son utilisation, quand et comment l'utiliser dans notre application, tout cela via des appels à l'API graphique. Nous pouvons comparer cela à l'utilisation des textures, nous avons d'une part la création de la texture, soit la création de l'image via un logiciel de dessin 2D, et d'autre part le chargement et l'utilisation de cette texture dans notre programme. L'idée est la même pour les shaders, nous allons tout d'abord programmer un shader, nous placerons son code source dans un fichier, puis nous programmerons notre application OpenGL et nous chargerons via celle-ci le code source de notre shader afin de l'utiliser à notre convenance au sein de notre application.

3.1. Quel IDE pour la programmation de shaders ?

Il n'existe pas beaucoup d'éditeurs de texte qui colorent le langage GLSL. On peut toutefois citer Kate, qui bénéficie du support de la coloration syntaxique du GLSL, il active automatiquement celle-ci pour tout fichier ayant pour extension .vert pour les vertex shaders, ou .frag pour les fragment shaders (ou pixel shaders).

. Conclusion

Pour les adeptes des spécifications, voici celles du langage GLSL.

Version PDF (Miroir) Version hors-ligne (Miroir)

Cette crï¿½ation est mise ï¿½ disposition sous un contrat Creative Commons.