Discussion :

[Kurisu]

Bonjour, je cherche des id�es, voire tutoriels, pour cr�er un petit programme de test qui permet d'avoir un rendu OpenGL dans un thread s�par� du reste de la logique du programme (AI ou physique ou encore musique). Je pensais utiliser boost::thread parce que quasiment standard et relativement facile � utiliser (je pourrais aussi r�aliser cela avec des pthreads, mais bon...).
Je suppose bien qu'il y a de la synchronisation � faire et d'autres probl�mes propres au thread, d'o� cette question.

Je voudrais utiliser GLUT (FreeGLUT) au possible pour limiter la surcharge de biblioth�ques de fen�trage.

Merci d'avance pour toutes vos contributions.

[Eusebe]

Bonjour,

Tu as regard� les tutos de Miles ?
http://miles.developpez.com/tutoriels/cpp/boost/thread/

[loufoque]

GLUT, tu veux dire ce truc qui est incapable de faire du plein �cran sous X ?

[Kurisu]

glutGameMode() pour le plein �cran, mais le d�bat n'est pas l�.

Eusebe>merci pour le lien, fort instructif.

Pour continuer le fil, quel serait la meilleure strat�gie pour le multithreading, justement?

(PS: Je sens que je vais devoir retourner sur la th�orie des syst�mes concurrents...)

[Ti-R]

Je ne suis pas sur que d'afficher dans un thread s�par� soit la meilleur solution, m�me si il n'y a logiquement aucune contre indication , mais la boucle principale doit servir � quelque chose et pourquoi s�parer l'affichage qui sert de r�f�rence dans le logiciel ?

Personnellement je fais le contraire, mon thread principal permet de g�rer l'affichage, tous les autres threads sont pour g�rer le reste.

Sons, r�seau, animation�

[Kurisu]

A en conclure que tu initialises les threads pour les sons, anims etc avant d'entrer la boucle principale et que tu te sers du callback "onIdle" ou "onDisplay" (pour rester dans la terminologie de GLUT) pour synchroniser le tout.
Je suppose que j'ai besoin d'un Mutex pour acc�der et affichers mes donn�es 3D sans provoquer un probl�me de mise-�-jour. Vois-je juste?

[Ti-R]

Je ne synchronise rien.

Le son se lit tout seul et n'a besoin de rien.
Les �v�nements r�seau arrivent et son trait� ind�pendamment de l'affichage.
Les animations renseignent les textures � utiliser et seront rendu au moment voulu par le moteur de rendu.
etc...

Tout est ind�pendant m�me si c'est li�, mais chaque unit� fait son travail ind�pendamment et peut, si besoin est, envoyer un message vers un autre pour lui dire, j'ai fini ou je change de donn�e, mais chaque thread � sa propre unit� de temps et ne partage pas les donn�es des autres. Donc pas besoin de savoir qui peut acc�der � quoi et � quel moment.

[Kurisu]

Cela me semble ing�nieux, mais j'ai du mal � comprendre tu peux faire das ce cas, pour jouer un son sur un �venement arrivant dans un autre thread. (Ok, via un message). Idem, pour les animations et la physique, si elles sont calcul�s dans un autre thread que celui qui fait le rendu, il faut bien que j'interdise l'acc�s aux variables d�fnissant l'emplacement de tel ou tel �l�ment sans que celui-ci ne puisse �tre �crit...

Enfin bon, je suis encore un bleu en ce qui est programmation avec des threads.

[Ti-R]

En fait j'utilise des threads et des timers personnels qui s'utilisent un peu comme des threads, mais qui sont appel�s directement dans le programme principal.

Donc pour les animations cela passe plus par mes timers personnels, la physique peut �tre incluse dedans aussi, cela permet de tout synchroniser naturellement, et de ne pas gaspiller la puissance PC.

D�sol� de mettre mal exprim�.
Le principe reste le m�me, sauf que la synchronisation est implicite.

[Laurent Gomila]

Tu devrais oublier les threads pour le moment, � ton niveau �a n'apportera que des ennuis.

Il ne faut commencer � penser aux threads (et pas forc�ment de cette mani�re) que lorsque ton application atteint une certaine complexit�, et lorsque les probl�mes que cela solutionnerait sont clairement identifi�s.

[Kurisu]

� mon niveau... BAC+5 ? ahem.
Non, en fait, mon cours sur les syt�mes concurrents �tait ax� Java, et pas vraiment dans l'optique de faire un syst�me bas� sur OpenGL non plus.

En fait, je me demandais � quel point il serait complexe ou facile de mettre du multithreading dans une appli OpenGL. Et quels seraient les complexit�s engendr�es... Le tout dans l'optique de mettre mon code de base � jour. Voil� tout.

[Ti-R]

Les threads c'est bien si on en a besoin, on peut s'en passer la pluparts du temps et si on peut s'en passer, c'est ce qu'il y a de mieux. Sauf si on veut utiliser des architectures sp�ciales ou tous autres domaines hors contexte g�n�ral.

Le niveau d��tudes n�est qu�un indice, je suis sur que certaines personnes qui ont 15 ans (ou moins ?) sans dipl�me programmes mieux que moi

Sinon si tu tiens quand m�me � faire du multithreading sous OpenGL, il faut commencer � faire du partage de ressource, regarde du c�t� des contextes et des partages.

Ce qu'a voulu souligner Laurent, c'est que ce n'est pas si �vident que cela un environnement multithread (d'ailleurs j'ai pas mal de difficult� avec des fonctions type wglUseFontBitmap dans un environnement multithread)

[bafman]

je dirais m�me plus, si c'est juste pour l'affichage graphique, utiliser un thread ne sert � rien, le driver se chargeant lui m�me du parallelisme avec la carte graphique (bien mieux que ce que tu pourrai faire probablement)

de plus, utiliser des thread avec openGL, c'est chiant il y a pleins de probl�mes de partages de contextes qui sont loins d'�tres triviaux