Nolan Mariotte
Lorsque les performances de jeu commencent à plafonner, nous nous tournons presque toujours vers le CPU à basse résolution et le GPU à haute résolution. Plus de cœurs, plus de fréquence, plus d'optimisation, oui, c'est vrai, car Intel et AMD progressent tous deux dans le gabming, cependant, de nombreux goulots d'étranglement subsistent car le code multithread en C++ finit par saturer les ressources disponibles sur les PC et les ordinateurs portables. AMD veut attaquer ce problème sous un autre angle avec HIP Threads, une bibliothèque conçue pour transférer ces charges critiques directement sur le GPU sans obliger les équipes à devenir des experts en programmation GPU. Autrement dit, ils veulent simplifier les choses compliquées pour améliorer l'exécution directe sur les cartes graphiques Radeon.
L'idée d'AMD est simple et très efficace : si la limite se situe au niveau du CPU, il vaut mieux déplacer le travail vers le GPU, mais sans réécrire la moitié d'un projet ni concevoir des noyaux à partir de zéro. Le contexte est que pour réaliser ce qu'on appelle « l'exécution sur GPU », les développeurs doivent être vraiment experts pour pouvoir porter le travail du processeur vers la carte graphique, et beaucoup de temps est perdu à bien le faire. C'est là qu'interviennent les nouveaux rouges.
AMD HIP Threads, transférer le travail du CPU vers le GPU n'a jamais été aussi simple
HIP Threads, en gros, est un projet d'écosystème ROCm qui reproduit les modèles de concurrence C++ typiques, tels que les threads et la synchronisation, et les adapte pour fonctionner sur un GPU AMD.
La manière dont il le fait est la meilleure, car au lieu d'obliger le développeur à travailler avec des grilles, des blocs, des déformations ou des modèles de mémoire spécifiques, il propose une couche qui maintient une mentalité proche de std::thread et des structures connues. L’objectif est qu’une équipe disposant déjà d’un code multithread puisse porter des régions spécifiques où elle détecte des hotspots sans repenser toute l’architecture.
Il faut dire que nous ne sommes pas confrontés à un remplacement total du modèle de programmation classique pour les GPU, il s'agit seulement d'une approche pragmatique pour des scénarios où le CPU est clairement saturé et où la parallélisation traditionnelle n'est plus évolutive, mais, surtout, où les ingénieurs n'ont pas assez de temps, ou n'ont pas l'expérience nécessaire pour le faire.
Un gain brutal de temps et de coûts pour les petits développeurs, une optimisation géante des ressources pour les plus puissants
Dans les tests partagés par AMD, des améliorations de l'ordre de 3× à 6× sont mentionnées dans les charges typiques telles que SAXPY ou la multiplication matricielle clairsemée, par rapport à l'exécution sur un CPU, même si cela dépendra toujours du modèle d'accès mémoire et du réel parallélisme de l'algorithme. Quoi qu'il en soit, il s'agit d'une amélioration impressionnante par la simplification que cela implique pour les développeurs les plus récents et les moins expérimentés. Un pas de géant pour les seniors, qui n’auront plus à consacrer autant de temps et d’efforts à ce dossier.
Sur le plan technique, HIP Threads ne fait pas partie intégrante de ROCm par défaut en tant que composant stable, c'est-à-dire qu'il n'est pas inclus pour le moment dans le package AMD. Il est distribué en tant que projet indépendant au sein de l'écosystème ROCm et nécessite des versions spécifiques, comme ROCm 7.x, en plus de la compilation et de l'intégration manuelles, tout ne peut pas être parfait et idyllique. AMD le présente dans une phase précoce, plus orientée vers l'évaluation et l'adoption progressive que vers des déploiements critiques en production pour les développeurs, encore moins pour tout le monde, il faut du temps pour déboguer les fonctionnalités et le fonctionnement, mais l'important c'est que c'est déjà là.
Ce qui est intéressant, ce ne sont pas seulement les performances, mais aussi le changement d'approche qu'AMD propose aux développeurs open source. Au lieu de supposer que l'optimisation du CPU est le seul moyen, HIP Threads suggère que de nombreux goulots d'étranglement ne nécessitent pas plus de fréquence ou plus de cœurs, mais plutôt un autre type de matériel, le GPU, simplifiant la transition de l'un à l'autre. Si AMD parvient à faire mûrir cette couche et à faciliter son intégration, elle peut devenir une véritable passerelle pour les équipes C++ qui voyaient jusqu'ici le GPU comme un domaine réservé aux spécialistes comme les développeurs seniors.
