Que peut apporter le multithread au développement de jeux ?

[LeGreg]

Envoyé par ThEbAsHeR

Lorsqu'on fait un jeu se basant sur une architecture multithread on est censé, sur des processeurs multi cores, avoir de meilleurs performances, mais si je comprends bien, si ce même jeu tourne sur un processeur simple core (mais permettant le multi tâche), il sera plus lent du fait que les threads ne pourront pas être exécutés en parallèle, alors que ce serait le cas sur un processeur multi core?

J'en avais parlé un petit peu sur la première page du thread (ahah !).

Le multithread sur un simple core peut-etre utile ne serait-ce que s'il améliore l'expérience utilisateur. Par exemple Windows est multitâche/multithreadé ce qui est caractérisé par le fait que chaque application a son propre contexte d'exécution et l'OS se charge de faire le time sharing (partage du temps processeur par préemption).

C'est quelque chose à laquelle on est habitué désormais, la barre de progression de copie de fichier ne bloque pas la machine. L'attente d'une page web n'empêche pas la musique de continuer à jouer dans le background, etc. Il y a de nombreux analogues dans le jeu vidéo : chargement de ressources asynchrones (depuis le réseau ou le disque), une routine d'IA qui doit s'exécuter sur plusieurs time steps, musique qui s'exécute en fond, etc. Il est possible de s'en passer bien sûr (au coût d'une programmation plus compliquée ou d'une moins bonne expérience de l'utilisateur final), c'est juste quelque chose qui est de plus en plus fréquent.

Mais en contrepartie bien entendu, si tu prends une tâche qui était au départ unique, la diviser en plusieurs sous-tâches avec thread dédié va probablement diminuer les performances si tu n'as qu'un seul core CPU : le coût de basculer d'une tâche à l'autre n'est pas nul. Mais tu peux être adaptatif : c'est à dire diviser par autant de threads qu'il y a de processeurs ou de contextes CPU (cf hyperthreading où plusieurs contextes CPU peuvent coexister et se partager les mêmes ressources de calcul pour limiter le context-switching et maximiser l'utilisation des unités idle).

LeGreg

[The BasheR]

D'accord merci de ta réponse, ça confirme ce que je pensais. car en fait je me suis demandé pendant un moment si faire de la programmation multithread pour un processeur multi core, était différent de la programmation multithread simple (comme on en voit en effet partout pour les chargement, musique, etc...) => et quand je dis ça je parle au niveau du code, pas au niveau de la conception, qui elle, est en effet différente dans bien des situations.

Sinon de mon côté pour entrer dans le débat je suis pour la programmation multithread dans les jeux, bien que la conception derrière soit parfois plus complexe (je serais même tenté de dire que c'est tout le temps le cas).

Et sinon au sujet de revenir au software rendering, ça me parait être bien, mais est-ce que ça va impliquer de gros changements dans la programmation des jeux? Je serais tenté de dire que non, car si c'est le cas, les jeux développés pour ce type de carte ne seraient même pas compatibles avec les cartes actuelles, et pour ma part je me vois mal faire 2 versions du jeu pour gérer les différences (surtout que tout le monde n'aura pas ces cartes en même temps et beaucoup de monde restera donc encore pendant un moment sur les cartes actuelles).

Et sinon qu'en est il de l'avenir du raytracing dans tout ça?

[screetch]

Pour synthétiser ce qui a été dit précédemment :

- de nombreux jeux (presque tous) sont déjà multi-threads, pour pouvoir par exemple gérer le son et le graphisme indépendamment. Mais ils sont en général prévus pour être executés sur des simples cores

- lorsque ces jeux passent sur des multi-core, on pourrait s'attendre a un facteur x2 puisqu'on a deux CPU, mais en fait il n'en est rien

- en effet, les tâches effectuées dans des threads "correspondent mal"; dans une frame du jeu qui dure 30 millisecondes, il est possible que le jeu prenne 29 millisecondes (donc sur le CPU 1) et que le son ne prenne que 1 milliseconde (sur le CPU 2) donc le CPU 2 est sous utilisé

- On peut intuitivement esperer mieux en séparant le jeu en plus de taches (IA, rendu, particules, son, réseau, etc etc)

- mais cela reste une solution mitigée car cela ne permettra pas de s'adapter a un nombre de CPU importants (16,32 voire... le futur)


