Depuis la version 3.0, sortie au début de l’année, OCCT est également capable d’effectuer le même type de test sur les processeurs graphiques : en leurs faisant traiter des shaders complexes spécialement conçus à cet effet, il est possible de pousser le GPU à ses limites pour éprouver sa stabilité. Et ne croyez pas qu’un Crysis puisse faire aussi bien : les mesures ont montrés que des tests synthétiques comme OCCT ou Furmark étaient capable de faire consommer à la puce graphique un courant nettement supérieur (parfois de l’ordre de 15 à 20%).

J’en viens au fond de l’histoire. La version 3.1 d’OCCT, sortie hier, inclut un tout nouveau test de charge GPU. Codé en HLSL au lieu de Cg et doté d’une complexité de shader paramétrable, celui-ci requiert environ 10% ressources GPU supplémentaires que la version précédente. Or, il s’avère que lorsque ce nouveau test est exécuté sur les cartes graphiques Radeon HD 4870, 4890 ou 4870X2 – dotée du design de référence d’AMD -, celles-ci plantent lamentablement au point de nécessiter un redémarrage hard de la machine.

Intrigués, nous nous sommes donc livrés à quelques tests. Configuré en plein écran, résolution haute, détection d’erreurs désactivée et complexité des shaders à 3, OCCT provoque effectivement un plantage systématique de la Radeon HD 4870 de test. Quel que soit la version du driver, la carte mère ou l’alimentation utilisée. Le problème ne survient pas sur une Radeon HD 4850, une 4770, une 3870 ou avec aucune carte nVidia en notre possession.  Pour aller plus loin, nous avons donc tenté de réduire la fréquence du GPU de la Radeon HD 4870 grave à RivaTuner et là : plus de plantages. Par contre, toujours underclockée, la carte se remet à planter invariablement si l’on augmente la tension du GPU.

A première vue, on pourrait croire à un problème de surchauffe. Dans la pratique, ce n’est pas le cas : refroidir très efficacement le GPU ne change rien au problème. En fait, le responsable serait plutôt le régulateur d’alimentation (VRM) présent sur ces cartes : bien que ne chauffant pas au delà de ses spécifications (le doter d’un dissipateur surdimensionné ne règle rien), il serait tout simplement incapable de fournir le courant nécessaire au GPU et à la mémoire en charge maximale. Et vérifier ce point est assez simple : en utilisant une Radeon HD 4870 équipée d’un VRM à 4 phases  (au lieu des 3 phases du design de référence), le problème disparait. Aux mêmes fréquences, une PowerColor PCS+ 4870 passe ainsi le test sans encombre alors qu’une Sapphire 4870 « classique » plante à tous les coups.

AMD aurait-il cherché à réduire les couts du VRM des 4870/4890 au point de provoquer une instabilité à pleine charge ? Certes, on peut se dire que de telles conditions de charge GPU n’ont visiblement pas encore été rencontrées dans un « vrai » jeu, mais est-ce vraiment une excuse ? Il est parfaitement inadmissible qu’une carte graphique (ou un processeur) soit incapable de traiter un code classique (quel qu’il soit) sans planter. Car dans le cas contraire, il faudrait freiner les développeurs afin qu’ils ne créent pas un code trop optimisé qui risquerait de faire planter le GPU. Le monde à l’envers en quelque sorte. Heureusement pour AMD, une solution logicielle déjà utilisée dans d’autres cas pourrait servir à corriger ce problème : grâce à une détection du nom de l’exécutable, le driver pourrait ainsi limiter les performances du GPU pour éviter qu’il ne consomme trop de courant… tout en limitant du même coup les performances ! Ce procédé a-t-il déjà été mis en œuvre pour éviter que certains jeux ne fassent planter la carte graphique ? Difficile à dire.

Quoiqu’il en soit, il est fort peu probable que ce défaut n’ait pas été détecté lors des tests de validation.  Et il est donc logique de croire qu’AMD a choisi de les ignorer sciemment. Le plus problématique dans cette histoire reste l’inefficacité des mécanismes de protections contre les surintensités (OCP). Sur tout design bien conçu, le régulateur devrait avertir le pilote dés que les limites des composants sont sur le point d’être atteintes, entrainant une mise en sécurisé et un underclocking automatique. A moins bien sûr que ce ne soit pas le VRM en lui-même qui soit mal conçu, mais justement ce mécanisme de limitation des surintensités…

Dans tous les cas, AMD semble s’être déjà emparé du problème. Nous ne manquerons pas de vous tenir informé de leurs explications.