Discussion :

[zenux]

Hello,

J'ai un pixel shader qui ressemble à ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
for(int j=0; j<100;j++)
{
	//..
	float NdotL = dot(normal, vertexToLightNormalized);
	if(NdotL > 0.0001){
		color += att * (diffuse * NdotL);
	}
}

Nombre de fps que j'obtiens avec ce shader: 44fps.

Si je change mon shader comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
for(int j=0; j<100;j++)
{
	//..
	float NdotL = max(dot(normal, vertexToLightNormalized), 0.0);
	color += att * (diffuse * NdotL);
}

Nombre de fps que j'obtiens avec ce shader: 107fps.

La difference de fps me parait assez énormeeeee: comment ça peut s'expliquer ?
Existe t-il des articles sur Internet qui parle de l'optimisation des pixel shaders ?

Merci d'avance.

[LittleWhite]

Bonjour,

Moi j'ai appris que dans un shader on ne doit pas faire de boucles, ni trop de branchements (des if)
Donc lorsque je vois:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(int j=0; j<100;j++)

Et bah je tique un peu.

Si vous voulez énormément de lampe (moi j'ai réussi à faire plus de 512 points de lumière) il faut utiliser du deferred shading (une technique en deux passes). En résumé, cela permet de faire le calcul d'une lampe que au endroit où il faut et non sur toute la scène (ce que vous, vous faites).

En terme de calcul que vous demandez:
(Le pixel shader pouvant parcourir la taille de la fenêtre au maximum) cela lui fait déjà
1024x768 pixels.
Maintenant, vous lui demandez de faire 100 itérations pour chaque pixel:
1024x768x100

Et la mauvaise nouvelle ... c'est qu'il peut faire plus que la taille de la fenêtre car si deux objets sont l'un derrière l'autre ... dans certains cas ... les deux objets peuvent se retrouver calculer dans le pixel shader ... et ça peut faire énorme dans une scène 3D complète. (surtout lorsque l'on ne calcul pas que l'éclairage)

Pour résumé ... ne faites pas des boucles de 100 itérations dans un pixel shader. Pour le deferred shading, on trouve pas mal de document (notamment en anglais :p dans les GPU Gems de NVidia (voir leur site, c'est libre)).

Note hors sujet: J'ai eu un code qui ne compilait pas avec DirectX car trop de boucles dans le code ... (notamment pour la lumière )

[zenux]

Merci pour ta réponse.

C'est un pixel shader de deferred shading .
- Dans ma première passe, je remplis mes textures de diffuse, depth, normal, etc.
- Dans ma seconde passe, je lis ces textures et j'applique l'éclairage.

Dans ma seconde passe, je suis bien obligé de boucler sur toutes mes lampes, non ? (je peux biensur éviter d'envoyer les lampes qui n'affecte pas du tout la scène à mon shader).
Ensuite dans la boucle, je peux ajouter un test du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if(!attenuationOfLight[j] > 0.0){
  /*J'applique l'éclairage sur ce pixel*/
}else{
  /*La lampe 'j' n'affecte pas ce pixel, je passe à la lampe suivante.*/
  continue;
}

Ma question initial était surtout: pourquoi un 'if' est bcp bcp plus lent qu'une fonction 'max' ou une addition, etc. J'aimerai connaitre la raison technique.

Merci d'avance.

[LittleWhite]

Euh le deferred shading, c'est pour éviter la boucle. Comment ? Simplement que dans la deuxième passe (passe des lampes) on va appliquer les shaders que sur les parties éclairés (en dessinant un rectangle autour de la lampe).
Ce qui évite:
- De dessiner les zones complètement noirs (pas de lampe)
- De passer 100 fois alors que seulement 2 lampes éclaire cette zone

Pour les branchements / contre les commandes built-in, c'est parce que le GPU n'est pas un CPU (Wouhou !). Plus précisément, le GPU est spécialisé dans les calculs, qui multithread de base (il éxecute le pixel shader en parallèle sur 8 ou 16 pixels à la fois) et que, à cause de sa spécialisation dans les calcul, les tests le dérange ...

[TNT89]

(il éxecute le pixel shader en parallèle sur 8 ou 16 pixels à la fois)

Beaucoup plus, non?

[LittleWhite]

Beaucoup plus, non?

Bah peut être ... cela dépend de la carte graphique ... (je ne sais pas précisément ).

Par contre si j'ai bien compris un prof, les cartes graphiques sont capables de faire les calculs blocs par blocs de pixels (genre ... on a une surface uniforme assez grande ... celle-ci peut être calculé par petits blocs au lieu de simple pixels)

[bafman]

Merci pour ta réponse.

C'est un pixel shader de deferred shading .
- Dans ma première passe, je remplis mes textures de diffuse, depth, normal, etc.
- Dans ma seconde passe, je lis ces textures et j'applique l'éclairage.

Dans ma seconde passe, je suis bien obligé de boucler sur toutes mes lampes, non ? (je peux biensur éviter d'envoyer les lampes qui n'affecte pas du tout la scène à mon shader).
Ensuite dans la boucle, je peux ajouter un test du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if(!attenuationOfLight[j] > 0.0){
  /*J'applique l'éclairage sur ce pixel*/
}else{
  /*La lampe 'j' n'affecte pas ce pixel, je passe à la lampe suivante.*/
  continue;
}

Ma question initial était surtout: pourquoi un 'if' est bcp bcp plus lent qu'une fonction 'max' ou une addition, etc. J'aimerai connaitre la raison technique.

Merci d'avance.

ha mais c'est très simple... Les cartes graphique moderne sont conçu pour faire du traitement numerique très rapide. Pour cela, elle sont decomposé en unités de calculs. Pleins. Tout pleins d'unités de calculs, un peut comme les core des CPU actuels, mais moins généraliste et beaucoup plus nombreux. Du coup, ta carte graphique est capable de traiter pleins de pixels en parallèle. Le seul problème, c'est qu'elle est aussi capable de faire des calculs de dérivations. Pour avoir une dérivé partielle, il faut, au minimum, avoir un voisin en x et un voisin en y. Problème résolu simplement en traitant toujours les pixel par petits paquets (en général, 2x2). L'avantage de cette technique, c'est qu'on gagne sur plusieurs points :
* On a une ganularité de calcul assez faible pour pouvoir saturer les unités de calculs
* 2x2, tiens, justement, ça fait 4 !!! ce qui est le nombre d'operation faite par les operateur SIMD 128 bits classiques
* les caches sont contents d'avoir une localité géographique

du coup, quand on a un code homogene dans son traitement, ça va vite. Très vite.

Problème: justement, quand on ajoute un if, on a plus du code homogène (le pixel 1 peut aller d'un coté du if quand le pixel 2 peut aller de l'autre coté)
Du coup, le compilateur de shader perd pleins (vraiment) de possibilité d'optimisation. Déjà, la première, c'est qu'il ne fera probablement pas de SIMD (aïe). La deuxième, c'est qu'il devra utilisé une unité logique pour faire la comparaison, ce dont il est peu pourvu car il est justement conçu pour faire du calcul. La troisième, c'est que (a priori, je n'ai pas verifié) ce genre de processeur est du type "out of order", ce qui signifie qu'il peut réordonnancer les opérations en interne pour gagner du temps, mais du coup, un branchement raté, c'est une catastrophe, il doit vider sont pipeline pour ré exécuter le code... (et en plus, je ne pense pas qu'il y ai de branch target buffer sur GPU )

Bref, si les GPU ne sont pas rapide pour exécuter des if, c'est qu'ils sont conçu pour faire du calculs et pas trop d’arithmétique (mais ils peuvent quand même en faire.)
Une règle assez efficace, est que si tu peut faire le même calcul sans branchement, généralement, il ira plus vite même si il fait du calcul inutile (mais pas trop quand même).

Par contre, le cas des boucles for est généralement différent[1]. En effet, une boucle peut être facilement découpé en 2 parties : les N premier éléments (avec N un multiple de 4) et les M suivant (avec M <= 3). Du coup, on peut facilement utiliser du SIMD dans la première boucle, et la seconde est certes lente, mais limité à 3 éléments max.

pfuiiiii, j'ai encore pondu un pavé. Zut. Et du coup, mon introduction en disant que c'etait simple perd un peut de sons sens

[1] je ne prend pas en compte ici les boucle for qui n'en sont pas (condition de terminaison non constante, break, continue et autre truc qui facilite la vie du programmeur mais pas de l'optimiseur)

[themoye]

Bonsoir !

Sujet fort intéressant !

Mais alors, comment gérer efficacement plusieurs cas?
Je pense notamment à la présence ou non de textures diffuse / spéculaire / ambiante...

A l'heure actuel, mon fragment shader reçoit un uniform bool pour chaque texture.
Je teste chaque booléen, s'il est true j'utilise la valeur de texture, sinon j'utilise une valeur passée par uniform (couleur matériau, intensité spéculaire...).

Existe t'il une façon plus propre, plus adapté aux shaders ?
Histoire de limiter les nombres de tests.

[LittleWhite]

On peut penser de faire un shader par effet (un effet == diffuse + speculare ; un autre effet == diffuse + globale) par exemple.

Sinon je n'ai pas vraiment compris quel effet vous voulez faire, mais il y a surement mieux.