Rapatrier le backbuffer en ram système

Bonjour,

Je me sers de la carte graphique pour dessiner des choses dans un backbuffer.
Plusieurs thread on acces à ce backbuffer, disons thread1 et thread2

J'ai une fenetre qui me sert à l'affichage de ce que me génère thread1.
Un seul et unique present() me permet d'afficher le backbuffer à l'écran.

Le problème c'est que lorsque le thread2 dessine à son tour dans le backbuffer, et que je dois rafraichir mon affichage (par exemple à la suite d'un redimensionnement de fenêtre), et bien je n'ai forcement plus mon image d'origine (mais celle générée par le thread2).

Je suis donc obligé de récupérer le backbuffer dès que thread1 à terminé, puis de l'afficher à ma guise avec le gdi. J'utilise pour cela D3DXSaveSurfaceToFileInMemory().

Ma question : y'a t-il un moyen plus rapide ? une autre fonction qui serait plus adaptée à ce que je veux faire, ou une méthode ?

Une autre question : je ne m'y connais pas tellement en carte graphique, mais j'ai lu que l'agp n'était optimisé que dans un sens (système vers carte). Est-ce que le pci express corrige ca ? dans un avenir proche, le problème que je décris plus haut n'en serait plus un ?

Merci.

Citation:

---

Je me sers de la carte graphique pour dessiner des choses dans un backbuffer.
Plusieurs thread on acces à ce backbuffer, disons thread1 et thread2

---

Ca me paraît dangereux. Es-tu sûr que DirectX supporte ce genre de choses ?

Citation:

---

Je suis donc obligé de récupérer le backbuffer dès que thread1 à terminé, puis de l'afficher à ma guise avec le gdi. J'utilise pour cela D3DXSaveSurfaceToFileInMemory().

---

La fonction IDirect3DDevice9::GetBackBuffer permet de récupérer le backbuffer, aussi.

Citation:

---

Une autre question : je ne m'y connais pas tellement en carte graphique, mais j'ai lu que l'agp n'était optimisé que dans un sens (système vers carte). Est-ce que le pci express corrige ca ? dans un avenir proche, le problème que je décris plus haut n'en serait plus un ?

---

Globalement, les cartes graphiques ne sont faites que pour travailler dans un sens, et PCI Express ou pas, si tu vas à contre-sens, tu casses tout le délire de la carte. Donc ce sera toujours une mauvaise chose (dans un futur proche tout du moins).

Merci pour ta réponse Loulou.

Je me suis mal exprimé pour l'histoire des threads. En fait ils accedent au même backbuffer, mais via une interface.
Un thread bloque l'interface si il veut produire une image.
Il dessine via des fonctions de l'interface.
Puis il débloque l'interface quand c'est fini.

Je vais essayer avec le GetBackBuffer voir si c'est plus rapide...

Je viens d'essayer avec GetBackBuffer() et c'est pire (430 ms contre 300ms avec le D3DXSaveSurfaceToFileInMemory).

Loulou, je te pose quelques questions (vu que tu es le grand maître de la 3D sur le forum).
Si je réécrivais tout en GDI+, crois-tu que ma génération d'image serait beaucoup plus lente ? Je n'utilise que du texturage de quads, textures de textes sur quads (D3DXFont), des quads avec gradient, des lignes, et beaucoup de rotation, rien de trop compliqué.
J'ai peur qu'avec le gdi mon temps de génération (100ms ici) explose d'un facteur 10 (surtout si je met de l'antialiasing un peu partout).

Citation:

---

Je viens d'essayer avec GetBackBuffer() et c'est pire (430 ms contre 300ms avec le D3DXSaveSurfaceToFileInMemory).

---

Faut voir comment tu le manipules ensuite.

Pour répondre à tes autres questions, il faudrait connaître la finalité de la manip. Tu cherches à faire quoi au juste ?

Le but est de créer des graphiques rapidement (axes, courbes, textes, etc.). Tu peux voir un exemple ici :
http://guilmard.free.fr/programmatio...images/sc3.jpg
Sur cette image, tout est fait a base de DrawPrimitiveUp (linelist, trianglelist, etc.). Les textes sont en fait des sprites. Le degradé vert est une texture (on peut mettre une photo si on veut).

