double optimisation VBO

[Lintel-oo]

Bonjour à tous
Je souhaiterais obtenir quelques précisions sur la meilleure manière de procéder lorsqu'on crée un vbo.

J'ai une classe qui permet de créer et modifier un vbo à partir de plusieurs std::vector<> correspondants au tableaux de vertex, couleurs, coordonnées de texture et index. Cependant, les méthodes de cette classe sont souvent amenées à être appelées et les vector à être modifiés, ce qui je crois n'est pas terrible pour les performances de l'application.
Je voulais savoir si il serait plus avantageux de créer un vector de tableaux automatiques de taille N afin d'allouer la mémoire par bloc successifs et non par ajouts systématiques sur un seul vector, ceci afin d'éviter l'appel trop fréquent de push_back(). Si une telle solution est plus avantageuse, quelle valeur approximative vaut N ? Doit-elle dépendre de la situation ?

D'autre part je me demandais comment il était possible d'utiliser un vector de structures (vertex, couleurs ...) afin de remplir directement le vbo sans passer par une conversion de la structure en X variables de type Y,
ce qui serait plus avantageux que de créer un vector de types de "bases" (double, int...) que l'on remplirait en convertissant un tableau de structures (vertex, couleurs...).

J'espère avoir été assez concis dans l'exposé de mon problème, si vous avez des questions n'hésitez pas

[gbdivers]

Envoyé par Lintel-oo

Cependant, les méthodes de cette classe sont souvent amenées à être appelées et les vector à être modifiés, ce qui je crois n'est pas terrible pour les performances de l'application.

Si tu peux éviter, oui c'est mieux

Envoyé par Lintel-oo

Je voulais savoir si il serait plus avantageux de créer un vector de tableaux automatiques de taille N afin d'allouer la mémoire par bloc successifs et non par ajouts systématiques sur un seul vector, ceci afin d'éviter l'appel trop fréquent de push_back().

Oui c'est mieux, ça demandera beaucoup de moins réallocation et copie.

Envoyé par Lintel-oo

Si une telle solution est plus avantageuse, quelle valeur approximative vaut N ? Doit-elle dépendre de la situation ?

A mon avis, il faut créer des blocs de taile suffisante (trop petit, veut dire plus de réallocation) mais sans dépasser la taille du cache L1.
Par exemple, tu peux créer des blocs de 128ko, 256ko, 512ko (voir plus si tu n'est pas sur de l'embarqué et que la RAM n'est pas un problème)

Envoyé par Lintel-oo

D'autre part je me demandais comment il était possible d'utiliser un vector de structures (vertex, couleurs ...) afin de remplir directement le vbo sans passer par une conversion de la structure en X variables de type Y, ce qui serait plus avantageux que de créer un vector de types de "bases" (double, int...) que l'on remplirait en convertissant un tableau de structures (vertex, couleurs...).

Problème classique des AoS et SoA (array of structure et Structure of Array). Tu trouveras sans difficultés pas mal de littérature là dessus. Le problème est que suivant l'utilisation, certaine structure seront plus performance (par exemple pour lire un fichier ou l'afficage). Perso, j'utilise souvent des AoS (pour avoir des données contigûes et donc optimisées pour les caches gpu) mais c'est pas la meilleur méthode dans tous les cas. Il faut optimiser au cas par cas (en fonction des traitements de données que tu fais)

[gbdivers]

Petite remarque sur la taille des blocs. Je viens de relire des notes que j'avais pris sur la doc NVIDIA et il y a avait un calcul intéresant sur les problèmes de latence de la mémoire.

Pour un carte en PCIe 16x à débit de 8 Go/s, avec une latence mémoire de 10 µs, on peut calculer le ration temps_latence/temps_total en fonction de la taille des blocks :

Code :

1
2
3
4
5
6
7
Taille      Temps               Ratio
1ko         1/8 = 0.125 µs      10/(10+0.125) ~ 99%
8ko         8/8 = 1µs           10/(10+1) ~ 91%
32ko        32/8 = 4µs          10/(10+4) ~ 71%
128ko       128/8 = 16µs        10/(10+16) ~ 38%
256ko       256/8 = 32µs        10/(10+32) ~ 24%
512ko       512/8 = 64µs        10/(10+64) ~ 13%

Le calcul doit être adapté en fonction des perfs de la machine.

En conclusion, si tes blocs sont trop petits, tu passes plus de temps à attendre la mémoire qu'a transférer.

[DonQuiche]

Envoyé par gbdivers

A mon avis, il faut créer des blocs de taile suffisante (trop petit, veut dire plus de réallocation) mais sans dépasser la taille du cache L1.
Par exemple, tu peux créer des blocs de 128ko, 256ko, 512ko (voir plus si tu n'est pas sur de l'embarqué et que la RAM n'est pas un problème)

Je ne pense pas que la taille du cache soit importante ici, à moins d'avoir besoin de faire visiter par le CPU les sommets dans un ordre non-séquentiel (calcul géométrique, etc) ou d'avoir une scène tellement petite que les mêmes sommets resteront dans le cache d'une frame à l'autre.

S'il s'agit simplement de burster tout ça vers le GPU, NVidia recommande 1 à 4 Mo.

Envoyé par gbdivers

Pour un carte en PCIe 16x à débit de 8 Go/s, avec une latence mémoire de 10 µs

Tu es sûr qu'ill faut de l'ordre de 10 microsecondes pour un transfert de la RAM vers la carte graphique ? Cela me semble énorme.
A la rigueur, pour le coût de l'appel au driver en kernel-space, ok, c'est encore de l'ordre de quelques microsecondes je crois.

[gbdivers]

Envoyé par DonQuiche

Je ne pense pas que la taille du cache soit importante ici, à moins d'avoir besoin de faire visiter par le CPU les sommets dans un ordre non-séquentiel (calcul géométrique, etc) ou d'avoir une scène tellement petite que les mêmes sommets resteront dans le cache d'une frame à l'autre.

S'il s'agit simplement de burster tout ça vers le GPU, NVidia recommande 1 à 4 Mo.

Oui je sais plus ce que je raconte. Les valeurs que j'ai donné en plus dépasse le L1. Donc a oublier

Envoyé par DonQuiche

Tu es sûr qu'ill faut de l'ordre de 10 microsecondes pour un transfert de la RAM vers la carte graphique ? Cela me semble énorme.
A la rigueur, pour le coût de l'appel au driver en kernel-space, ok, c'est encore de l'ordre de quelques microsecondes je crois.

Je ne sais plus à quoi correspond ces 10 µs. J'avais du lire ça dans une publication de NVIDIA. Il faudrait que je retrouve

[gbdivers]

La source est Wang 2011 - Fondamental optimization in CUDA
En faisant des recherches, je suis également tombé sur ce papier qui donne la même information (en 2008). Egalement celui-là. Je les lirais en détail à l'occasion

[Lintel-oo]

Merci à tous
Je vais regarder cela attentivement !