Performance pixel shader

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.