D'ou le début de la discussion, comment changer le design d'un moteur pour pouvoir s'adapter au mieux a la montée en nombre des CPU. Soit, comment occupper 100% de toute les ressources de la machine (CPU, GPU).

De plus, qui dit nombreux CPU dit nombreuses communications : "t'as fini ta tache ? balance le resultat. attend, pause, je fais un truc!! vas y, reprend. Je t'envoie des données!". Si toute les taches s'interrompent sans cesse pour demander l'état des autres taches, ou tres tres frequemment, en attente de données, alors la machine ne "travaille" pas. Il faut donc réussir a rendre les taches locales le plus possible, et avoir aussi peu de dépendances que possible. Le mieux est lorsqu'il n'y a pas de communication (c'est le principe du "fire and forget" : je lance une tache, elle se debrouille toute seule, pas besoin de quoi que ce soit)

[Ange_blond]

Sympa le petit résumé, merci beaucoup :-)

Je peux me tromper, mais de plus ce sont les carte graphiques et leurs GPU qui font de plus en plus de boulot (shader, PhysiX, ...) et donc, sauf connaissances tres avancées, le multi CPU ne sera plus une priorité, la CG fesant le gros du boulot...

Apres en effet, il restera toujours des difficultées pour gagner en temps de rendu, mais avec la montée en puissance des bécanes, les jeux et leurs codeurs plutot ne prennent plus la peine d'optimiser comme c'était le cas par le passé. De nos jours il suffit de marque sur la pochette qu'il faut une bonne bécane, (sous entendu 2Go de RAM, 2GHz, 10 Go de DD) et hop tout le monde est ravi.
Bien sûr les graphismes ont évolué, mais je ne pense pas me tromper bcp en disant qu'a présent, avec cette course au photo-réalisme, on perd de vue que le joueur moyen n'as pas envie de changer de bécane tout les 2 ans pour pouvoir jouer aux jeux de derniere génération...

[Matthieu Brucher]

Envoyé par Ange_blond

Je peux me tromper, mais de plus ce sont les carte graphiques et leurs GPU qui font de plus en plus de boulot (shader, PhysiX, ...) et donc, sauf connaissances tres avancées, le multi CPU ne sera plus une priorité, la CG fesant le gros du boulot...

Je pense plus que le GPU va progressivement laisser la place au CPU directement. Le GPU devient de plus en plus programmable, il y a déjà des projets de processeurs avec GPU intégré. Et pour que le CPU puisse travailler tranquillement pendant que le GPU fait ses petites affaires, quoi de plus simple qu'un GPU qui soit un CPU ?

[shenron666]

Envoyé par Ange_blond

Je peux me tromper, mais de plus ce sont les carte graphiques et leurs GPU qui font de plus en plus de boulot (shader, PhysiX, ...) et donc, sauf connaissances tres avancées, le multi CPU ne sera plus une priorité, la CG fesant le gros du boulot...

sauf qu'aujourd'hui, les gros jeux qui mettent à jenoux des machines de guerre sont limités par... le CPU

Envoyé par screetch

De plus, qui dit nombreux CPU dit nombreuses communications : "t'as fini ta tache ? balance le resultat. attend, pause, je fais un truc!! vas y, reprend. Je t'envoie des données!". Si toute les taches s'interrompent sans cesse pour demander l'état des autres taches, ou tres tres frequemment, en attente de données, alors la machine ne "travaille" pas.

faire cela dans un moteur de rendu temps réel c'est... suicidaire

que ce soit opengl ou directx seul le thread ayant créé a fenêtre peut envoyer des commandes, partant de ce constat je me suis dit :
- un thread principal qui s'occupe de communiquer avec le driver et qui demande à un thread de travail (via des events) de faire quelque chose (déplace les objets, gère les collisions, lance un son dans le thread sonore...)
- le thread de travail dont on peut lancer autant d'instance que l'on veut (en fonction du nombre de coeurs disponibles) va faire le travail à la demande du thread principal

Ainsi on a le thread principal qui fait office de chef d'orchestre et qui répartit les taches entre les threads de travail
s'il y a 1000 objets à déplacer il peut en donner 500 à un thread 500 à un autre

perso je n'ai pas encore eu le temps d'expérimenter la chose mais ça me botte bien comme principe

