GLSL multiple shaderprogram VS uniforms switches

Question

Je suis en train de travailler sur un shader gestionnaire de l'architecture et j'ai plusieurs questions pour d'autres personnes. Mon choix s'opposer deux conceptions qui sont:

1. Par matériau programme de shaders

=> Créer un shader programme de par les matériaux utilisés dans le programme.

Les inconvénients possibles:

• Considérant chaque objet peut avoir son propre matériel, il implique beaucoup de glUseProgram appels.
• Implique la création d'une multitude de shaderprogram objets.
• Architecture plus complexe que la #2.

Pour:

• Shader code peut être généré spécifiquement pour chaque "options" utilisé dans le matériau.
• Si je ne me trompe pas, les uniformes doivent être définis qu'une seule fois (lors de la shaderprogram est créé).

2. Mondial shader programmes

=> Créer un shader programme par shader fonctionnalité (foudre, la réflexion, la parallaxe de la cartographie...) et l'utilisation des variables de configuration d'activer ou de jeter des options en fonction du matériau à rendre.

Les inconvénients possibles:

• Les uniformes doivent être changés plusieurs fois par image.

Pour:

• Bas shader programmes de comte.
• Moins SP swich (glUseProgram).

Vous remarquerez peut-être que ma tendance actuelle est #1, mais je voulais savoir votre opinion à ce sujet.

• N'initiale des uniformes réglage de l'offset de la glUseProgram appel, les frais généraux (je ne suis pas particulièrement fou de vitesse) ?
• Dans le cas n ° 1, pour la mémoire ou de la performance de la contrepartie, dois-je appeler glLinkProgram qu'une seule fois lorsque je crée du PS, ou je doit dissocier/lien chaque fois que j'appelle glUseProgram?
• Sont t-il de meilleures solutions ?

Merci!

Answer 1

Regardons #1:

Considérant chaque objet peut avoir son propre matériel, il implique beaucoup de glUseProgram appels.

Ce n'est pas que les grandes d'un accord, vraiment. La permutation des programmes est dur, mais vous pourriez être la permutation des textures trop, de sorte qu'il n'est pas comme si vous n'êtes pas déjà en train de changer importantes de l'etat.

Implique la création d'une multitude de shaderprogram objets.

Cela va faire mal. En effet, le principal problème n ° 1 est la combinaison explosive de shaders. Alors que ARB_separate_program_objects vous aider, cela signifie toujours que vous avez à écrire beaucoup de shaders, ou de trouver une façon de ne pas écrire beaucoup de shaders.

Ou vous pouvez utiliser un rendu différé, ce qui contribue à atténuer ce. Parmi ses nombreux avantages, c'est qu'il sépare la génération de la fiche de données de calculs que de transformer ce matériau des données dans la lumière de réflectance (couleurs). De ce fait, vous avez beaucoup moins de shaders pour travailler avec. Vous avez un ensemble de shaders qui produit des données de matériaux, et un jeu qui utilise le matériel de données pour effectuer les calculs d'illumination.

Donc, je dirais d'utiliser #1 avec un rendu différé.

Answer 2

Cela dépend vraiment de votre matériel et les exigences spécifiques de votre application.

Un autre con de #2, c'est que votre shader finit généralement pas être aussi efficace, car il doit faire des branchements conditionnels basée sur l'uniforme que vous transmettez. Donc, vous êtes essentiellement de négociation entre moins de temps de commutation de l'état contre une diminution de débit dans votre shader. Cela dépend de qui est le pire.

Vous devriez certainement appeler uniquement glLinkProgram une fois par shader. La compilation d'un shader prend beaucoup plus de temps que de passer déjà compilé les shaders.

Il n'y a pas vraiment de meilleures solutions. Presque tout le monde à la rédaction d'un moteur de rendu doit prendre la décision que vous êtes confrontés.

Answer 3

Sur les appareils mobiles, la ramification dans un shader augmente considérablement le temps de rendu. Vous devez mesurer le temps nécessaire pour changer de programme par rapport à la vitesse de tirage réduite associée au branchement dans une opération répétée par sommet / par texel. Je recommanderais la méthode n ° 1 et examinons comment GPUImage est configuré pour une bonne architecture de shader amical oop.

https://github.com/BradLarson/GPUImage