Mutex et OpenGL

Bonjour,

Je développe actuellement une mini-application OpenGL multithreadée avec boost. J'ai divisé ma zone de rendu en plusieurs zones. Chaque thread s'occupe de rendre la zone qu'il lui est dédiée avec des points 2D et effectue aussi le rendu dans une image.

Pour l'accès à mes données, j'utilise naturellement un mutex de boost (boost::mutex::scoped_lock). Le mutex protège donc à la fois le rendu OpenGL et le rendu dans l'image.

Le problème est qu'OpenGL plante avec un core dump assez violent. Si je retire les instructions OpenGL, tout fonctionne normalement.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

// Début de la fonction static boost::mutex mutex;   ...   // Mutex (lock) boost::mutex::scoped_lock lock(mutex);   // Output to screen glBegin(GL_POINTS); { glColor3fv(Color); glVertex2d(a, b); } glEnd();   // Output to image buffer Image->SetValue(a, b, Color);   // Mutex (unlock) lock.unlock();

---

Comment puis-je faire pour avoir le rendu OpenGL ? Merci d'avance :)


Nico.

Un contexte OpenGL ne peut être bindé que sur un thread à la fois. Et lorsque tu le bind sur un thread, il faut que tu t'assures qu'il soit tout d'abord "unbindé" du thread sur lequel il était précédemment.

Ok mais comment binder et unbinder un contexte sur un thread ?

wglMakeCurrent ou glxMakeCurrent. Si tu utilises une bibliothèque de fenêtage il faut voir.

J'utilise SDL comme bibliothèque de fenêtrage.

Alors je ne pense pas que ce soit possible.

Arf merci au moins c'est clair :P


Nico.

J'ai dit "je ne pense pas" ;)

Attends que quelqu'un de plus expérimenté que moi avec SDL vienne donner son avis, avant de marquer le sujet comme résolu.

Je rebondis sur le sujet pour poser une question :

y a t'il (aurait il) un gain de performance a faire du OpenGL (respectivement directx) en multithreade ??

Faire du xxx en multithread ça n'a que très peu de sens. Il faut que les gens cessent de croire que faire mumuse avec les threads va magiquement booster leur application ;)

Les threads ça s'utilise avec parcimonie et potentiellement beaucoup de code de synchronisation derrière, à des endroits que l'on a clairement identifié comme étant susceptibles d'en tirer partie.

Donc pour répondre à la question : oui, certaines applications OpenGL pourront tirer partie des threads, et non, les utiliser "au pif" ne te fera rien gagner bien au contraire ;)

bonjour les frame buffer object ça permet pas ça ?
(le bind et le unbind)

Citation:

---

Envoyé par Laurent Gomila

Faire du xxx en multithread ça n'a que très peu de sens. Il faut que les gens cessent de croire que faire mumuse avec les threads va magiquement booster leur application ;)

Les threads ça s'utilise avec parcimonie et potentiellement beaucoup de code de synchronisation derrière, à des endroits que l'on a clairement identifié comme étant susceptibles d'en tirer partie.

Donc pour répondre à la question : oui, certaines applications OpenGL pourront tirer partie des threads, et non, les utiliser "au pif" ne te fera rien gagner bien au contraire ;)

---

En fait, ma question est de savoir, si deux thread utilisant QUE openGL (ne faisant rien d'autre dans l application que des appels OpenGL) peuvent potentiellement (pas de temps en temps par fruits du hazards) augmenter des perfs.

Est ce que travailler sur deux contextes OpenGL change la donne ? (un rendu fenetre en meme temps que un rendu Off-screen par exemple)


l interet n est pas pour moi de savoir si 1 thread "OpengL" + 1 thread "operations diverses NON openGL" plus rapide que 1 thread "OpenGL + non OpenGL".



Perso, j'ai l'impression que le synchro mise en place pour faire cohabiter deux threads OpenGL (synchro dans l application ou au niveau du driver) devrait interdire tout gain de performances. Cependant comme ce genre de question est redondante sur le forum, je finis par me demander si je ne suis pas dans le faux.

Citation:

---

bonjour les frame buffer object ça permet pas ça ?
(le bind et le unbind)

---

Non, vraiment rien à voir. On parle du contexte là.

Citation:

---

En fait, ma question est de savoir, si deux thread utilisant QUE openGL (ne faisant rien d'autre dans l application que des appels OpenGL) peuvent potentiellement (pas de temps en temps par fruits du hazards) augmenter des perfs.

---

Dans ce cas c'est encore plus simple : sachant que deux commandes OpenGL ne pourront jamais être exécutées "en même temps", ça n'a aucune chance d'augmenter les performances. Cela ne fera que les réduire étant donné le coût des changements de thread, de synchro potentielle, et de bind / unbind de contexte.

C'est bien ce que je me disais , mais a force d entendre parler multithread , je finissais par me poser la question ...

Citation:

---

Envoyé par smashy

En fait, ma question est de savoir, si deux thread utilisant QUE openGL (ne faisant rien d'autre dans l application que des appels OpenGL) peuvent potentiellement (pas de temps en temps par fruits du hazards) augmenter des perfs.

---

le truc, c'est que c'est déjà fait par le driver ce boulot, et que tu est nettement moins bien placé que lui pour faire ça. Donc dans le meilleurs des cas, tu ne changera rien en perf, et dans le cas réel, tu vas perdre en perf ;)

Finalement, je me rends compte que mon idée était plutot stupide. J'espère au moins que ce post répondra à certaines questions que d'autres personnes se posent à ce sujet.


Nico.