Tout fonctionne bien. Je me sers donc de la carte graphique pour me générer une image, mais elle peut a tout moment être détruite par un autre thread. Il faut donc que je la sauvegarde en mémoire (d'ou le D3DXSaveSurfaceToFileInMemory). C'est idem pour tous les threads, obligation d'aller chercher l'image.

En utilisant le gdi je pense pouvoir sauvegarder l'image plus rapidement. Et/ou à la rigueur faire en sorte que mes threads ne dessinent pas sur le même dc (ce je ne peux pas faire avec directx car je suis limité par la mémoire vidéo, impossible de créer un device directx par thread).

Il y a pas mal de chose à faire quand même, en texturage, transparence alpha, tracé de lignes. Le GDI peut t-il solutionner mon problème, j'ai peur que ce soit trop lent ?

Pour infos :

Après quelques essais, j'ai la confirmation que le gdi+ est lent.
J'ai codé le plus facile, c'est à dire tracé de ligne, texture, gradients, et le temps de génération d'une image a été multiplié par 4. Reste toutes les rotations, le texte, et j'en passe...bref je reste en directx avec "rapatriement de backbuffer" :D

Citation:

---

Envoyé par titoine1978

Bonjour,
Une autre question : je ne m'y connais pas tellement en carte graphique, mais j'ai lu que l'agp n'était optimisé que dans un sens (système vers carte). Est-ce que le pci express corrige ca ? dans un avenir proche, le problème que je décris plus haut n'en serait plus un ?

---

Non, le problème fondamental n'est pas uniquement la vitesse du bus (quoi que ça aide d'être en PCI-express vs simple PCI), mais les problèmes de latence et d'interface (ainsi que d'autres comme la protection de l'accès à la mémoire, l'espace adressable, mais bon ça on peut rien y faire puisque c'est géré par le système etc).

Le problème principal que les gens rencontrent quand ils veulent rapatrier le contenu du backbuffer est qu'il force le rendu à finir dès l'appel des fonctions comme LockRect, ou encore GetRenderTargetData.

Donc si tu as enfilé des commandes dans la liste de rendu, ces commandes vont mettre du temps à s'executer, et le prochain GetRenderTargetData va simplement attendre que ces commandes aient fini, avant de rapatrier le contenu du backbuffer (ou de tout autre surface de rendu).
Il n'y a aucun moyen de contrer cela, cela aboutit à une "sérialisation" des deux processeurs (CPU et GPU) et donne l'impression que la commande de rapatriement est longue à executer (tu peux avoir jusqu'à l'équivalent de trois frames en attente d'être affichées à l'écran).

En général entre le temps passé à faire le rapatriement et le temps passé à simplement attendre, ce dernier est le plus important.

Une manière de partiellement résoudre cela est d'envoyer les commandes d'un coup, forcer l'exécution des commandes bufferisées (via un query dx9 ou un lockRect sur une surface non utilisée). Puis faire autre chose. Il est important de ne pas envoyer de nouvelles commandes de rendu pendant ce temps parce qu'elles vont s'ajouter à la liste.
Quand on a épuisé le "autre chose" ou que l'on croit que le rendu est fini, on envoie alors la commande de récupération des données (getRendertargetData).

Normalement celui-ci devrait finir beaucoup plus rapidement. Si il prend toujours longtemps même après avoir forcé une synchronization forcée (comme attendre activement le résultat d'une event query), cela veut dire que c'est le temps de rapatriement qui est long, et donc là pas de solution à part tenter de réduire la quantité de données à rapatrier, ne pas tenter de rapatrier le contenu d'un buffer avec un flag multisampled (ce qui rallonge le temps de rapatriement), ou changer de machine (avec un bus plus rapide comme un PCI-Express 16x).

LeGreg

Merci Legreg pour ta réponse très complète. Je vais étudier en details tes explications, car je ne suis pas encore un pro de DirectX :lol:
Je suis en PCI simple, avec une bonne carte graphique 9600 pro, le temps de rappartiement est d'environ 300 ms pour une image 900x800 en gros.

Comme Loulou24 je déconseille les threads ou alors avec le gdi32 ( pas GDI+)
Pour ce que tu veux faire rien ne prouve que Direct X soit plus rapide que des HDC en mémoire affichés avec StretchBlit du GDI ;)

