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