2009-11-05 11 views
1

Les puces TBR effectuent le HSR (suppression de la surface cachée) avant le traitement du fragment, de sorte que seuls les pixels visibles sont rendus. Cette fonction ne nécessite aucun tri des objets opaques de l'avant vers l'arrière. Mais j'ai fait une expérience sur mon iPhone 3GS. En comparant le temps de trame, rendre les objets opaques de l'avant vers l'arrière est beaucoup plus rapide que d'arrière en avant. Je ne comprends pas pourquoi il montre ce résultat. Les performances doivent être très proches lorsque les objets sont rendus dans n'importe quel ordre.mon expérience montre que l'ordre de rendu affecte beaucoup la performance dans l'architecture TBR. Pourquoi?

qui sait? merci

Répondre

1

Je crois que l'optimisation pour ne pas effectuer de traitement de fragment est faite en utilisant le Z-buffer pour déterminer si un pixel est visible ou non (et tôt dans le pipeline si le pixel n'est pas visible). En conséquence, le rendu en arrière-plan sera le pire des cas pour cette optimisation (aucune optimisation possible) et avant-arrière est le meilleur des cas (tous les pixels éventuellement cachés sont déjà masqués).

1

Si cela est vrai, qui contredit Apple's documentation on the topic:

  • Ne perdez pas de temps à trier des objets CPU avant vers l'arrière. OpenGL ES pour L'iPhone et l'iPod touch implémentent un modèle de rendu différé à base de mosaïques, qui rend cette opération inutile. Voir "Rendu différé basé sur les tuiles" pour plus d'informations.
  • objets de tri Do de leur opacité:

    1. Dessiner des objets opaques en premier.
    2. objets de dessin suivant qui nécessitent des tests alpha (ou dans une application OpenGL ES 2.0 , les objets nécessitent l'utilisation de défausse dans le fragment shader .) Notez que ces opérations ont une pénalité de performance, comme décrit dans "Évitez le test Alpha et Discard."
    3. Enfin, dessiner des objets alpha-mélangés.

Outre la documentation here:

Un autre avantage de rendu différé est qu'il permet au GPU de effectuer l'enlèvement de surface cachée avant fragments sont traités. Les pixels qui ne sont pas visibles sont mis au rebut sans textures d'échantillonnage ou en effectuant un traitement de fragment , significativement réduisant les calculs que le GPU doit effectuer pour rendre la scène. Pour tirer le meilleur parti de cette fonctionnalité , vous devriez essayer de tirer comme une grande partie de la scène avec un contenu opaque possible et de minimiser l'utilisation de mélange, les tests alpha et l'instruction de défausse dans les shaders GLSL. Étant donné que le matériel exécute la suppression de surface cachée, il n'est pas nécessaire pour votre application de trier sa géométrie de l'avant vers l'arrière.

+0

Oui, j'ai lu ce document "OpenGLES_ProgrammingGuide", donc le résultat est vraiment étrange. Cela peut également être trouvé dans l'expérience où les pixels sont récupérés à partir de textures. Je n'ai pas vu l'avantage de HSR. –

+0

@ Brad Larson - Il se peut que les puces ne font pas de texturation/ombrage jusqu'à ce qu'ils comprennent quels pixels sont visibles. Cependant - déterminer quels pixels sont en haut de l'ordre z peut toujours être optimisé en utilisant un mécanisme de départ anticipé qui rendra le rendu d'avant en arrière plus rapide que le retour en arrière (si vous utilisez un tampon z hiérarchique que vous pouvez éliminer le besoin de balayer les triangles pleins plutôt que de les pixéliser et de déterminer la visibilité des pixels). – Aaron