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

[Matthieu Brucher]

Il existe des approches de ce types, mais on sait que ça ne fonctionne pas. Ca devait être la nouvelle révolution de la programmation, mais c'est impossible de le faire.

[C-E.B]

Impossible ou plutôt impossible à l'état actuel des nos connaissances ?

En tout cas cette discussion me donne l'eau à la bouche d'essayer d'établir un moteur qui serait capable de découpler ces tâches pour améliorer le gameplay.

Quelqu'un pour se joindre à moi ?

[Matthieu Brucher]

Envoyé par C-E.B

Impossible ou plutôt impossible à l'état actuel des nos connaissances ?

Impossible, à mon avis. Déjà un code multi-thread tournant sur un seul processeur passé sur un multi-processeur donne des résultats incertains (la preuve que déjà pour les humains, il est difficile de voir ce qui se passe), donc automatiser cette tâche, sans avoir la certitude que ce qui doit se passer se passe effectivement, c'est impossible (IMHO).

[C-E.B]

En effet, je vois que tout cela révèle pas mal de problème... Cela demande réflexion !

Commençons par aborder les problèmes qui pourront être engendrés, cela permettra d'y voir plus clair et de savoir quelle solution y apportée (si une solution est possible bien sûr).

Avis donc aux amateurs.

[Bakura]

Pour apporter ma maigre contribution à cette discussion qui est vraiment passionnante (et en même temps vachement intimidante, ces histoires de cores de plus en plus nombreux, bientôt de Larabee, puis de fusion totale entre CPU-GPU, et tout ça en quelques années, ça va vraiment remettre en cause et rendre obsolète beaucoup de choses notamment dans le domaine du jeu vidéo).

En tout cas, j'avais trouvé un lien il y a quelques temps qui discute de la répartition des tâches pour les processeurs multithread et qui serait relativement scalable par rapport au nombre de cores : http://www.pablo-zurita.com.ar/spani...ra-motores-3d/ (EDIT : désolé, je croyais qu'il était en anglais, désolé pour les non-hispanophones)

[JolyLoic]

Envoyé par LeGreg

"D3D Runtime and Driver account for 25-40% of CPU cycles per frame" et c'est sans compter les cycles CPU "administratifs" que l'application doit dépenser de son coté pour garder le GPU busy. La tâche "affichage" est celle qui est coûte le plus sur un jeu moderne.

Est-ce parce qu'elle est si coûteuse qu'elle est la plus coûteuse, ou bien est-ce qu'elle a pour objectif de l'être ? Je m'explique (du moins, je tente ) :
J'ai un peu l'impression qu'aujourd'hui, pour la plupart des jeux, la condition de vente première est d'avoir un graphisme qui tourne bien et soit joli. Et qu'on n'arrive pas à aller assez loin dans ce sens avec le matériel d'aujourd'hui.

Conclusion, on attribue 95% des ressources (ressources hardware, mais aussi ressources de développement) au graphisme, et les miettes qui restent au reste. Peut-être qu'on arrivera un jour à avoir du graphisme suffisant, en qu'on pourra se concentrer sur le reste.

Ce qui fait que même si on n'arrive pas à paralléliser le graphisme (mais je ne vois pas de raisons de ne pas y arriver, après tout, ça fait plus de 10 ans que je vois des architecture graphiques parallélisées hors grand public), l'arrivée de multi-cœurs aura quand même pour effet de permettre d'avoir des jeux non pas plus rapides, mais plus riches.

Ça me désole un peu de voir que je n'ai pas plus de challenge intellectuel dans un RTS moderne que dans un warcraft.

Pour Matthieu Brucher : Sur les aspects est-ce qu'un processeur data-parallel peut améliorer les choses, je suis d'accord que ce qui compte avant tout, c'est l'algorithme, mais comme une partie de l'algorithme est directement écrite dans des processeurs spécialisés, de nouveaux processeurs peuvent avoir un impact, non ?

[Matthieu Brucher]

Envoyé par JolyLoic

Pour Matthieu Brucher : Sur les aspects est-ce qu'un processeur data-parallel peut améliorer les choses, je suis d'accord que ce qui compte avant tout, c'est l'algorithme, mais comme une partie de l'algorithme est directement écrite dans des processeurs spécialisés, de nouveaux processeurs peuvent avoir un impact, non ?

Si un coeur en lui-même est amélioré, oui. Malheureusement, on se tourne plus vers la multiplication des coeurs que vers l'amélioration d'un seul.
Mais comme dit, un processeur n'est pas task- ou data-parallel, l'implémentation d'un algorithme oui .

Sinon, complètement d'accord avec ton analyse sur le graphisme dans les jeux Ca va être un peu plus fun d'avoir de vrais adversaires.

[raptor70]

Envoyé par C-E.B

Si je suis ton raisonnement, une IA c'est de la pise de décision donc pas d'intérêt à être multi-threadé ? Ou devrait-elle avoir son propre thread ?

En fait, l'IA .. ou plus particulièrement, le pathfinding, est souvent utilisé comme exemple de système "paralellisable" car il en possède toutes les caractérisques.

