Discussion :

[tnarol]

Salut,

Je m'apprête à passer aux VertexBuffers (IDirect3DVertexBuffer9) au lieu de buffers simplement alloués dynamiquement - dans mon précédent thread Laurent disait que c'est mieux :
http://www.developpez.net/forums/sho...d.php?t=218121

Je me demande si ça vaut également la peine d'utiliser ces vertexbuffers lorsqu'on en modifie et en lit régulièrement le contenu - ce qui dépend évidemment de la vitesse de l'opération Lock/Unlock.

D'où ma question aux "expérimentés" ? A vue de nez quel est le plus rentable pour le rendu d'une frame entre :

1- VertexBuffer (mémoire graphique ??) + 2 ou 3 lock + 2 ou 3 unlock + 1 SetStreamSource + DrawPrimitive

et

2- Buffer en mémoire système + pas de lock/unlock + DrawPrimitiveUP

Merci

[blastou]

L'avantage du vertex buffer c'est d'être directement dans la mémoire du GPU, si tu l'as initialisé normalement, donc lors du draw il n'y auras aucune interaction avec le cpu qui pourras faire autre chose. Lorsque tu utilises un buffer de mémoire systeme et le drawprimitiveUP tu es obligé de passer des informations par le bus qui relie ton cpu avec ton gpu.

Ensuite le Lock/Unlock, ne fait rien d'autre que passer le buffer du GPU vers le CPU pour que tu puisses le modifier et lors de l'Unlock il retourne le buffer changé vers le GPU. Cette opération prends donc un certain temps et est souvent utilisé une unique fois lors de l'initialisation de l'application.

J'espère qu'après cette explication tu comprends qu'il faut éviter à tout prix de faire 2/3 Lock/Unlock sur une boucle de rendu. D'ailleurs, logiquement 1 seul devrait suffire dans tous les cas.

ps : Il y a sans doute d'autre subtilités et optimisations obscures dans un vertex buffer de directX. Par exemple l'utilisation de certains flags du lock ou bien celle à la création du VertexBuffer. Donc, je te conseille de toujours les préférer à un buffer système.

[moldavi]

Salut.

La suite logique, ce sont les vertex shaders.

[tnarol]

Salut.

La suite logique, ce sont les vertex shaders.

Tu peux être plus explicite ?

[tnarol]

J'espère qu'après cette explication tu comprends qu'il faut éviter à tout prix de faire 2/3 Lock/Unlock sur une boucle de rendu. D'ailleurs, logiquement 1 seul devrait suffire dans tous les cas.

.... Donc, je te conseille de toujours les préférer à un buffer système.

Je ne fais pas le lock/unlock dans ma boucle de rendu pour le plaisir, il y a une réelle utilité, en fait je me sers des vertex buffers pour stocker directement un flux de points (nécessairement changeant) au lieu de le stocker en mémoire... Je me dis que c'est plutôt une chose positive d'avoir directement les données à afficher sous la forme qui est a priori la plus rapide à afficher.

J'ai réalisé un petit benchmark pour comparer le temps de rendu depuis un vertex buffer de 10000 points sur lequel je fais 2 lock/unlock + 1000 écritures et depuis un buffer mémoire de 10000 points + 1000 écritures. Dans le premier cas j'étais aux alentours de 1ms et dans le deuxième autour de 2ms. Ca a l'air plutôt efficace.

Par contre j'ai remarqué que si je prends une grande taille pour le vertex buffer il est alloué en mémoire système et les performances sont dégradées.

[blastou]

Par les pixel shader il veut dire par la que tu peux modifier tes vertex au niveau du GPU se qui libère totalement ton CPU. Les vertex shader permettent de modifier les differentes données a l'intérieur de ta structure de vertex avant le rendu. La grande différence c'est que tu ne peux pas changer ton buffer lui même, le pixel shader ne garde pas les changement.

Sinon, je suis plutot surpris qu'avec 2 lock/unlock tu arrives a avoir de meilleures performances. Tu n'as pas expliqué la raison pour laquelle tu as besoin de 2 Lock/Unlock. Par exemple, dans un système de particules tes vertex changent en permanence, cependant un seul Lock/Unlock est nécessaire.

Enfin pour la grande taille en mémoire, ça vient peut être des deux Lock/Unlock, (il libère peut être pas de suite les buffer qu'il utilise). Sinon, vérifies que tu n'initialises pas ton VertexBuffer avec le flag SysMem.

[tnarol]

Tu n'as pas expliqué la raison pour laquelle tu as besoin de 2 Lock/Unlock. Par exemple, dans un système de particules tes vertex changent en permanence, cependant un seul Lock/Unlock est nécessaire.

Je fais une sorte d'oscilloscope numérique rapide. J'ai besoin d'un lock/unlock pour gérer l'arrivée d'un flux de points (ajouter ces points dans le buffer et éventuellement en retirer d'autres) - Cette arrivée de flux de points n'est pas nécessairement synchrone avec le rendu, c'est pourquoi j'ai ensuite besoin d'un lock/unlock lors du rendu pour lire le contenu du buffer afin de déterminer la liste des vertices à représenter qui dépend des échelles et du moment où le rendu est demandé. De plus je gère deux buffers (en flip/flop je crois), celà permet de garder les points dans leur ordre d'arrivée, mais occasionne des transitions de buffer qui demandent parfois des lock/unlock de plus.

D'où en moyenne 2 à 3 lock/unlock.

[blastou]

Je ne pense pas avoir bien compris.
J'ai compris que tu faisais un Lock/Unlock pour ré-initialiser tous tes vertices selon un flux, en gros. Ensuite un second Lock/Unlock, pour synchroniser. Enfin d'autres Lock/Unlock pour remettre dans l'ordre. Pour faire un oscilloscope ça me paraît beaucoup.

Si j'ai bien compris tu remplis une des deux files pendant que l'autre contients les informations de l'oscilo au temps t-1. Tu as donc toujours une information valide et presque synchronisée, je ne vois pas pourquoi tu ne remplis pas l'intégralité de ton buffer a partir de la file à jour tout juste avant le rendu ?

[tnarol]

Je ne pense pas avoir bien compris.
Si j'ai bien compris tu remplis une des deux files pendant que l'autre contients les informations de l'oscilo au temps t-1. Tu as donc toujours une information valide et presque synchronisée, je ne vois pas pourquoi tu ne remplis pas l'intégralité de ton buffer a partir de la file à jour tout juste avant le rendu ?

Le but est de traiter l'ajout d'échantillons de sorte qu'il y ait un minimum de recopies et de conversions. Mettons que les échantillons arrivent 1000 par 1000 et que j'ai besoin d'en afficher au maximum 10000. J'alloue 2 vertexbuffers de 10000 points, et je remplis le premier 1000 par 1000, quand il est plein je passe au deuxième, puis quand il est plein de nouveau au premier, etc... L'intérêt est que les vertices sont toujours rangés dans leur ordre d'arrivée, il est donc possible de tracer *directement* des lignes d'après celà -> pas de recopie - il y a juste à gérer le cas où les données sont à cheval sur les deux buffers ce qui amène à tracer en deux fois.

[blastou]

D'accord, c'est une solution et si elle marche autant la garder .