Salut,

A priori, si deux threads accedaient au même device DirectX, au pire ca plante l'ordi ?
Sinon GDI+ c'est beaucoup trop lent (pour avoir testé), j'ai lu qu'il n'utilisait pas le hardware, par contre gdi32 oui. Le gdi je ne connais pas assez, mais ca me semble très pauvre en fonctions...pour faire un simple gradient de couleur il faut se taper 20/30 lignes de code d'après ce que j'ai vu...alors qu'avec directx c'est plutot simple.

Edit : je viens de comprendre a quoi vous faites allusions pour les threads, c'est le flag de creation D3DCREATE_MULTITHREADED. Pourquoi est-il déconseillé de l'utiliser ?

Salut.

Citation:

---

Envoyé par titoine1978

Edit : je viens de comprendre a quoi vous faites allusions pour les threads, c'est le flag de creation D3DCREATE_MULTITHREADED. Pourquoi est-il déconseillé de l'utiliser ?

---

Lorsque plusieurs threads accèdent à une même ressource, il faut des sections critiques (si l'on veut maîtriser parfaitement le déroulement).

Le programme peut être ralenti parce qu'il n'est pas toujours facile de savoir précisément dans quel ordre et à quelle fréquence seront traités les threads par l'OS.

Il y a de forte chance qu'à un moment donné, le programme soit bloqué parce qu'un thread n'est pas dans un état d'avancement adéquat, ce qui oblige l'OS à faire un changement de contexte alors qu'il aurait pû continuer l'exécution du thread en cours.

Néanmoins, ce n'est pas parce qu'il y a des contraintes à travailler dans un environnement multithreadé qu'il ne faut pas l'utiliser.

Si tu ne peux pas faire autrement, que tu dois garantir une bonne exécution, alors il faut l'utiliser.

Personnellement, je l'utilise lorsque je mélange DirectShow (multithreadé à gogo) et directxgraphics. Dans mon cas c'est tip-top parce que l'aspect 3D n'est pas aussi complexe que pour un jeu vidéo.

Il faut aussi savoir que les threads ça se gère et que l'on peut optimiser leur déroulement pour une exécution rapide et contrôlée (je pense notamment aux priorités des threads).

Merci de ta réponse Moldavi.
J'utilise en effet des sections critiques. Comme ce que je fais n'est pas trop lourd en temps de calcul, l'utilisateur n'a pas le temps de voir de gros ralentissements. Par contre le multithread n'est quand meme pas évident (messages, arrets des threads, etc) surtout quand on n'en n'a jamais fait.

Citation:

---

Envoyé par titoine1978

Par contre le multithread n'est quand meme pas évident (messages, arrets des threads, etc) surtout quand on n'en n'a jamais fait.

---

C'est parce qu'il te manque des notions. Si tu veux maîtriser un peu plus le sujet, je te conseille de faire un tour du côté de:

-> ordonnancement de processus/thread.
-> recherche opérationnelle.

Tu y verras plus clair et tu comprendras de quelle manière il est possible d'optimiser la chose du moins de manière théorique.

Pour la pratique, il n'y a pas de solution miracle, car plusieurs facteurs interviennent (ton programme, tes threads, ton OS, API fournit, etc...).

LeGreg : J'ai testé le GetRenderTargetData qui est beaucoup plus rapide que ce que je faisais...seul inconvenient la fonction ne supporte pas les RenderTarget multisamplée. J'ai donc intégré les deux méthodes ca marche super.
Comme je génére de l'image par image (je sais quand le traitement est terminé), je n'ai pas appliqué ta méthode (query, etc.). Je ne pense pas me tromper en faisant ca.

Par contre je suis tombé sur un article et les problèmes de FRAPS (qui produit des vidéos de jeux), ca en fait des données à aller chercher...8O

Merci encore.