[anarkia777]

Sous le nouveau moteur Unreal mes 4 Core fonctionne.
Il en prend donc partie?

[shenron666]

si tu n'a pas d'autre application lancée en même temps que le jeu alors oui il en tire partie, ce qui ne serait pas étonnant puisque ce moteur a été créé en prenant en compte les spécificités des consoles de dernière génération :
- le processeur Xenon de la Xbox360 et ses 3 coeurs SMT peut gérer 6 threads
- le processeur Cell de la PS3 peut gérer 2 threads sur le coeur principal + 8 sur les coeurs spécifiques
et donc il est probable qu'il exploite un certain nombre de coeurs pour optimiser ses traitements

[anarkia777]

Sur mes jeux je crois c'est le seul, Crysis lui ne prend que 2 Coeurs.

C'est quoi la différence entre Treadh et Coeurs?
Un Q6600 à 4 coeurs, soit 4 processeur physique....

[Matthieu Brucher]

Les cores, c'est en gros le nombre de processeurs. Sauf que certains cores peuvent gérer plusieurs threads à la fois, à savoir plusiurs fils d'exécution. En même temps, si tu es sur cette conversation, tu dois au moins savoir la différence...

[anarkia777]

A ba non je ne connaisai pas la différence, j'ai monter des dizaine de proc sans savoir ca.

Les intel Quad sont toujours 4 core avec 4 Tread?

[Matthieu Brucher]

Un thread, c'est un fil d'exécution. Sur les nouveaux Intel, il y a à nouveau 2 fils par coeur.
Mais ça dépend plus de la capacité multi-thread du programme.

[Bakura]

Intel a mis en ligne un papier sur ça : http://software.intel.com/en-us/arti...el-game-engine

Pas eu le temps de lire par contre

[shenron666]

Envoyé par Bakura

Intel a mis en ligne un papier

papier basé sur leur récente démo dont raptor70 nous a d'ailleurs généreusement fait part

globalement c'est l'idée que je me faisait d'un moteur multithreadé
les taches qu'un moteur doit accomplir à chaque image : gérer les déplacements, les collisions, l'IA, envoyer du son, ect
disons que le thread principal, à son lancement :
- crée un thread pour gérer une liste de taches à faire à chaque image
- crée un thread de travail pour chaque coeur disponible (1 sur un dualcore, 3 sur un quadcore 7 sur un i7 vu qu'il est capable de gérer 8 threads)
puis le thread principal bascule à son tour en thread de travail
le thread de répartition des taches distribue les taches courante à tous les travailleurs

c'est pas compliqué vu d'ici mais à coder et pire à débugguer

mais à l'heure actuelle, les taches de rendu ne peuvent être effectuées QUE par le thread principal, celui qui a créé la surface de rendu
il va donc être le seul à les faire et il faudra qu'il les gère et en priorité pour éviter de créer un goulot d'étranglement

[Bakura]

- crée un thread pour gérer une liste de taches à faire à chaque image
- crée un thread de travail pour chaque coeur disponible (1 sur un dualcore, 3 sur un quadcore 7 sur un i7 vu qu'il est capable de gérer 8 threads)
puis le thread principal bascule à son tour en thread de travail
le thread de répartition des taches distribue les taches courante à tous les travailleurs

C'est vrai que dit comme ça, ça a l'air d'une simplicité .

Par contre pour le papier d'Intel, ils parlent bien de dupliquer toutes les données ? Visiblement c'est un peu ce qu'il ressort un peu partout... J'y connais pas grand chose en programmation multi-thread, mais j'avais lu un papier qui expliquait comment construire un BVH (pour le raytracing) en parallèle, et effectivement ils dupliquaient toutes les données (là ça concernait les vertices des triangles...) et travaillait avec celles-ci, et dès qu'il avait fini, il envoyait son nouveau résultat et il récupérait toutes les données nouvelles, et il repartait... Le problème c'est que si le BVH mettait trop de temps à se construire (bon, c'était pas le cas ici), ben il renvoyait un arbre qui était déjà complètement has-been par rapport aux données, puisqu'il utilisait des données déjà périmées de pas mal de frames ^^.

Pour ceux qui souhaiteraient lire : http://www.cs.utah.edu/~thiago/paper...BVHJournal.pdf