Discussion :

[qnop]

Bonjour bonjour.

J'ai remarqué que dans la version d'OpenGL 3.X, les fonctions glVertexPointer et ses dérivées n’existent plus.

Je me demandais si il était donc plus efficace d'utilisé glVertexAttribPointer plutôt que glVertexPointer, normal, texCoord et autre, en passant par un Shader et des variables varying. Personellement, je dirais que non, vue qu'il faut rajouté plusieurs variables, mais d'un autre côté, je pense que si OpenGL3 fonctionne comme ceci, c'est peut être pour une raison(à moins que ce soit identique et pour forcé le cas du TOUT SHADERS).

Mais le Tout Shaders, que l'on passe par un Shader, en utilisant un VBO + glDrawElements avec un IBO dont les données se suivent : 1 2 3 4 5 6 7 8 9 10... ou que l'on utilise un VBO sans IBO, mais sans les Shaders, je ne note aucun gain de performances.

Avez vous une idée?

Merci

[LastSpear]

Bonjours.

glVertexPointer et ces copains (textures, normals & Cie) on été noté déprécier. Ainsi leur utilisation est a proscrire dans les versions 3.x et supérieur. En effet, il a été jugé que l'interprétation de chaque attributs envoyés au vertex shader doit être faite par le développeur du moteur graphique. En effet il est possible que l'attribut 0 ne correspond pas réellement aux Vertex. C'est pour cela que ces fonctions ont été retiré, au profits de glVertexAttribPointer. Etant donné que le rendu graphique est désynchronisé du CPU, l'utilisation de glVertexAttribPointer, bien qu'il possède plus de paramètres, ne ralentira pas ta duré de rendu.

Attention, l'IBO doit être utilisé astucieusement. Par exemple, lorsqu'un même vertex est appelé à plusieurs reprise de manière "très rapproché" genre 0 1 2 2 1 3 ..., là on notera un gain de performance. Mais un IBO comme tu le propose ne représente aucun intérêt, et est même susceptible de ralentir la duré de rendu.
Utiliser un IBO n'implique pas que le rendu ne peut être que plus rapide. L'objectif premier d'un IBO est d'optimiser la taille mémoire des objets, et lorsqu'un seul IBO peut être appliqué à plusieurs VBO. En exemple, on peut faire le rendu d'une heightmap divisée en régions carrés par un seul IBO, mais plusieurs VBO correspondant aux différentes régions.

En espérant avoir répondu ..

[qnop]

Salut.

Oui, les fonctions glVertexPointer ont étaient déprécié puis supprimé il me semble.

Tu m'as bien répondu sur les IBO, donc dans mon cas, je suis obligé de le supprimé ^^.

Sinon que me conseils tu? De supprimé GlVertexPointer et de passé par glVertexAttribPointer en utilisant les glgetAttrib, mais pas en faisant 0 1 2 3 4 ^^? Ou de gardé glVertexPointer? Sachant que je recherche la performance, mais mes tests ne se sont pas révélé très révélateur ^^.

Par contre les Shaders? Même si ils ne font pas grand choses augmentent ils réellement la vitesse de rendu?

Merci !!

[LastSpear]

Le CPU n'est pas synchronisé avec les calculs GPU, donc quand bien même glVertexPointer serai plus rapide que glVertexAttribPointer, de toute façon ton CPU arrivera plus rapidement que ton GPU au swap buffer, donc çà n'influra pas de tout manière sur ta duré de rendu. Etant donné que glVertexPointer est decrecatted, alors tu le remplaces par glVertexAttribPointer.

Note qu'en GLSL, tu peut explicitement spécifier tes numéros d'attribut par layout(location = 0) in Vertex ; par exemple, et comme çà, plus besoin de glGetAttrib, qui te retournera 0. layout(location = 0) peut être disponible qu'à partir d'une certaine version du GLSL, sachant qu'elle est disponible au moins depuis le 3.3 délivré par OpenGL 3.3, donc renseigne toi si elle fonctionne sur ta version d'OpenGL. Mais libre à toi de continué avec glGetAttrib, çà n'aura aucune importance ni influence sur tes performances.

[DonQuiche]

Bonsoir.

Sinon que me conseils tu? De supprimé GlVertexPointer et de passé par glVertexAttribPointer en utilisant les glgetAttrib, mais pas en faisant 0 1 2 3 4 ^^? Ou de gardé glVertexPointer? Sachant que je recherche la performance, mais mes tests ne se sont pas révélé très révélateur ^^.

L'indice que tu spécifies n'a aucun impact sur les performances : 0 n'est pas plus rapide que 3, etc. De toute façon cela ne correspond pas à la façon dont ces données seront réparties sur les registres matériels, le GPU faisant sa propre sauce en fonction de son architecture interne .

