Programmable shader

Un shader (anglais, du verbe to shade : ombrager ou estomper, nuancer) est un programme^{[Quoi ?]} utilisé en image de synthèse pour paramétrer une partie du processus de rendu réalisé par une carte graphique ou un moteur de rendu logiciel. Ils peuvent permettre de décrire l'absorption et la diffusion de la lumière, la texture à utiliser, les réflexions et réfractions, l'ombrage, le déplacement de primitives et des effets post-traitement. Par la conception même du processus de rendu, les shaders sont les candidats idéaux pour une exécution parallèle par les processeurs graphiques multiples, situés dans une carte vidéo, permettant un traitement vectorisé soulageant l'unité centrale pour obtenir un résultat plus rapidement.

Les shaders sont flexibles et efficaces. Des surfaces apparemment compliquées peuvent être rendues à partir de géométrie simple. Par exemple, un shader peut être utilisé pour générer un carrelage en céramique à partir de la simple description d'un plan.

Sommaire 1 Différents langages 1.1 Pour le calcul réaliste 1.1.1 RenderMan Shader Language 1.1.2 Gelato Shader Language 1.2 Pour le calcul en temps réel 1.2.1 OpenGL shading language 1.2.2 DirectX High-Level Shader Language 1.2.3 Cg Shader Language 2 Structure pour le calcul en temps réel 2.1 Vertex shaders 2.2 Geometry shaders 2.3 Fragment shaders 3 Exemples d'utilisation des shaders en temps réel 3.1 Per-pixel lightning 3.2 Toon shading 4 Voir aussi

Différents langages

Initialement introduits par Pixar dans son logiciel RenderMan pour la production de films en images de synthèse, et plus particulièrement Toy Story les shaders ont acquis un intérêt croissant alors que le coût des ordinateurs diminuait. À partir de 2001, ils ont été introduits dans les interfaces de programmation 3D temps réel telles que DirectX 8.0 et OpenGL 1.4, puis ont été supportés par les grands constructeurs de cartes graphiques comme nVidia ou ATI. L'avantage principal d'employer des shaders vient de leur flexibilité, qui permet un temps d'élaboration plus rapide ainsi que meilleur marché, mais permet également de rendre les travaux plus riches. Un langage de shader a habituellement des types de données propres comme les couleurs et les vecteurs, mais en raison des divers intervenants industriels et de la forte évolution du secteur, différents langages de shader ont été développés.

Pour le calcul réaliste

Ce genre de langage de shader est conçu pour une qualité maximum d'image. Les propriétés matérielles sont totalement ignorées, peu de compétences de programmation et aucune connaissance du matériel n'est exigée. De tels shaders sont souvent créés par des artistes pour obtenir le bon rendu.

La réalisation de ce genre de shader est habituellement un processus long. La puissance informatique exigée pour obtenir ce genre d'ombrage peut être coûteux en raison de leur capacité à produire des résultats photoréalistes. La majeure partie du temps, le rendu est produit par une grille de calcul.

RenderMan Shader Language

Gelato Shader Language

Pour le calcul en temps réel

Jusqu'à récemment, les programmeurs ne pouvaient pas avoir un tel niveau de contrôle sur le traitement réalisé par les cartes graphiques, mais les langages de shader pour le rendu en temps réel sont maintenant répandus. Ils fournissent maintenant une abstraction sur le matériel et un modèle de programmation plus flexible comparés au paradigme précédent du « tout câblé », suivi de la programmation bas niveau. Ce cumul permet aux programmeurs un plus grand contrôle sur le processus de rendu, et permet de fournir un contenu plus riche à un coût généralement inférieur.

Étonnamment, ces shaders sont conçus pour être exécutés à même le processeur de traitement graphique (GPU) de la carte graphique en se plaçant dans la file de traitement et permettant ainsi des performances optimales. L'architecture des cartes n'a pas eu besoin d'évoluer, étant basée sur un modèle de traitement par flux, le calcul des shaders a trouvé sa place dans la structure globale des cartes.

Ce genre de langage est habituellement dépendant de l'interface de programmation graphique utilisée, bien que quelques applications fournissent également de tels langages intégrant des fonctionnalités limitées.

