Disons que je veux rendre un carré; sa texture est "square.png".
Est-il plus facile pour l'ordinateur de le rendre si la texture est juste une couleur unie?
Et qu'en est-il si c'est une texture très bruyante avec des couleurs complètement aléatoires ici et là?
Ou que se passe-t-il si cette texture est bruyante dans le sens où chaque pixel en elle est différent les uns des autres, mais seulement par un tout petit peu?
Réponses:
Comme la plupart des choses dans le développement de jeux, et en particulier dans les graphiques de jeux, la réponse est "cela dépend"
La résolution de votre texture peut avoir un impact sur la vitesse de rendu. Plus il contient de pixels, plus il y a de données brutes à télécharger sur le GPU et moins de texture nous pouvons tenir dans le cache à la fois, de sorte que le shader peut frapper plus de pauses en attendant la bonne partie de la texture pour être mis en cache.
L'utilisation du mipmapping peut en réduire l'impact. Avec les mipmaps, nous stockons une chaîne de versions réduites de la texture, qui au premier abord semble être encore plus de mémoire à utiliser. Mais cela nous permet de lire à partir des versions plus petites lorsque la texture est affichée à une petite taille à l'écran (comme un objet distant en perspective), afin que nos échantillons utilisent mieux le cache de texture, plutôt que de sauter partout. Cela réduit également l'aliasing.
Le contenu de vos textures n'a pas d'impact sur l'efficacité du rendu la plupart du temps.
Une couleur n'est qu'un groupe de nombres en ce qui concerne le GPU, donc peu importe ce que sont ces nombres, elle les canalise simplement dans ses calculs de la même manière. Cela ne fait rien d'extraordinaire comme de se rappeler "Oh, j'ai déjà vu un pixel dans ce vert, je vais juste réutiliser la même sortie que j'ai calculée la dernière fois que j'ai vu cette entrée" donc si votre texture est une seule couleur ou scintille au hasard, votre GPU fait le même travail.
Contrairement aux formats comme PNG et JPG, qui compressent plus efficacement dans les zones prévisibles de l'image et consomment plus de bits dans les régions complexes, les formats de texture GPU comme BTC, ETC, PVRTC ou même RGBA brut utilisent un nombre fixe de bits par bloc de pixels. Donc, rendre votre texture plus ou moins détaillée tout en conservant le même format de compression ne changera pas sa taille de données ou n'affectera pas le transfert de données et l'efficacité liée au cache.
Mais, si vous utilisez un type particulier de détails que votre compression précédente ne conserve pas bien, vous pourriez être obligé de modifier votre image entière pour utiliser un format différent, ce qui pourrait à nouveau changer la taille de ses données.
Voici le plus gros astérisque de la situation: vous pouvez utiliser cette entrée de couleur de texture pour prendre des décisions, comme une if()branche. Ici, le détail compte pour la vitesse.
Les unités d'ombrage GPU fonctionnent sur des blocs de pixels par lots, exécutant les mêmes instructions en parallèle sur plusieurs flux de données. Ainsi, lorsque certains pixels du bloc prennent une branche de ifet d'autres pixels prennent l'autre, le lot entier doit passer par les deux branches (masquant les résultats qui ne s'appliquent pas à un ensemble de pixels ou à l'autre)
Si votre entrée change de manière fluide / prévisible, vous aurez probablement de nombreux blocs qui n'ont besoin que d'une seule branche, et ces cas à deux branches seront limités à des bandes étroites autour de la frontière de transition. Mais si votre entrée est aléatoire, nous nous attendons à ce que la plupart des blocs prennent les deux branches et ralentissent le rendu.
Cela peut également se produire si vous utilisez une texture pour contrôler les recherches dans une seconde texture, comme une distorsion ou une carte d'index. Si la première texture saute au hasard, nous échantillonnerons à partir de points dispersés et aléatoires de la deuxième texture, ce qui rendra l'utilisation de notre cache de texture moins cohérente et attendra plus longtemps pour obtenir les données dont nous avons besoin, en moyenne.
Donc, dans l'ensemble: non, le contenu de la texture n'a pas beaucoup d'impact sur la vitesse de rendu, sauf dans les cas où cela se produit. ;)
ne pixel, vous devriez parcourir chaque pixel avant. Avec une largeur de pixel constante, c'est juste start_of_buffer + width * n, ce qui est beaucoup plus rapide, surtout pour les grands n.
Avec l' excellente réponse de DMGregory ci-dessus, il y a peut-être un cas où la complexité d'une "texture" peut affecter les performances de rendu et c'est là que les résultats d'un rendu précédent sont utilisés comme source dans un suivant, par exemple des shadow maps / réflexions / cartes de l'environnement.
Certains matériels modernes peuvent appliquer une compression sans perte à ces tampons: par exemple, PowerVR a PVRIC , AMD, Delta Color Compression et ARM a quelque chose de similaire. Le but de ces techniques de compression est de réduire la bande passante globale qui, à son tour, peut améliorer les performances de rendu.
Plus les données sont simples, que ce soit la profondeur ou la couleur (entier ou virgule flottante), mieux ces schémas fonctionneront. Bien sûr, je ne suggérerais pas de simplifier délibérément votre sortie de rendu juste pour que ceux-ci fonctionnent mieux, mais éviter d'utiliser des données bruyantes pourrait aider dans certaines circonstances.
De plus, faire un échantillonnage clairsemé des tampons de trame / profondeur qui utilisent ces schémas, dans une vaine tentative de réduire la bande passante, ne sera pas utile car ils sont très probablement basés sur des blocs.
De plus, vous pouvez trouver ces deux questions et réponses SE Computer Graphics d'intérêt: