OpenGL 4.2 et context partagés.

est ce que tu arrives a afiicher un cube sur le trhead principal?
On dirait que c'est un probleme avec la carte dediee, pas un probleme avec ton code.

Une remarque un peu a cote, tu as beaucoup de mutex et de lock, en general ce n'est pas une bonne idee. De un, si tu lock tout en permanence, il n'y a pas de raison de faire du multithread puisque un seul thread s'execute...

de deux, tu as des lock/unlock asymetriques parfois, je n'arrive pas a comprendre la logique derrier. Il me semble qe tu peux appeler des fonctions qui ne font jamais de unlock.

Citation:

---

est ce que tu arrives a afiicher un cube sur le trhead principal?

---

Je peux afficher un cube, si le vbo qui le contient a été chargé dans le thread principale.

Y'a pas moyen de demander à opengl de nous faire un compte rendu de tout ce qu'il fait ? histoire de voir à quel moment il n'arrive pas à écrire dans le framebuffer... ce qui à pour effet de ne rien afficher à l'écran...

Bon, pour vous éclairer un peu, je vous ai fait trois petits schémas super simplifié du fonctionnement du moteur.

Premier schéma :
Il représente le fonctionnement idéale et qui fonctionne sans soucis en opengl 3.0.
http://www.herma-soft.com/schema.png

Second Schéma :
Il représente le premier schéma sauf que le thread load attend 10 secondes avant de commencer à travailler, manière d'être bien sûr que la boucle est commencée, on sait jamais... comme ça l'ordre des actions tel qu'il est donné est obligatoirement bon.
http://www.herma-soft.com/schema2.png

Troisième schéma :
Il représente ce qu'il faut que je fasse pour que ça fonctionne en 4.2, c'est à dire charger les ressources dans la boucle de rendu.
http://www.herma-soft.com/schema3.png


Donc, les deux premiers schéma ne fonctionne pas en 4.2, seul le dernier fonctionne, sauf que l'intérêt du multithread est plus que NULL !

Les trois schéma fonctionne en 3.0

Et effectivement, les mutex sont totalement inutile ici... mais quand on sait plus que faire, on fait ce qu'on peut x)

En espérant avoir pu vous éclairer sur mon problème parce que moi je suis dans le noir ^^

Je ne sais pas si cela peut vous aider, mais pour tracer ce que fais OpenGL, vous pouvez peut être utiliser cet outil : http://zrusin.blogspot.fr/2011/09/apitrace-20.html

Merci, je savais même pas que ce genre d'outils existaient... :aie:

j'arrive pas a faire marcher celui que tu m'as donné alors j'essaye gDEBugger GL que doit prendre en main mais qui semble bien, il me trouve plein d'erreur avec les pointeurs de fonction opengl et les context, je vais donc m'affranchir de glew et charger mes fonctions à la main pour chaque context afin que chacun aient les siennes.

J'vous fait un petit retour voir si ça s'améliore d'ici peu.

gDEBugger est un outil extra. Bon ok, c'est un peu le seul qui existe coté OpenGL.

On peut réussir à avoir un log des commandes OpenGL après avoir mis en pose le programme. En plus le log (un peu lourd certes) est en HTML et affichera les valeurs des paramètres, les textures et autres buffers et shaders.
Par contre, faut tripatouiller l'outil, cliquer un peu partout une fois le programme lancer et pauser (soit à l'image, soit au prochain draw call), car il est pas totalement intuitif, mais il fait ce qu'il a à faire :)

pour celui qui a mis -1 sur mon post, si j'ai tort je veux bien savoir ou.

Tu n'est pas obligé de crée tes contexts sur les thread différent ... Personnellement, je crée tout les context sur un seul thread, les un à la suit des autres ... Ensuite chaque thread vient binder son context respectif. J'ai suivi les conseil des constructeurs pour çà, car ils précisent qu'il faut absolument aucune intervention sur un context avant d'avoir fini de crée tout les autre context qui sont partages les même ressources.

Ce que je peut te proposé, c'est de travaillé avec deux context partagé, mais avec un seul thread, qui switch entre les contexts (juste pour testé le fonctionnement des ressources partagé bien sur) et dès lors que çà sera fonctionnel tu pourra transposé çà dans ton système actuel avec tes 2 threads avec un synchronisation par fram et non par mutex pour chaque ressources. Car malgré que quelqu'un aipas aimé ma remarque, la desynchronisation du CPU et du GPU est un fait. Donc les mutex sont inutile mis à part ralentir ton thread de rendu. :aie: Sinon tu peut utiliser avec tes mutex avec des GLsync, mais tu perdrera aussi en performance, car le GPU devra attendre les instructions suivantes du CPU. ce qui est une perte de temps.