Quant à glVertexPointer, en interne son implémentation s'appuie sur glVertexAttribPointer, en substance. Donc les deux sont aussi rapides.

Ce qui importe vraiment :
* La façon dont tes données sont représentées en mémoire : des tableaux interlacés (interleaved arrays - avec des strides multiples de 4 octets) donnent en principe de meilleures performances (meilleure localité spatiale), sauf si tes données sont constamment modifiées et qu'il faut sans cesse réinterlacer ou remettre à jour plus que nécessaire.
* Utiliser des indices quand cela se justifie (i.e. si économie notable de mémoire et de bande passante).
* Minimiser les changements d'états (rendre en une fois tous les objets qui doivent être rendus de la même façon - mêmes shaders, etc). Essentiel.
* Minimiser les allers-retours mémoire (render targets, mise à jour des données géométriques ou de textures, etc).
* Minimiser le jeu de données (taille des textures, des géométries, des buffers, etc)
* Garder des shaders simples et efficaces.
* Comprendre où se situent les goulots d'étranglement dans ton appli (cpu/gpu, texture interpolation, vertex shaders et traitements géométriques, fragments shaders, rasterization, etc) pour agir sur eux et pas au pif.

Et tout cela étant dit, note que les jeux modernes peuvent quand même se permettre de multiplier les render targets et les shaders monstrueusement gros (pour la peau par exemple).

Par contre les Shaders? Même si ils ne font pas grand choses augmentent ils réellement la vitesse de rendu?

Un shader n'augmente pas la vitesse de rendu, il opère le rendu. Sans lui, c'est l'écran noir : aujourd'hui les anciennes commandes opengl 1.x s'appuient en interne sur des shaders. Donc même si tu ne souhaites pas faire davantage que ce que l'on faisait au temps de 1.x, autant utiliser les shaders puisque tu voudras sans doute faire moins, et donc plus rapide.

Pëtit mot pour conclure : un GPU moderne est composé de centaines de coeurs ayant chacun au moins 8 unités d'exécution avec leurs propres pipelines et registres. Pour une vue simplifiée, représente-toi un GPU comme un chef d'orchestre qui dirige des milliers d'unités d'exécution : quand ce chef d'orchestre fait une multiplication de vecteurs, c'est sur plusieurs centaines de vecteurs à la fois. Autant dire qu'en un soixantième de seconde, ce sont quelques milliards de vecteurs qui sont traités. Alors si tu comptes faire du rendu type 1.x, tu as de la marge devant toi.

[qnop]

Salut .

Pour le glvertexAttribArray 0 1 2 3 4, je parlais de récupérer cette information avec un gl get attribute ^^.

Donc, ce que tu me conseilles, toi, c'est d'utiliser plutôt un buffer avec des données entrelacés selon un multiple de 4 octets.

Donc par exemple, 3 coordonnées pour un vertex, 4 pour la couleur, puis 2 pour la texture, 3 coordonnées pour un vertex, 4 pour la couleur, puis 2 pour la texture, et ceux, autant de fois que l'on a de sommets, plutôt que de mettre tout les sommets, puis toutes les couleurs, puis toutes les coordonnées de textures.

Merci à toi en tout cas, réponses très détailler ^^.

[DonQuiche]

Donc, ce que tu me conseilles, toi, c'est d'utiliser plutôt un buffer avec des données entrelacés selon un multiple de 4 octets.

Si ton problème s'y prête, en général c'est préférable. Il ne s'y prête pas quand :
* Une partie des données entrelacées changent à chaque frame et tu devrais alors envoyer toutes les données plutôt que seules celles qui ont changées.
* Toutes les données changent à chaque frame mais tu les reçois non-entrelacées et tu devrais donc entrelacer toi-même à chaque frame, ce qui sera sans doute moins efficace que d'envoyer les données séparées.

Ensuite, gros bémol : ça marche mieux quand chaque attribut a un stride multiple de 4 octets. Autrement dit, plutôt que X,Y,Z,Nx,Ny,Ny on préfère X,Y,Z,-,Nx,Ny,Nz,-. Sauf qu'évidemment cela demande plus de mémoire, ce qui peut ralentir l'application si le GPU n'a pas assez de mémoire pour toutes tes données auquel cas l'entrelacement sera contre-productif et source de ralentissements. Et ça demande aussi plus de bande passante ce qui ne sera pas un problème si les données ne sont envoyées qu'une seule fois ou rarement, sitôt chargées. Enfin, comme la vie serait moins amusante si tout y était simple, d'une architecture à l'autre les comportements ne sont pas les mêmes.

Bref, entrelacer les données constantes est généralement une bonne idée. Mais ce n'est pas une solution miracle et il faut tester. Qui plus est la minimisation des changements d'états et le batching, par exemple, est beaucoup plus importante.