Les GPU sont une très bonne tâche parallèle. Ce qui est génial ... si vous exécutez des tâches parallèles.
Les jeux représentent le type d'application le moins parallélisable. Pensez à la boucle de jeu principale. L'IA (supposons que le joueur soit traité comme un cas particulier de l'IA) doit réagir aux collisions détectées par la physique. Par conséquent, il doit être exécuté par la suite. Ou à tout le moins, la physique doit appeler des routines d'IA dans les limites du système physique (ce qui n'est généralement pas une bonne idée pour de nombreuses raisons). Les graphiques ne peuvent pas s'exécuter tant que la physique n'a pas fonctionné, car c'est la physique qui met à jour la position des objets. Bien entendu, l'IA doit être exécutée avant le rendu, car l'IA peut générer de nouveaux objets. Les sons doivent courir après l'IA et les commandes du joueur
En général, les jeux peuvent se faufiler de très peu de façons. Les graphiques peuvent être créés dans un fil de discussion; la boucle de jeu peut envoyer un tas de données sur le fil graphique et dire: restituer ceci. Il peut effectuer une interpolation de base, de sorte que la boucle de jeu principale ne soit pas nécessairement synchronisée avec les graphiques. Le son est un autre fil conducteur. la boucle du jeu dit "joue ceci", et c'est joué.
Après cela, tout commence à devenir douloureux. Si vous avez des algorithmes de cheminement complexes (comme pour les RTS), vous pouvez les threader. Quelques algorithmes peuvent être nécessaires pour que les algorithmes soient terminés, mais ils seront au moins concurrents. Au-delà, c'est assez difficile.
Vous avez donc 4 thèmes: le jeu, les graphiques, le son et éventuellement le traitement à long terme de l'IA. Ce n'est pas beaucoup. Et ce n'est pas presque assez pour processeurs graphiques, qui peuvent avoir des centaines de fils en vol à la fois. C'est ce qui donne aux GPU leurs performances: être capable d'utiliser tous ces threads en même temps. Et les jeux ne peuvent tout simplement pas faire ça.
Maintenant, vous pourrez peut-être aller "à fond" pour certaines opérations. Les IA, par exemple, sont généralement indépendants les uns des autres. Ainsi, vous pouvez traiter plusieurs dizaines d'IA à la fois. Jusqu'à ce que vous deviez réellement les rendre dépendants les uns des autres. Alors vous êtes en difficulté. Les objets de la physique sont également indépendants ... sauf s’il existe une contrainte entre eux et / ou qu’ils entrent en collision avec quelque chose. Ensuite, ils deviennent très dépendants.
De plus, il y a le fait que le processeur graphique n'a tout simplement pas accès aux entrées de l'utilisateur, ce qui, si j'ai bien compris, est assez important pour les jeux. Donc, cela devrait être fourni. Il n’a pas non plus accès direct aux fichiers ni aucune méthode réelle de communication avec le système d’exploitation; Encore une fois, il devrait y avoir un moyen de fournir cela. Oh, et tout ce traitement du son? Les GPU n'émettent pas de sons. Donc, ceux-ci doivent retourner à la CPU et ensuite à la puce son.
Oh, et coder pour les GPU est terrible. Il est difficile de faire le bon choix, et ce qui est «juste» pour une architecture de processeur graphique peut être très, très mauvais pour une autre. Et ce n'est même pas simplement passer d'AMD à NVIDIA; cela pourrait être de passer d'une GeForce 250 à une GeForce 450. C'est un changement d'architecture de base. Et cela pourrait facilement rendre votre code mal exécuté. C ++ et même C ne sont pas autorisés; le meilleur que vous obtenez est OpenCL, qui est un peu comme C mais sans quelques subtilités. Comme récursion . C'est vrai: pas de récursion sur les GPU.
Débogage? Oh, j'espère que vous n'aimez pas les fonctionnalités de débogage de votre IDE, car celles-ci ne seront certainement pas disponibles. Même si vous utilisez GDB, embrasse-le. Vous devrez recourir au printf
débogage ... attendez, il n'y a pas printf
de GPU. Vous devrez donc écrire dans des emplacements de mémoire et faire en sorte que votre programme de stub de processeur les relise.
C'est vrai: débogage manuel . Bonne chance avec ça.
En outre, ces bibliothèques utiles que vous utilisez en C / C ++? Ou peut-être que vous êtes plus du genre .NET, utilisant XNA, etc. Ou peu importe. Peu importe, vous ne pouvez en utiliser aucun sur le GPU. Vous devez tout coder à partir de zéro. Et si vous avez une base de code existante, difficile: il est temps de réécrire tout ce code.
Donc voilà. C'est horrible à faire pour tout type de jeu complexe. Et ça ne marcherait même pas, parce que les jeux ne sont tout simplement pas assez parallèles pour que ça aide.