Citation:

---

il n'y a pas moyen de choisir la carte graphique dans le programme, c'est l'OS qui choisit la carte graphique et tous les contextes sont crees pour cette carte graphique.

---

Si Il existe des moyens pour çà ... seul les Geforce sous windows ne peuvent etre assigné explicitement à un context OpenGL car l'extension OpenGL de nvidia sous windows est seulement accessible avec les quadros hors de prix. Ne me demandez pas pourquoi ... ;)

ah j'aurais du etre plus precis...
dans le cas d'Optimus (deux cartes graphiques, une carte integree et une carte dediee) il n'y a pas moyen de choisir dans le programme quelle carte sera utilisee, l'OS decide de la carte a utiliser (on peut le controler a l'exterieur du programme, mais pas a l'interieur)

en effet les deux cartes ne sont jamais disponibles en meme temps, c'est soit l'une soit l'autre.

Citation:

---

car ils précisent qu'il faut absolument aucune intervention sur un context avant d'avoir fini de crée tout les autre context qui sont partages les même ressources.

---

Si cela est vrai, alors mon système est inutile :'(...

Mon but est de permettre a une fenêtre nouvellement créer de partager et d'exploiter les ressources déjà charger.

Es-tu bien sûr de cela, as-tu encore les sources qui disent cela ?

Je ne pense pas que ça rende caduque ton système.
Tu as décrit 2 threads : le principal et celui de load des ressources.
Il te suffit donc de créer 2 contextes dès le départ, un par thread.

Oui, mais il y a un thread de rendu par fenêtre ou du moins un context par fenêtre. Hors, imaginons que je décide de créer une fenêtre après l'initialisation de la première...

Bon en fait, il semblerait que cette technique soit mauvaise, non pas sur le papier... mais à cause de bug dans les drivers et le fait que les drivers ne soient pas thread-safe...
Cette technique en soit le serait, mais pas les drivers.

Le lien suivant mène à un post qui parle de cela, et l'un des participant explique qu'il fait exactement ( en théorie ) comme moi, c'est à dire créer un context caché global qui est partagé avec tous les autres contexts.

http://www.opengl.org/discussion_boa...xt-s-resources

Je ne sais plus que penser x)

Citation:

---

Si vous ne trouvez plus rien, cherchez autre chose...

---

J'vais faire ça je crois ^^

Il faut toujours prendre des précautions avant de parler de bugs dans les drivers, langages, frameworks...

Comme j'ai toujours pas compris pourquoi tu faisais autant de threads et contextes, je vais pas critiquer l'architecture, mais as tu testé avec un contexte debug comme j'ai dit ?

Fondamentalement, deux threads suffisent, mais j'en met plus parce que je veux gérer différents inputs différemment.

Je veux différents context pour ne pas charger les ressources dans le thread de rendu ainsi que pour pouvoir partager mes différentes ressources entre les différentes fenêtres, chacune aillant son thread de rendu et son context de rendu.

J'ai testé un context debug sans amélioration ni d'autre erreur opengl d'après les tests que j'ai effectués ( glGetError un peu partout ).



Une autre solution que j'explorerai par la suite sera le rendu multi-fenetre mono-context/mono-thread... ainsi j'aurai un partage des ressources comme je le veux et je mettrai sur pied un thread qui chargera les données depuis le disque et les objets opengl seront chargé depuis le thread de rendu...
Ça réduit la flexibilité mais si je peux pas faire autrement...

Citation:

---

Envoyé par exkise

Fondamentalement, deux threads suffisent, mais j'en met plus parce que je veux gérer différents inputs différemment.

---

C'est la première fois que j'entend parler de créer des threads différents pour chaque input. C'est quoi l'intérêt ???

Citation:

---

Envoyé par exkise

Je veux différents context pour ne pas charger les ressources dans le thread de rendu ainsi que pour pouvoir partager mes différentes ressources entre les différentes fenêtres, chacune aillant son thread de rendu et son context de rendu.

---

