Quand un moteur de tâches parallèles devient-il une bonne solution?

Je suis souvent tenté de casser le jeu sur lequel je travaille pour essayer une architecture basée sur des tâches parallèles, mais cela ne semble pas être une grande exigence pour mon projet, donc je l'évite pour le moment. J'ai l'intention de l'essayer d'abord dans un projet de jouet, pour "jouer avec le concept".

Maintenant, ce que je demande, c'est que comme beaucoup de jeux (non AAA) ne nécessitent pas vraiment de très hautes performances, on a l'impression que l'utilisation d'un moteur basé sur les tâches ne vaut pas la peine d'être dérangé jusqu'à ... quels cas?

Pour le moment, je suppose seulement que c'est nécessaire lorsque vous avez vraiment besoin d'exploiter les performances maximales du matériel (multicœur). Y a-t-il d'autres cas où c'est une bonne idée d'utiliser un moteur basé sur les tâches? Ou peut-être, pour les nouveaux projets, il est toujours bon de commencer avec un moteur basé sur les tâches?

Le filetage est utilisé dans deux situations:

1. Lorsque vous avez du travail à faire mais que vous avez besoin de réactivité pour être maintenu.
2. Lorsque vous avez besoin de la puissance de plusieurs cœurs de traitement sur votre plate-forme préférée / exigence minimale.

Si vous pouvez raisonnablement vous attendre à ce que l'une ou les deux choses soient nécessaires, allez-y. Sinon, non. Bien sûr, personne ne vous empêchera de fileter pour le plaisir parce que vous le pouvez, ou pour fouiller et enquêter, mais en termes de filetage pour les avantages de gagner réellement une application multithread, les deux cas d'utilisation ci-dessus sont à peu près tout.

Si votre jeu va être gourmand en matériel à distance, vous avez besoin de threads pour faire face à tout le matériel moderne; les futurs processeurs qui sortiront dans un an ou deux commenceront à faire de 4 cœurs le minimum et jusqu'à 16 cœurs communs pour les marchés passionnés / de performance. Si vous faites du multi-threading, faites une architecture orientée tâche, car tout autre modèle de threading est intrinsèquement cassé pour les moteurs de jeu prospectifs.

Maintenant, gardez à l'esprit que par «tâches», je veux dire «travaux» et non «threads séparés pour différents sous-systèmes de moteur». Vous ne voulez absolument pas faire quelque chose comme avoir un thread graphique, un thread physique, un thread AI, etc. Cela ne s'étend pas au-delà d'une petite poignée de cœurs et cela ne vous apporte en fait aucun véritable parallélisme de toute façon. La physique ne doit pas exécuter plus d'une mise à jour par mise à jour de l'IA (vous voulez que votre IA puisse réagir aux événements physiques), et les graphiques n'ont presque rien de nouveau à rendre si la physique n'a pas fonctionné, donc chaque sous-système s'exécute naturellement dans un ordre ordre. Tu ne

Ce que vous voulez, c'est faire. Créez une bobine de fil. Exécutez votre boucle de jeu avec la séquence classique de mises à jour de sous-système. Cependant, pour chaque sous-système, séparez la charge de travail en lots distincts séparables et distribuez-les au pool de threads. Attendez que tous les travaux soient terminés avant d'exécuter le prochain état de la boucle de mise à jour du jeu. Certains sous-systèmes peuvent avoir plusieurs sous-étapes; par exemple, les graphiques peuvent émettre une série de travaux pour effectuer l'abattage puis une deuxième série de travaux pour effectuer la création de la file d'attente de rendu. Cette approche évite le problème de synchronisation de la première approche, s'adapte à un plus grand nombre de cœurs et est franchement plus facile à coder, à déboguer et à maintenir.

Le multithreading a deux utilisations, l'une pour améliorer les performances de votre programme et l'autre pour laisser le programme s'exécuter lorsqu'un processus important est en cours. par exemple, lorsque vous essayez de charger des données, cela dérange si votre programme raccroche, vous pouvez donc utiliser un autre thread pour le chargement et garder le thread principal libre pour continuer la boucle principale. améliorer les performances à l'aide de threads est en revanche quelque chose de vraiment difficile. car en général, vous faites tout dans un processus linéaire et cela contraste avec le traitement parallèle. et vous devez toujours utiliser votre thread principal pour les mises à jour graphiques des périphériques, ce qui rend encore plus difficile la répartition des tâches entre les threads.