Le dessin d'index est-il plus rapide que le dessin sans index


8

J'ai besoin de dessiner beaucoup de polygones composés de 6 sommets (deux triangles).

Sans coordonnées de texture, normales, etc., les deux approches donnent 72 octets. À l'avenir, j'aurais certainement besoin de coordonnées de texture et de normales, ce qui ferait que le dessin d'index consomme moins de mémoire. Pas beaucoup cependant.

Ma question est donc la suivante: pour les VAO avec peu de chevauchements de sommets, quelle approche est la plus rapide? Je me fiche de la mémoire supplémentaire consommée par le dessin non indexé, seulement de la vitesse.

Modifier: pour que ce soit clair.

Approche non indicielle:

float[18] vertices = {
//Triangle 1
1,1,0,
1,0,0,
0,0,0,

//Triangle 2
1,0,0,
0,1,0,
0,0,0,
};

Approche indicielle:

float[12] vertices = {
1,1,0,
1,0,0,
0,0,0,
0,1,0,
};

int[6] indices = {
//Triangle 1
0,1,2,

//Triangle 2
0,3,2
};

1
... pourquoi ne pas simplement mesurer les deux approches pour votre application spécifique sur votre matériel cible et le découvrir de manière concluante?
Sean Middleditch

Réponses:


4

J'essaie de répondre à la question. Je pense que vous devriez opter pour des indices, pour quelques raisons:

1) Dans tous les cas, l'indexation est une opération gratuite côté GPU, vous n'y prenez pas de pénalités. (ajouté) Bien sûr, les index sont des opérations d'accès aléatoire et peuvent nuire aux performances du cache mémoire du GPU.

2) L'indexation peut permettre au cache de sommet du GPU d'effectuer ces quelques optimisations pour les sommets qui se chevauchent.

3) L'encombrement de la mémoire plus petit côté GPU signifie de meilleures performances, car la bande passante mémoire est l'un des goulots d'étranglement, et parce que les opérations d'extraction (par exemple 10_10_10_2 -> 4 x float) sont sans coût.

La différence de vitesse n'est probablement pas perceptible s'il n'y a pas beaucoup de sommets qui se chevauchent où vous pouvez obtenir une amélioration de la vitesse. Mais je n'ai vraiment pas de faits concrets pour soutenir mon opinion (pour aller avec les indices).


Regardez aussi ceci:

/programming/17503787/buffers-indexed-or-direct-interlaced-or-separate


1
re 1) qu'en est-il de l'optimisation de l'ordre des index pour les performances du cache? il existe même des algorithmes pour cela. comme la réorganisation de k-cache. re 3) qu'en est-il de la surcharge du tampon d'index lui-même? Parfois, le tri-stripping entraîne moins de données à télécharger ... bien que ce ne soit pas le cas commun.
jheriko

1

Si les positions sont toujours les mêmes, vous pouvez même vous passer de tampons en stockant le tableau dans le shader et en utilisant gl_VertexIDpour sélectionner le sommet dans le vertex shader.

#version 330 core

const vec3 data[4] = vec3[]
(
//Triangle 1
vec3(1,1,0),
vec3(1,0,0),
vec3(0,0,0),

//Triangle 2
vec3(1,0,0),
vec3(0,1,0),
vec3(0,0,0)
);

void main()
{
  gl_Position = vec4( data[ gl_VertexID ], 1.0);
}

Et lorsque rendu avec instanciation, vous pouvez définir un point, une rotation et une échelle par occurrence.
Lasse

@ratchet freak Les positions ne seront pas toujours les mêmes, car c'est pour le terrain (et je ne peux pas utiliser triangle_strips car cela serait très difficile à implémenter correctement, car il est basé sur le voxel). J'ai simplement besoin de savoir si je dois utiliser un dessin indexé ou non indexé. Ou même les anciennes listes d'affichage, si ce serait plus rapide.
KaareZ

@KaareZ Vous pouvez toujours utiliser des uniformes pour changer la position. Ou utilisez l'instanciation pour transmettre des données par face.
ratchet freak

0

comme pour toutes les performances, ne devinez pas, profilez-le pour le savoir.

cela variera en fonction du matériel et de très nombreux facteurs compliqués. la mesurer par profilage considérera automatiquement toutes ces choses pour vous sans que vous ayez besoin de savoir quoi que ce soit à leur sujet.


-1

Mon hypothèse est que l'utilisation de l'indexation pour les sommets serait plus lente.

J'ai mal compris la question d'origine, mais voici la réponse pour l'indexation des couleurs. Je suppose que les mêmes règles s'appliqueraient à l'indexation des sommets (sans perte de précision), mais ce n'est qu'une supposition.

Mais...

  • En règle générale, je suggère l'indexation.
  • L'indexation est plus lente.
  • La non indexation est plus rapide.
  • L'indexation est plus efficace en mémoire.
  • Ne pas indexer est moins efficace en mémoire.
  • L'indexation perd la précision des couleurs.
  • La non indexation ne perd pas la précision des couleurs.

72 octets est si petit qu'il serait probablement plus efficace en mémoire de ne pas l'indexer.

Quelques règles d'or: l'indexation est plus efficace en mémoire. L'indexation perd la précision des couleurs. La non indexation est plus rapide.

Cela peut vous donner envie de ne jamais utiliser l'indexation, mais le compromis mémoire est plutôt important pour des images de taille décente. La précision des couleurs est imperceptible.

L'indexation fonctionne de la manière suivante: lorsqu'elle dessine un pixel, elle reçoit un index et doit rechercher la couleur dans un tableau d'une taille prédéterminée. (Disons 256 octets, vous êtes donc limité à 256 couleurs). Ensuite, il dessine ce pixel. Aucune indexation ne stocke directement les données de pixels, donc aucune limite de couleur à 256. Mais dans une image 100x100, votre image de 400 octets est maintenant de 10000 octets.

Avertissement, je retire ces chiffres de mon chapeau.


Je n'ai pas posé de questions sur la compression des couleurs.
KaareZ

Réponse super courte: l'indexation est toujours plus lente. J'ai enterré ma réponse là-dedans, mais je l'ai ajoutée à la première ligne maintenant, je suis entré dans la compression des couleurs, car c'est ce qu'est l'indexation.
Evorlor

Je parle de l'indexation des sommets, pas de la compression de texture. Comme par exemple, vous avez v0, v1, v2 et v, 3. Pour dessiner deux triangles, vous spécifiez les indices suivants: 0, 2, 3, 0, 2, 4
KaareZ

Oh mon erreur. Dans ce cas, je ne sais pas, mais je suppose que les mêmes règles de base s'appliqueraient (moins la perte de résolution)
Evorlor
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.