Tu appelles quelle fonctions gl dans ton thread de chargement des ressources ? Tu as bien compris que l'appel des fonctions gl est asynchrone par défaut ?

Citation:

---

Envoyé par exkise

J'ai testé un context debug sans amélioration ni d'autre erreur opengl d'après les tests que j'ai effectués ( glGetError un peu partout ).

---

tu l'utilises correctement ? J'espère que ne fais pas qu'utiliser glGetErreur mais regarde aussi le message log

Citation:

---

C'est la première fois que j'entend parler de créer des threads différents pour chaque input. C'est quoi l'intérêt ???

---

Bof, pas grand chose en vérité :aie:
C'est une partie qui n'est pas terminée, mais étant donnée que ces deux threads suplémentaire ne gène pas pour l'instant je les ai laissé, je pense les remettre en synchrone au final et laissé seulement le thread de message(chargement).
Disons que je m'étais dit "Si un type veut initialiser un menu sur l'appuie d'une touche du clavier ou pire sur un clic souris..." mais en fait il suffit d'envoyer un message au moment de l'appuie et de traité le message dans le thread de message(chargement)... Enfin bon, je ferais tout cela plus tard, pour l'instant j'ai de toutes façon désactiver les contexts de ces threads là afin de ne rien perturber.

Citation:

---

Tu appelles quelle fonctions gl dans ton thread de chargement des ressources ? Tu as bien compris que l'appel des fonctions gl est asynchrone par défaut ?

---

Oui oui, mais comme de toutes façons je veux un partage des ressources entres les contexts et que les threads sont sencé servir à d'autre chose dans l'avenir (peut-être un peu de réseau) je préférerai que ca marche comme cela.

Citation:

---

J'espère que ne fais pas qu'utiliser glGetErreur mais regarde aussi le message log

---

Euh, je ne connais pas le message log. :aie:

Tu n'as pas répondu à

Citation:

---

Tu appelles quelle fonctions gl dans ton thread de chargement des ressources ?

---

Citation:

---

Envoyé par exkise

Euh, je ne connais pas le message log. :aie:

---

Je suis entrain de finaliser un article la dessus

Désolé je l'ai zappée,

J'appelle des fonctions opengl relatives aux objets, je n'ai pas la liste exacte ( a moins que tu la veuilles au quel cas je la constituerai ).

glBind*
glGen*
glDelete*

les fonctions pour définir les données des objets (texture, vbo, ibo ).

et les fonctions utiles pour charger un programme de shader.

Citation:

---

Je suis entrain de finaliser un article la dessus

---

Super, je le lirai avec intérêt.

Pour que l'on soit bien d'accord sur le fonctionnement d'OpenGL.

OpenGL fonctionne sur le principe de client (le code hôte en C++) serveur (le runtime OpenGL). Quand tu appelles une fonction gl, l'application envoie juste une commande à OpenGL pour lui dire "fait moi ça". Ensuite l'application passe tout de suite à l'instruction suivante. De son côté, OpenGL mets la commande dans une queue et lorsqu'il a du temps libre, il exécute cette commande indépendamment de l'application. Ce temps d’exécution peut prendre du temps, mais il n'a pas d'impact sur l'application puisque c'est indépendant.

Du coup, il n'y a pas d'intérêt à mettre les fonctions gl dans un thread puisque leurs appels (côté client) ne prend pas de temps. Seuls leurs exécutions (côté serveur) prend du temps

Dans un application, certains calculs prennent du temps CPU (donc côté hôte). Par exemple, lire des données sur le disque, faire des calculs complexes sur les données, décompresser les textures, etc. En mono thread, ces temps de calcul peuvent bloquer l'interface graphique. On utilise alors un second thread pour faire les calculs, laissant le thread principal gérer les events et lancer les commandes gl

Il peut exister des cas d'utilisation plus complexes qui nécessite plusieurs threads, mais fait d'abord 1 thread de rendu fonctionnelle avant de passer à la suite

L'article en question : http://blog.developpez.com/gpu/p1124...r-avec-opengl/

Au risque de me répéter, pour le rendu multi fenêtres, tu n'es pas obligé d'avoir plusieurs contextes.
Il te suffit de passer le HDC de la fenêtre en cours de dessin à la fonction glMakeCurrent.
La seule limitation à cette technique (je suppose, à confirmer) est qu'il faut que les HDC soient compatibles.