Il possède généralement une structure propre à lui (un graphe, une grille ou autre) qui n'est utilisé que par lui donc pas de risque interférance extérieur.
De plus, les algorithmes peuvent être lourds et long donc pouvoir faire quelquechose en même temps est interressant.
Enfin, il a très peu d'entrée et de sortie. On lui donne un départ et une arrivée et il nous donne un chemin.

Donc en étant completement indépendant, il est très facile de lui posé un question et d'attendre la réponse (même quelques frames plus tard)..

[Matthieu Brucher]

Envoyé par raptor70

En fait, l'IA .. ou plus particulièrement, le pathfinding, est souvent utilisé comme exemple de système "paralellisable" car il en possède toutes les caractérisques.

Il possède généralement une structure propre à lui (un graphe, une grille ou autre) qui n'est utilisé que par lui donc pas de risque interférance extérieur.
De plus, les algorithmes peuvent être lourds et long donc pouvoir faire quelquechose en même temps est interressant.
Enfin, il a très peu d'entrée et de sortie. On lui donne un départ et une arrivée et il nous donne un chemin.

Donc en étant completement indépendant, il est très facile de lui posé un question et d'attendre la réponse (même quelques frames plus tard)..

Exact, on peut le mettre dans un thread à côté. En revanche, il est plus difficile de calculer deux chemins pour deux entités en même temps, car elles peuvent vouloir passer au même endroit alors qu'une seule peut passer. Et ce genre de goulot d'étranglement pour l'algorithme est fatal à la scalabilité.

[JolyLoic]

Est-ce si gênant ? Quand je planifie un déplacement, je ne sais pas si d'autres voitures vont vouloir aller comme moi, mais je m'adapte au fur et à mesure. Quitte en cas de bouchon à prendre un itinéraire bis (qui souvent me rallonge encore plus).
La planification stratégique doit certainement en tenir compte, mais le pathfinding ?

[Matthieu Brucher]

Envoyé par JolyLoic

Est-ce si gênant ? Quand je planifie un déplacement, je ne sais pas si d'autres voitures vont vouloir aller comme moi, mais je m'adapte au fur et à mesure. Quitte en cas de bouchon à prendre un itinéraire bis (qui souvent me rallonge encore plus).
La planification stratégique doit certainement en tenir compte, mais le pathfinding ?

Par exemple dans un RTS, le jeu où le pathfinding doit être au top, optimisé de manière héirarchique avec adaptation au fur et à mesure. Tu as un groupe d'unité que tu déplaces dans un canyon. Il faut que l'ensemble des unités s'organise différemment de sorte à passer l'un après l'autre. Là, le parallélisme est plus difficile à mettre en place à cause des communications entre les unités pour la réorganisation. Et faire dévier la moitié par un autre endroit n'est pas possible car tu veux attaquer ce coin de l'adversaire et non l'autre qui serait mieux protégé, ...

[raptor70]

Envoyé par Matthieu Brucher

Par exemple dans un RTS, le jeu où le pathfinding doit être au top, optimisé de manière héirarchique avec adaptation au fur et à mesure. Tu as un groupe d'unité que tu déplaces dans un canyon. Il faut que l'ensemble des unités s'organise différemment de sorte à passer l'un après l'autre. Là, le parallélisme est plus difficile à mettre en place à cause des communications entre les unités pour la réorganisation. Et faire dévier la moitié par un autre endroit n'est pas possible car tu veux attaquer ce coin de l'adversaire et non l'autre qui serait mieux protégé, ...

D'accord avec ça ... mais ce n'est plus que du pathfinding ... on a de la prise de décision

[Matthieu Brucher]

Envoyé par raptor70

D'accord avec ça ... mais ce n'est plus que du pathfinding ... on a de la prise de décision

Mais en même temps, le pathfinding doit être couplé à la prise de décision d'une manière ou d'une autre : regroupement de toutes les unités en une méta-unité qui va chercher un passage avec la possibilité de la réorganiser à la volée, ou déplacement de chaque unité mais en restant dans un groupe, sans se séparer comme c'est le cas dans certains jeux (C&C, Alerte rouge, ...).

Mais effectivement, ce n'est qu'un morceau. Le gros est de savoir ce qu'on veut faire. Mais déjà, si on peut avoir dans un FPS un thread par bot, avec plus de 16 coeurs, on se retrouve avec 16 excellents adversaires sur une partie, ça aidera les jeux les plus couramment utilisés.

[deadalnix]

En même temps il n'y a pas que les unités dans le canyon sur la map, donc il y a moyen de paralléliser tout de même.

On peut de plus imaginer un recherche de solution indépendante des unités puis une concertation de groupe afin d'affiner le résultat. Cette affinement devant être léger car non parallélisable.

Il est de plus erroné de penser en thread selon moi. Il convient mieux de penser taches indépendantes. Un taskManager se chargera de répartir ses tache sur les threads.

[LeGreg]

Envoyé par deadalnix

En même temps il n'y a pas que les unités dans le canyon sur la map, donc il y a moyen de paralléliser tout de même.

Il y a beaucoup de MMOG qui arrivent à paralléliser/distribuer les tâches. Parfois l'utilisation d'un langage autre que C++ permet de mieux exprimer les indépendances/dépendances entre threads. Eve online travaille avec une version de Stackless python, Vendetta online avec Erlang.