Dans mon expérience, qui n'est pas le domaine du jeu, mais qui tourne sur du matériel et a des contraintes de performance assez comparable, nous sommes confrontés à un écueil dont on ne parle pas assez: déplacer les données. Ou comment exploiter des téraflops sur des GB/s... ça ne passe pas! Nous sommes toujours à décider à propos de où mettre telle ou telle donnée, selon son chemin complet entre le GPU, le CPU (et le reste des périphériques, ce qui nous différencie du domaine du jeu).
En gros, si on peut se contenter comme sous DirectX9 de balancer des données sur un GPU et le laisser bosser (mode "fire and forget"), tout va bien, on pourra dans l'avenir faire des centaines++ de TFlop sur 10 GB/s, si bien sur on a l'utilité d'effets graphiques ultra compliqués. Le multi-thread est compréhensible, ses gains estimables, les évolutions sur CPU multi-coeur et sur les GPU annoncés sont faciles à anticiper.
Par contre, dès qu'on veut faire des aller-retour entre le GPU et le CPU, on a une dégelée de paramètres supplémentaires qui peuvent tout chambouler: les bus, leur bande passante, les tailles de cache et les vitesses respectives, la synchronisation, les plages de mémoire spécialisées, etc. Aujourd'hui, une jungle infâme avec des choses non documentées, des drivers qui se permettent de tout casser d'une version mineure à l'autre, bref une horreur qui perturbe gravement toute extrapolation.
C'est pourquoi je pense que la question initiale ne peut pas faire l'économie du contexte: multi-thread dans le CPU et sans interaction avec le GPU? Oui, bien sûr, mais il n'y a pas énormément à gagner (quel jeu est vraiment limité par le CPU?). Multi-thread à l'intérieur du GPU sans interaction avec les CPU (fire-and-forget)? Ben ya pas le choix de toute façon, et bien sur il faut y aller à fond, c'est le point fort du système, par contre là non plus il n'y a pas non plus vraiment beaucoup à gagner, on est vraiment coincé dans un GPU qui peut pas faire grand chose pour l'ensemble de l'appli. Multi-thread avec interactions significatives entre le GPU et le CPU? Là on rentre dans des subtilités qui font que l'aspect multi-thread va souvent être l'esclave des autres contraintes, et ne va pas apporter grand chose par soi-même, mais va peut-être justement se révéler déterminant dans la bonne utilisation combinée.
Si on regarde un peu plus loin, lorsque les différents matériels convergent (Larrabee...), et donc très probablement des outils plus standards, extensibles et simples pour la circulation des données?
Là, je ne vois pas comment éviter une conception extrêmement différente des applications actuelles. La programmation de ces trucs sera probablement très inspirée du mode de raisonnement utilisé actuellement pour essorer à fond les GPUs d'aujourd'hui, sauf que ce sera étendu à une variété de tâches bien plus grande... Bien du travail en perspective, mais c'est passionnant.
Pour qu'on en arrive là, il faudra aussi que les langages utilisés se plient aux critères de productivité récents. Si C++03/0x n'est pas supporté, qui va prendre le risque de faire passer tout un projet en CUDA ou proche? Et comment faire un vrai compilateur capable de tirer parti de Larrabee à partir d'un programme C++0x?
Pour rester avec des choses réalistes, si on suppose qu'il y a bien un projet de compilateur C++0x pour Larrabee basé sur la TBB (ça parait très fortement pas impossible du tout...), alors il vaut mieux se préparer à un gros choc. Les nouveautés annoncées en Juin sont franchement pas simples (affinité avec les threads). Je m'attend à une courbe d'apprentissage rude d'après les premiers tests que nous avons fait.
Par contre, je vois bien des bases très intéressantes se mettre en place chez Intel, on a vraiment l'impression qu'ils ont une vision d'un mouvement d'ensemble vers des architectures bien plus intégrées que maintenant, prenant en compte non seulement des cœurs (très) multiples, mais surtout la glu nécessaire pour qu'ils fonctionnent au mieux ensemble.
Partager