Performance pixel shader

Hello,

J'ai un pixel shader qui ressemble à ceci:

Code:

---

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:

---

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.

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:

---

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 :aie:)

Merci pour ta réponse.

C'est un pixel shader de deferred shading :P.
- 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:

---

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.

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 ...

Citation:

---

Envoyé par LittleWhite

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

---

Beaucoup plus, non?

Citation:

---

Envoyé par TNT89

Beaucoup plus, non?

---

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

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)

Il me semblait que le maximum de coeurs étaient occupés (nombre qui dépend de la carte graphique mais qui doit être entre 100 et 2000+ de nos jours...).

Citation:

---

Envoyé par zenux

Merci pour ta réponse.

C'est un pixel shader de deferred shading :P.
- 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:

---

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 :aie:)

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 :aie:

[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)

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.

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.

En fait ce n'est pas pour un effet en particulier.

Tous mes objets 3D vont avoir une couleur diffuse, une couleur spéculaire, une valeur spéculaire, etc...
Mais certains d'entre eux utiliseront une valeur, pour tout l'objet, d'autre une texture.
Par exemple, je peux afficher un cube texturé, ou un cube de couleur diffuse rouge.

Pour cela, j’envoie à mon fragment shader un uniform indiquant que j'utilise (ou non) une texture.

Si j'ai une texture, alors gl_FragColor = texture.
Si je n'en ai pas, gl_FragColor = couleur.

Et je fais ça pour chaque composante de mon matériaux : spéculaire, valeur spéculaire, ambient, normal map....

Du coup mon shader est plein de tests.
Aux vues des explications de bafman, je me demandais s'il y avait un meilleur moyen de gérer ça, pour ne pas plomber les performances de mon application.

Je remet en avant mon histoire de shaders par effet.
Pour moi, le texturing (application de textures) est un effet.

Donc vous allez avoir un pixel shader avec l'application de texture (et donc calcul de la couleur en se basant sur la texture) et un autre pixel shader avec application d'une couleur uniforme ... sans plus.
Bien sur, le code dans les deux pixel shaders sera légèrement différent ... mais au moins ... vous n'aurez pas de test ... et donc une exécution optimale (je pense).

Après, cela demande deux programmes shader dans le progamme OpenGL ... et même peut être une nouvelle hiérarchisation des objets dans le programme.

Hum, je comprends bien ce que tu veux dire LittleWhite, mais ça fait beaucoup plus que 2 shaders.
En effet, il n'y a pas que la composante diffuse à gérer.

Je peux avoir des objets :

_Texture diffuse, Texture Spéculaire, Texture Normale,
_Texture diffuse, Valeur Spéculaire, Texture Normale,
_Valeur diffuse, Valeur Spéculaire, Pas de normalmaping,
....
....

Il y a plein de combinaisons possibles.

Alors, deuxième possibilité (je ne sais pas si c'est possible). On utilise les flags OpenGL (car il y a certains flag) ou des boolean en uniform ... en partant du principe que un booléan à false == 0 et à true == 1, on peut imaginer faire:

Code:

---

couleur = couleurTexture * isTexturing + couleurDiffuse * hasDiffuse + ...

---

On peut utiliser des float à la place des booléans (pour éviter les cast et autre).
Enfin ... c'était une autre idée. Du coup cela limite à faire des shaders que pour normalMapping (qui est un effet complet) ... texturing et lumière (toute lumière).
Par contre ... le problème possible, c'est que l'on n'évitera pas dans l'immédiat le calcul des lumières même lorsque l'on a pas besoin.
Pour ce cas là ... je pense qu'il faudrait utiliser des fonctions (je me demande si je ne surcomplique pas tout ... et si un if ne serait pas plus économique qu'une fonction).
La fonction retourne la couleur pour une telle lumière (genre éclairageDiffus()).
Si on fait:

Code:

---

couleur = hasDiffuse * éclairageDiffus();

---

On peut imaginer que si hasDiffuse == 0 l'exécution saute l'appel de fonction car une multiplication avec 0 donne toujours 0.

Pour faire simple ... restez sur les if :aie: tant que les if sont constant à travers l'exécution de tout le shader pour le pipeline.

2 ou 3 if dans un shader c'est rien, s'ils existent c'est pour qu'on s'en servent

une centaine c'est autre chose...

Tout dépend la plateforme non?

En ce moment je bosse sur WebGL.
Il me faut donc un truc léger.
S'il y'a moyen de faire la même chose de manière moins lourde, je prend :mouarf:

Il me semble que faire un if sur une variable uniforme ne coute rien et qu'opengl fait une espèce de recompilation du shader quand on change ses paramètres.

