Modèle de filetage pour un moteur de jeu

Question

Je suis intéressé à me lancer dans le petit moteur sur lequel je travaille pendant mon temps libre, mais je suis curieux de savoir quelle est la meilleure approche. Je suis curieux de connaître la façon recommandée de synchroniser le fil de la physique avec le reste du moteur, similaire à ThisGuy. Je travaille avec le SDK Bullet Physics, qui utilise déjà la méthode de copie de données qu'il décrivait, mais je me demandais, une fois que la balle passe par une simulation, puis synchronise les données avec les autres threads, cela ne donnera-t-il pas quelque chose synchronisation verticale, où le fil de rendu, à mi-chemin à travers les données de traitement commence soudainement à utiliser un ensemble d'informations plus récentes et différentes?

Est-ce quelque chose que le spectateur sera capable de remarquer? Que se passe-t-il si une explosion quelconque apparaît avec l'objet destiné à être détruit?

Si c'est un problème, quelle est alors la meilleure façon de le résoudre?

Verrouillez le thread physique afin qu'il ne puisse rien faire jusqu'à ce que le thread de rendu (Et fondamentalement tous les autres thread) a traversé son cadre? Cela semble perdre du temps CPU. Ou est la méthode préférable pour tripler le tampon, copier les données de physique à un deuxième emplacement, continuer la simulation physique puis copier ces données dans le thread de rendu une fois prêt?

Quelles approches recommandez-vous les gars?

Answer 1

La variante la plus simple et probablement la plus utilisée consiste à exécuter des threads physic, rend, ai, ... en parallèle et à les synchroniser après que chacun d'eux ait fini avec une image/une pas de temps. Ce n'est pas la solution la plus rapide, mais celle qui pose le moins de problèmes. La réécriture des données dans le thread de rendu pendant leur exécution entraîne des problèmes de synchronisation importants (par exemple, vous devez verrouiller chaque vecteur/matrice lors de la mise à jour). Pour rendre la paralellisation efficace, vous devez minimiser la quantité de données à synchroniser, par ex. seulement écrire des données dans le thread de rendu, qui peut être rendu. Lorsque vous ne synchronisez pas après chaque image, vous pouvez probablement obtenir l'effet que physic/ai utilise toute la puissance du CPU produisant 60fps, tandis que le moteur de rendu ne rend que 10fps, ce qui n'est généralement pas le cas. Une double mise en mémoire tampon augmenterait également les performances, mais vous devez toujours synchroniser vos threads. Un problème est ai et physique ou des threads similaires, car ils peuvent vouloir modifier les mêmes données