1)
Un shader, ca peut s'apparenter effectivement aux "shaders" de q3. sauf que c'est pas execute au meme endroit, par le meme truc, de la meme facon. bref, en fait ca a rien a voir, sauf dans le concept. (
)
Un shader, c'est un binaire pour le GPU, qu'il va etre executer, dans un ou plusieurs pipelines differents suivant le type de shader et le shader model supporte (plus de details plus bas)
c'est comme un .exe, mais pour le GPU quoi. Comme pour un programme CPU, tu peux ecrire un shader directement en ASM, ou avec un des langages haut niveau: HLSL, GLSL, Cg, CUDA, ou OpenCL.
Apres il se fait compiler en ASM, assembler en bytecode, et uploader sur le GPU, qui va l'executer dans ses (nombreuses) unites d'execution.
d'un point de vue historique, d'abord, y avait le vieux truc classique : le fixed function pipeline, qui etait plus ou moins juste un grosse collection de bourrin de flags et valeurs diverses.
ensuite, t'as eu les register combiners qui se sont greffes la dessus. ils permettaient un peu plus de souplesse dans les combinaisons d'etats de rendus en te donnant quelques fonctions de base avec lesquelles tu pouvais combiner les valeurs composant ton rendu (genre la couleur de ta texture, un vertex stream donne, une valeur uniforme, etc..). mais sont morts quasiment dessuite avec l'arrivee des premiers shaders.
ensuite, les premiers shaders... Petite precision: ce n'est pas DirectX10 qui a "introduit les geometry shaders". Mais plutot: les geometry shaders ne sont supportes par DirectX qu'a partir de la version 10, ils existaient bien avant, et etaient accessible en Cg ou en ASM avec des extensions OpenGL a l'epoque de DX9.
pour parler de versions de shaders, on parle de shader models (abbrevies "SM", genre: SM1.2, SM4.0, etc..).
les geometry shaders, c'est a partir du SM4.0
au debut, les premiers shaders etaient super limites, en instructions, en nombre de texture fetches, de registres uniformes que tu pouvais setter. Les tout premiers ne geraient pas les texture-reads dependants (genre tu sample une texture, et tu sample une 2eme texture avec des texcoords calcules avec le resultat du premier texture fetch).
par exemple les vertex shaders en shader model 2.0 sont limites a 96 instructions.
aucun shader model avant le 3.0 ne supportaient pas le sampling de textures dans le vertex shader (!)
et d'autres limitations du genre.
tu peux voir l'evolution des shader models comme un perfectionnement des unites d'execution des GPUs.
certaines vieilles cartes supportaient a la fois le fixed-function pipeline et les shaders. maintenant, les API graphiques qui gerent encore le fixed-function pipeline (genre OpenGL sur les cartes recentes) l'emulent en construisant des shaders qui font la meme chose derriere ton dos. bref.
et avant le SM3.0 (il me semble bien que c'est le 3..), les pixel et vertex shaders etaient executes par des unites d'execution bien separees. maintenant c'est unifie: c'est les memes unites d'execution qui font tourner les deux.
t'as un resume des limitations ici: http://en.wikipedia.org/wiki/High_Level_Shader_Language
la actuellement on en est au SM5.0, qui introduit la tesselation hardware. Il rajoute 3 nouveaux types de shaders en plus de vertex, geometry, et pixel shaders, entre le vertex et le geometry shader:
- hull shader
- tesselation shader
- domain shader
details ici: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476340(v=vs.85).aspx
du coup le pipeline devient:
vertex -> hull -> tesselation -> domain -> geometry -> fragment
ouai tiens d'ailleurs... DirectX utilise la terminologie "pixel shader", et OpenGL "fragment shader", mais la, c'est OpenGL qui a raison, parceque le "pixel" shader peut etre execute plusieurs fois par pixel, suivant tes settings d'antialiasing notamment, on parle de "fragment", le pixel final est une combinaison de tous ces fragments. donc c'est bien un fragment shader, pas un pixel shader...
mais bon, tout le monde dit pixel shader, alors on va dire pixel shader aussi...
btw, les compute shaders, j'en ai jamais utilise, mais c'est a priori comme les kernels CUDA ou OpenCL.
(question 2 incoming)