Avec l'évolution des cartes graphiques, de nouvelles fonctionnalités ont été ajoutées pour permettre une plus grande flexibilité dans le pipeline de rendu au niveau du traitement des sommets (aussi appelé « vertex », de l'anglais) et des fragments (pixelss). Ces éléments sont devenus programmables à l'aide de shaders de fragments et de sommets.
À l'origine, cette fonctionnalité s'obtenait en écrivant des shaders en ARB assembly language(en), une tâche complexe et peu intuitive. L'OpenGL Architecture Review Board a créé l'OpenGL Shading Language pour fournir une méthode plus intuitive de programmation des processeurs graphiques tout en conservant les avantages d'un standard libre qui a fait l'histoire d'OpenGL.
Initialement introduit comme une extension d'OpenGL 1.4, GLSL a été officiellement inclus dans le noyau d'OpenGL 2.0 en 2004 par l'OpenGL ARB. Il s'agissait de la première révision majeure d'OpenGL depuis sa version 1.0 en 1992.
La possibilité d'écrire des shaders pouvant être utilisés sur la carte graphique de n'importe quel fournisseur de matériel prenant en charge le GLSL.
Chaque fournisseur de matériel inclut un compilateur GLSL dans son pilote, permettant ainsi à chaque fournisseur de créer un code optimisé pour l’architecture de sa carte graphique.
Versions
Les versions de GLSL ont évolué parallèlement à des versions spécifiques de l'API OpenGL. Ce n'est qu'avec les versions 3.3 et ultérieures d'OpenGL que les numéros de version majeure et mineure de GLSL et d'OpenGL correspondent. Voici les versions de GLSL pour chaque version d'OpenGL :
A l'image du C, le langage GLSL supporte les boucles et les branchements (ex: if-else, for, switch). La récursion est proscrite et son absence est vérifiée durant la compilation.
L'utilisateur peut définir ses propres fonctions mais le langage intègre aussi des fonctions natives. Les fabricants de carte graphique sont susceptibles de les optimiser au niveau matériel. Plusieurs de ces fonctions sont semblables à la bibliothèque mathématique du C tandis que d'autres sont spécifiques à la programmation graphique. La plupart des fonctions natives et des opérateurs peuvent opérer sur des scalaires et des vecteurs (jusqu'à 4 éléments) pour une ou plusieurs opérandes. C'est notamment le cas pour ces fonctions communément utilisées : mix, smoothstep, normalize, inversesqrt, clamp, length, distance, dot, cross, reflect, refract et min et max vectorielles, ainsi que d'autres fonctions telles que abs, sin, pow. Le langage GLSL supporte également la surcharge de fonction (pour les opérateurs et les fonctions natives mais aussi pour les fonctions définies par l'utilisateur), ce qui veut dire qu'il peut y avoir plusieurs fonctions portant le même nom, ou possèdent un nombre ou des types de variables différents. Chacune de ces fonctions peuvent avoir un type de retour différent.
Préprocesseur
Le GLSL définit un sous-ensemble du préprocesseur C (CPP) combiné avec ses propres directives spécifiant sa version et les extensions d'OpenGL supportées. Tout ce qui relate aux noms de fichier comme #include and __FILE__[18] est retiré de CPP.
L'extension GL_ARB_shading_language_include[19] (implementée notamment dans les pilotes Nvidia[20] sur Windows et Linux, et tous les pilotes Mesa 20.0.0[21] sur Linux, FreeBSD et Android) implémente la possibilité d'utiliser #include dans le code source, rendant plus facile le partage de code et de définition entre plusieurs shaders sans manipulation manuelle supplémentaire. Des extensions similaires comme GL_GOOGLE_include_directive et GL_GOOGLE_cpp_style_line_directive existent en GLSL avec Vulkan et sont supportées par le compilateur de référence SPIR-V (glslang, de son nom complet "glslangValidator")[22],[23],[24].
Compilation et exécution
Les shaders GLSL ne sont pas des programmes autonomes. Il est nécessaire d'avoir un programme qui exploite l'API d'OpenGL pour les exécuter. Cette API est disponible sur différentes plateformes (ex: Linux, macOS, Windows) et dans un nombre très varié de langages comme le C, C++, C#, JavaScript, Delphi, Java.
Les shaders en eux-mêmes ne sont que de simples chaînes de caractères transmises pour compilation par le programme utilisant l'API d'OpenGL au pilote du fabricant matériel. Les shaders peuvent être créés à la volée au sein de l'application, ou lus en tant que fichier texte, mais doivent être envoyés au pilote en tant que chaine de caractères.
L'ensemble des API utilisées pour compiler, lier et transmettre les paramètres aux programmes GLSL sont spécifiés dans trois extensions d'OpenGL et sont devenus une partie intégrante d'OpenGL à partir de la version 2.0. L'API a été étendu aux shaders de géométrie à partir d'OpenGL 3.2, aux shaders de tessellation à partir d'OpenGL 4.0 et aux shaders de calcul à partir d'OpenGL 4.3. Ces APIs d'OpenGL se trouvent dans ces extensions :
ARB vertex shader
ARB fragment shader
ARB shader objects
ARB geometry shader 4
ARB tessellation shader
ARB compute shader
Le langage GLSL peut aussi être utilisé avec l'API Vulkan. Il constitue un moyen courant d'utiliser les shaders sous cette API. Les shaders GLSL sont précompilés avant utilisation, ou au moment de l'exécution dans un format de bytecode binaire appelé SPIR-V.