Citation:

---

Envoyé par math_lab

Il me semble que faire un if sur une variable uniforme ne coute rien et qu'opengl fait une espèce de recompilation du shader quand on change ses paramètres.

---

Ce qui est très intéressant, as-tu une source ?

Malheureusement non. Je me souviens par contre que quelqu'un en avait parlé sur le forum (mais c’était peut être dans le forum directx :P). De toutes façons, même si c'est pas optimisé (et je suis quasiment sur que ça l'est), tant que ça ne change pas par pixel, ça ne cassera pas le parallélisme, et ça aura donc un coût minime. Et si ça change par pixel mais qu'il y a des blocs contigus où le résultat de la condition sera le même, ça peut améliorer les performances si le if permet de sauter un gros paté d'instructions.

Citation:

---

Envoyé par math_lab

Malheureusement non. Je me souviens par contre que quelqu'un en avait parlé sur le forum (mais c’était peut être dans le forum directx :P). De toutes façons, même si c'est pas optimisé (et je suis quasiment sur que ça l'est), tant que ça ne change pas par pixel, ça ne cassera pas le parallélisme, et ça aura donc un coût minime. Et si ça change par pixel mais qu'il y a des blocs contigus où le résultat de la condition sera le même, ça peut améliorer les performances si le if permet de sauter un gros paté d'instructions.

---

Citation:

---

Il me semble que faire un if sur une variable uniforme ne coute rien et qu'opengl fait une espèce de recompilation du shader quand on change ses paramètres.

---

Je pense la meme chose ... je ne crois pas que cela est un cout (c'est pour cela que j'en parlais un peu) (Par contre, je n'ai pas de source ...)

C'est ce que l'on appelle le "thread divergence" :
Normalement, chaque thread d'un bloc exécute la même instruction au même moment sur des données différentes. Si on à un "thread divergence", une partie des threads n'exécute pas les mêmes instructions que les autres : on casse le parallélisme.
Dans le cas où le if correspond à un paramètre uniform, il n'y a pas de "thread divergence" et le parallélisme n'est pas cassé (donc pas de perte de performance).
Pour finir, le compilateur doit effectivement optimiser le code s'il tombe sur un if constant (c'est le B-A-BA de la compilation)

Un peu de lecture : http://perso.ens-lyon.fr/sylvain.col...pers/sympa13_7 (chapitre 5)

Citation:

---

Et je fais ça pour chaque composante de mon matériaux : spéculaire, valeur spéculaire, ambient, normal map....
Du coup mon shader est plein de tests.
Aux vues des explications de bafman, je me demandais s'il y avait un meilleur moyen de gérer ça, pour ne pas plomber les performances de mon application.

---

Comme l'a dit LittleWhite, tu as effectivement 2 possibilités :
- tu donnes l'information de ce qu'il faut afficher dans les buffers : par exemple, tu ajoutes un uniform indiquant s'il faut utiliser les couleurs ou la texture. L’inconvénient est que comme tu dois donner un buffer homogène, tu auras un augmentation de la taille des données à transférer et donc perte de performance
- tu lances plusieurs shaders différents, chaque shader sur un jeu de données différentes
La seconde méthode est plus longue à mettre en place, la première est plus adapté pour des données très hétérogènes

En somme c'est évalué avant que le pipeline ne rentre dans le traitement de chaque pixel. Entre le drawcall et la rasterization quoi, puissant.

Citation:

---

Envoyé par gbdivers

Pour finir, le compilateur doit effectivement optimiser le code s'il tombe sur un if constant (c'est le B-A-BA de la compilation)

---

Du coup, personnellement, ça m'étonnerait beaucoup que le driver recompile les codes de tous les shaders à chaque changement d'une variable "uniform". Tout simplement : on ne lui en donne pas l'ordre et ça implique qu'il ait gardé le code source...

Non biensûr ce n'est pas une recompilation à proprement parlé. Mais étant donné que les uniforms sont gérés comme des constantes, le compilateur de shader peut évaluer les if à l'avance pour tous les fragments par exemple ou faire des bonnes optis en tout cas j'imagine ^^

Non, c'est TNT89 qui a raison : la compilation n'est pas refaite à chaque changement des variables uniforms. Et lors de la compilation, les variables uniforms ne sont pas connu donc il n'est pas possible d'optimiser le if en fonction de leurs valeurs.
Donc en retirant les if, on évite simplement les threads divergences

Oui pas à la compilation c'est ce que j'ai dis, mais il y en a bien une quand même qui est faite après la compil au moment du drawcall vu que tester un uniform est beaucoup plus rapide qu'une variable locale.