Présentation du problème

Lorsque l'on travaille avec des GPU modernes et profonds comme le Nvidia B200, l'analyse statique est nécessaire mais insuffisante pour valider les plans d'instruction. Il est frustrant de voir un planificateur signaler une couverture de test de 100 % sur le suivi des dépendances, seulement pour voir le code émis échouer silencieusement sur le silicium réel.

Contexte technique

Le pipeline matériel lui-même est l'arbitre final de la correction. Lorsqu'un planificateur sous-estime une dépendance, il permet à une instruction consommatrice d'être émise dans le pipeline avant que le résultat du producteur ne soit fermement enregistré dans le fichier des registres. Le matériel n'élève pas d'exception. Au lieu de cela, il exécute le plan, lit un état obsolète et propage des valeurs incorrectes à travers le reste du calcul.

Ces problèmes ne sont pas des défauts du silicium. Ce sont des violations de plan où le matériel expose les hypothèses incorrectes du compilateur. Dans les backends de compilateur, les ingénieurs de compilateur adhèrent généralement à la règle : la sur-estimation est un bogue de performance, mais la sous-estimation est un bogue de correction silencieux.

Fonctionnement du pipeline

Pour comprendre ces problèmes, il est utile d'établir un contexte de base : l'ordonnancement des instructions est une phase du backend du compilateur qui réorganise les instructions pour maximiser l'utilisation du matériel. Il doit explicitement encoder les retards (stalls) ou la synchronisation (scoreboards) entre les instructions dépendantes.

La profondeur du pipeline est le nombre d'étapes qu'une instruction traverse (récupération, décodage, exécution, écriture). Les pipelines plus profonds prennent plus de temps pour terminer une instruction. Le matériel repose sur le compilateur pour encoder explicitement les informations de dépendance.

Implications et limites

Pour éviter ces problèmes, l'analyse des opérandes d'un planificateur doit correctement identifier les utilisations de chaque instruction. Cependant, la véritable défense est une sonde sur silicium. Il est nécessaire de balayer les cycles de stall entre les instructions pour vérifier la latence minimale requise pour une exécution correcte.

Les instructions arithmétiques à latence fixe forment la colonne vertébrale de la multiplication de matrices et des charges de travail de cœur de tenseur. Elles nécessitent des retards de cycle précis avant que leurs registres de destination puissent être lus en toute sécurité. Des exemples incluent FFMA (Fused Multiply-Add à précision simple) et DFMA (Fused Multiply-Add à précision double).

ISETP.GE.AND P1, PT, R0, R1, PT;
@!P0 BRA P1, target;

Ces exemples montrent l'importance de comprendre les dépendances entre les instructions et les latences matérielles pour éviter les bogues silencieux dans les plans d'instruction.