Une texture détaillée prend-elle plus de temps à être rendue?


22

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:


39

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"

Taille de texture

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.

Les détails de texture

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.

Branchement et indirection de shader

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


Les textures basse résolution (pensez à Minecraft) seraient plus susceptibles de charger des texels pour les pixels adjacents dans le cache lorsqu'un texel particulier est chargé dans le cache, non?
user253751

6
@immibis Minecraft a de minuscules textures. La valeur par défaut est juste 16x16, ce qui s'intègre si facilement dans le cache de texture de chaque cœur que ce n'est même pas drôle: D Et oui, la plupart des échantillons de texture seront au même texel, à moins que vous ne soyez très loin du bloc. Cela est particulièrement vrai si vous prenez en compte la subdivision de l'écran - si vous êtes raisonnablement proche, le lot entier pour un noyau donné pourrait correspondre au même texel: un GPU plus simple DA fonctionnerait probablement mieux pour une telle texturation basse définition - je soupçonne beaucoup d'efforts sont gaspillés sur des optimisations qui n'aident en rien Minecraft.
Luaan

1
Note latérale: le "utilise le même nombre d'octets par pixel" est en fait la clé de certains des hacks de vitesse que le code graphique utilise. Si vous deviez essayer d'utiliser PNG en interne, ou même quelque chose comme UTF-8 avec une taille de pixel variable, pour arriver au 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.
Fund Monica's Lawsuit

@Luaan Je veux dire que même lorsque vous êtes loin du bloc, quand il récupère un texel (celui qui est le premier), il devrait également en extraire quelques uns adjacents dans le cache.
user253751

4
C'est le cas dont je parle ci-dessus avec le mipmapping. Pour éviter que nos échantillons ne sautent tout autour de la texture, laissant de grands écarts entre avec peu ou pas de réutilisation du cache, nous stockons une version 512x512 et une version 256x256 et .... tout le long de 1x1 parfois. Ainsi, lorsque vous dessinez la texture 1024x1024 en 16x16, la plupart des jeux liront réellement à partir du mip 16x16, et il fonctionne de manière similaire au cas Minecraft 16x16 en termes d'efficacité du cache. Cela réduit également les artefacts de crénelage scintillants du sous-échantillonnage.
DMGregory

1

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:

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.