Les langages de programmation évolués
Arrivé
à ce stade de l’article, je me devais de revenir, au moins
brièvement, sur un point essentiel de la révolution qui
est en train de s’opérer dans le grand monde de la programmation
des jeux vidéo et des cartes graphiques, et sur lequel l’actualité
est passé beaucoup trop rapidement à mon sens en comparaison
de l’ampleur de la chose : l’arrivée des langages de
haut niveau pour le ‘shading’.
Il y a maintenant plusieurs mois, à grand renfort d’annonces,
les deux protagonistes qui nous intéressent aujourd’hui ont
annoncés leurs langages de programmation respectifs : le Cg pour
nVidia, et le RenderMonkey d’ATI. Côté API, il s’agit
du High Level Shading Language de DirectX 9, et du GLSlang d’OpenGL.
La problématique de départ ? Aider au maximum les développeurs
et les programmeurs à tirer partit de toutes les possibilitées
embarquées par les dernières cartes 3D. En effet, la situation
était devenue préoccupante devant l’écart qui
séparait l’arrivée des nouvelles avancées de
nos cartes graphiques, et leur intégration réelle dans les
jeux, phénomène en partit aggravé par le passage
jusque là obligatoire des API, et du temps nécessaire pour
que DirectX ou OpenGL soient distribués dans des nouvelles versions
supportant ces fonctions.
En somme, nous retombons au cœur de l’éternel problème
de ce décalage extrêmement dommageable, et ATI tout comme
nVidia s’en sont bien rendu compte, le vrai problème étant
le nivellement par le bas des configurations des joueurs sur PC.
Pour comprendre le sens de ces langages de haut niveau, nous n’avons
qu’à nous pencher sur l’évolution qu’a
suivie la programmation processeur jusqu’alors.
Au début, le seul moyen de programmer un ordinateur était
de lui faire détecter des états logiques vrai et faux, que
l’on codait à l’aide de 0 et de 1 : le binaire fut
le premier langage de programmation à part entière, que
l’on a plus tard redéfinit comme un langage de bas niveau.
En 1950, Alan Turing et Maurice V.Wilkes de l'université de Cambridge
mirent au point le premier clavier en tant que périphérique
d’interface. Ce n’était plus des 0 et des 1 qui étaient
tapés, mais les noms associés à chaque instruction
du langage machine (les mnémoniques). Or, un ordinateur
n’est, à priori pas capable de comprendre ces mnémoniques
: un programme assembleur se chargeait de les convertir en langage machine.
L’assembleur était né, est constituait le deuxième
langage de bas niveau.
Ce n’est que plus tard que les langages dits de ‘haut niveau’
ont émergés, d’abord avec le Fortran, Lisp, Cobol,
mais ce n’est que dans les années 70 que le C va émerger.
Les différences entre un langage de bas et de haut niveau ? Excessivement
simples. Considérons le morceau de programme suivant, ou l’ordinateur
doit réaliser l’addition 2+3, et inscrire le résultat
(quelque chose qui devrait se rapprocher de 5…) dans la variable
contenant la valeur 3 c'est-à-dire b (exemple idiot imaginé
en deux secondes, mais qui devrait être compréhensible pour
ceux qui ne savent pas ce qu’est la programmation).
En assembleur (bas niveau), cela nous donnerait le code suivant :
mov WORD PTR _a, 2
mov WORD PTR _b, 3
mov ax, WORD PTR _a
add ax, WORD PTR _b
En C (haut niveau) :
{
a=2;
b=3;
b=a+b;
}
Notez bien qu’il ne s’agit ici que d’un fragment de
programme, et que les différentes phases d’initialisation
indispensables à celui-ci sont encore beaucoup plus contraignantes
en asm 86, comparativement au C.
On peut donc aisément concevoir ici a quel point l’assembleur,
proche du binaire et des caractéristiques du CPU, devient très
vite illisible sans de bons commentaires, et devient extrêmement
contraignant à coder pour des programmes d’un taille conséquente.
En revanche, il suffit d’avoir des notions mathématiques
primaires (l’addition, en fait) pour comprendre ce fragment particulier
de code.
L’autre avantage inhérent au C, c’est qu’il
n’a besoin d’être écrit qu’une seule fois
: c’est seulement lors de la compilation que les paramètres
de la plate-forme destinée à exécuter le programme
sont pris en compte, contrairement à l’assembleur, ou l’adaptation
du code en fonction du processeur auquel le programme final est destiné
à être exécuté, devra se faire dès l’écriture
du code.
L’avancé apportée par le Cg et le RenderMonkey est
directement comparable à ce qu’ont étés les
langages de haut niveau pour l’assembleur : permettre aux développeurs
de créer un code beaucoup plus simple, lisible, rapide (nVidia
avance un gain de temps de 70%), facilement modifiable, et quasi générique,
pour la création des shaders. J’aurai pu reprendre deux exemples
différents qui auraient montrés de la même manière
le gain apporté par ces langages de haut niveau sur l’assembleur
en vertex ou pixel shader.
Pour autant, le gain en compatibilité reste limité. En
effet, le programmeur ne pourra pas faire abstraction d’éléments
aussi essentiels que la version de DirectX pour laquelle il code ses effets.
Par exemple, DirectX 8 impose des restrictions très importantes
sur les vertex shaders, tels que la quantité de mémoire
qui leur est allouée, ou encore l’étendue des instructions
supportées, notamment concernant les sauts. Avec DirectX 9.0, ces
limitations sont largement repoussées, de telle sorte que plusieurs
versions resteront indispensables dans un premier temps.
Par ailleurs, en tant que langages de haut niveau, ces deux solutions
cumuleront les inconvénients inévitables qui résultent
de leur utilisation.
En premier lieu, ce seront les performances qui en pâtiront. Et
ceci trouve son explication très simplement dès lors qu’on
se penche sur le fonctionnement des compilateurs des langages de haut
niveau : puisque ceux-ci sont chargés d’adapter des instructions
à des environnement différents qui sont chacun soumis à
des contraintes bien singulières, le compilateur ne peut faire
autrement que d’extraire, pour chaque GPU, un code assembleur qui
sera non optimisé car générique (pour simplifier).
Dans tous les cas, ce code sera moins bon que ce qu’un programmeur
aurait pu faire en programmant en assembleur et en prêtant un minimum
d’attention à l’optimisation.
D’ailleurs, tous les moteurs 3D rapides (comprendre : suffisamment
optimisés) actuels contiennent des pans entiers d’instructions
en assembleur, tout simplement parce que l’impact sur les performances
est réel.
En second lieu, la connaissance, voire la maîtrise de l’assembleur
et des limitations du matériel auquel ils destineront leurs programmes
reste indispensable aux programmeurs qui utiliseront ces langages, car
sinon ils ne seront conscients des erreurs qu’ils auront pu faire
qu’au moment de la compilation, c'est-à-dire une fois le
code finni. Ainsi, si les vertex shaders de DirectX 8 n’autorisent
pas les boucles, DirectX 9 outrepasse cette limitation.
Imaginons donc un programmeur qui, ignorant cette limitation, va utiliser
ce type d’instruction qu’il destinera ensuite à un
GPU DirectX 8. Le Cg « autorisera » son code, mais lors de
la compilation, le compilateur n’aura d’autre choix que de
traduire cette instruction par un code de substitution logiciel, qui ferra
exécuter au GPU l’instruction le nombre de fois demandé.
Le résultat, en terme de performances, sera catastrophique, et
pourtant le programmeur en question ne s’en rendra compte qu’à
la compilation, voire à l’exécution.
Pour revenir sur la problématique initiale, la plus grande différence
qui subsiste entre le Cg et le RenderMonkey est que la solution de nVidia
est censé être un tout nouveau langage de programmation (Cg
= ‘C for graphics’), là ou ATI nous propose carrément
un environnement de développement à part entière.
En fait, en l’état actuel, ce que nous propose ATI est très
proche de Microsoft Visual Basic, et cette similitude n’est évidemment
pas due au hasard…
Au final, on ne peut que se réjouir de ces évolutions car,
si elles ne sont pas parfaites ni réellement novatrices si l’on
considère réellement ce que propose DirectX ou OpenGL au
programmeurs, qui aujourd’hui serait d’accord pour laisser
tomber les langages de haut niveau pour retourner à l’assembleur
?