Historiquement, seulement une poignée de langages ont réussi à s'imposer, et maintenant le marché est fermé, les constructeurs préférant s'aligner sur ceux existants. Une courte description de ces langages est présentée ci-dessous.

OpenGL shading language

Aussi connu sous le nom de GLSL ou glslang, c'est un langage de shader standardisé par l'OpenGL Architecture Review Board (ARB, constitué d’un ensemble de sociétés intéressées par la conception d'une interface standard) qui s’utilise dans OpenGL.

Le langage fournit des éléments riches et cela depuis le début, unifiant le processus de traitement sur la géométrie (vertex processing) et sur les pixels (fragment processing) avec le même ensemble d'instructions, permettant des boucles d'instructions, et (plus généralement) des branchements conditionnels.

Historiquement, le langage GLSL a succédé à diverses extensions comparables qui se trouvaient dans OpenGL, telles que ARB_vertex_program, ARB_fragment_program et d’autres. Ces extensions utilisent toutefois un langage de bas niveau de type assembleur avec certaines restrictions, et leur utilisation est maintenant déconseillée. Ces deux extensions ont été également précédées par d'autres propositions qui ne sont pas restées dans les dernières spécifications.

DirectX High-Level Shader Language

Probablement le langage le plus populaire, principalement de par le support de Microsoft, combiné avec le fait qu'il soit le premier à proposer un langage de type C — contre un langage de type assembleur — utilisable pour générer des rendus en temps réel. Le high level shader language, couramment appelé HLSL, est une abstraction du langage de shader de type assembleur. Ces langages de bas niveau ont été introduits à partir de DirectX 8.0 en version 1.x, puis en version 2.x et 3.x avec DirectX 9 et ont été supportés rapidement par les constructeurs. Le HLSL a devancé l'apparition de son principal rival, le GLSL, toutefois il a dû ensuite être étendu par deux fois pour bénéficier de fonctionnalités qu'il ne possédait pas.

Cg Shader Language

Ce langage développé par nVidia a été conçu pour faciliter et optimiser la production intégrée. Le langage fournit une interface de programmation indépendante et est livré avec un éventail large d'outils libres favorisant son utilisation en production.

Les premières implémentations de Cg étaient plutôt restrictives. Il permettait à la majorité des matériels de le supporter, mais était tout de même innovant comparées aux méthodes précédentes. Le Cg semble avoir bien survécu à l'introduction des langages shader de nouvelle génération, principalement par son avance prise sur le secteur de la création de contenu numérique, toutefois le langage semble rarement être employé dans les produits finaux. À noter cependant que les jeux vidéo développés sur la console de jeu de Sony, la PlayStation 3, implémentent leurs shaders avec ce langage.

Une fonctionnalité intéressante que Cg propose réside dans l'utilisation de connecteurs, des types de donnée spéciales pour lier les différentes étapes du processus. Des connecteurs sont utilisés pour définir l'entrée de l'application à l'étape de traitement géométrique (vertex processing) et aux attributs à interpoler dont le résultat est utilisé pour le traitement des pixels (fragment processing).

Structure pour le calcul en temps réel

Plusieurs approches des shader existent en raison des diverses applications technologiques visées. Les langages de shader pour la production de film sont habituellement d'un niveau d’abstraction plus élevé, et évitent d'utiliser du code spécifique pour l'éclairage ou l'ombrage. En revanche, les shader temps réel intègrent le calcul d'ombre et de lumière. Dans ces langages, les lumières sont passées à la fonction de shader en tant que paramètres.

Il existe actuellement deux applications différentes des shaders dans les langages temps réel. Bien que leurs fonctionnalités aient convergé — il est ainsi possible d'écrire un vertex shader en utilisant les mêmes fonctions qu'un fragment shader — les différents rôles imposent des limitations propre à chacun qu’il faut reconnaître.

Vertex shaders

Dans la liste des tâches graphiques séquentielles nécessaires à l'affichage d'une image 3D, la tache du vertex shader se situe un niveau de la tâche dite de « transformations et éclairage ». En pratique, c'est une tache au sein du pipeline graphique qui doit calculer la projection de coordonnées des sommets des primitives à partir de l'espace 3D dans l'espace écran.

Contrairement à sa contrepartie « fixe » dans le pipeline, aucune fonction par défaut ne peut être utilisée pour arriver à ce but. Le programmeur se doit donc d'expliciter totalement la procédure de projection à la carte graphique. Pour ce faire, le programmeur se situe dans un environnement de shader avec des registres spécifiques à l'architecture qui définissent aussi les entrées et les sorties du problème.

Un programme shader agit sur un seul sommet unique et isolé. L'architecture hautement parallèle des cartes graphiques actuelles interdit les lectures interdépendantes, c’est-à-dire accéder aux informations d'un sommet voisin par exemple.

Dans les registres d'entrées, on trouve la structure qui a été utilisée lors de l'écriture en mémoire graphique du « vertex buffer » (le tableau des sommets). On y retrouve le plus souvent dans cette structure, un vecteur contenant la position du sommet, parfois une couleur, parfois une coordonnée de texture ou plusieurs, et parfois une normale.

Le shader doit renvoyer une structure de donnée contenant des champs dont la définition est libre qui sera passée en entrée du pixel shader plus tard. Dans la plupart des « vertex programs » on retrouve la fameuse projection 3D vers 2D. En effet selon la formule de mathématique Y=MX (Y vecteur image, M matrice de l'application, X vecteur antécédent), on peut appliquer une transformation linéaire par une multiplication vecteur-matrice. Nous voulons que la matrice M qui effectue la transformation soit ici la matrice de l'application « projection ». On lui donne la dimension 4×4 (la 4^e dimension comporte une coordonnée homogène) pour se multiplier avec les vecteurs de la carte graphique qui sont de dimension 4. On utilise une coordonnée homogène car certains problèmes comme la projection ou la translation sont insolubles en algèbre linéaire de dimension 3. Finalement, le « vertex program » le plus courant, en quelque sorte le « hello world » du vertex shader pourrait s'écrire en HLSL tel que suit :

 float4x4 WorldViewProj;

 float4 VS_Transform(float4 position : POSITION0)
 {
     return mul(WorldViewProj, position );
 }

'WorldViewProj' est une variable dite uniforme qui se trouve mappée sur un des registres des constantes lors de la compilation. On l'appelle ainsi car elle est le résultat de la matrice de vue multipliée par la matrice de déplacement du monde, multipliée par la matrice de projection. Ceci permet de placer le point d'observation correctement dans la scène.

Geometry shaders

Nouveaux depuis les shader model 4.0, les geometry shaders permettent de modifier la géométrie de chaque polygone primitif. Il est exécuté entre le vertex shader et le fragment shader.ils ont été implémenté avec la nouvelle version DirectX 10 et OpenGL 3.0

Un geometry shader prend en entrée les donnée d'un primitif, et renvoie un ou plusieurs primitifs (incluant souvent le même qu'en entrée) éventuellement modifiés.

Fragment shaders

Le fragment shader ou pixel shader est un shader dont le but est de calculer la couleur de chaque pixel individuellement. Il prend ainsi en entrée les données de chaque pixel de l'image (position, coordonnées de texture, couleur) et renvoie la couleur de celui-ci.

Voici un exemple de fragment shader en Cg :

float4 main	(float3 color : COLOR0,
		 float3 texCoords : TEXCOORD0,
		 uniform sampler2D texture)
{
	float3 texColor = tex2D(texture, texCoords).rgb;
	return float4(color * texColor, 1);
}

Exemples d'utilisation des shaders en temps réel

Per-pixel lightning

En temps réel, l'éclairage est souvent calculé au moment du T&L ou du vertex shader (voir ombrage Gouraud). Il est néanmoins possible d'obtenir un éclairage beaucoup plus précis grâce au per-pixel lightning.

Sa mise en oeuvre se fait en deux étapes : le vertex shader calcule la provenance de la lumière pour chaque vertex et l'indique au pipeline, généralement via l'utilisation ainsi détournée des coordonnées de texture.

Le pixel shader récupère ensuite ces données ainsi que la normale virtuelle du pixel en cours de traitement dans le sampler de la bump map. Il connaît alors la normale et la provenance de la lumière, il peut donc calculer l'éclairage du pixel qu'il lui suffira de multiplier avec la couleur provenant de la texture classique.

Toon shading

Le toon shading ou cel-shading consiste à créer un rendu similaire aux bandes dessinées.

Voir aussi

• Rastérisation
• Synthèse d'image 3D

• Portail de l’informatique