AMX à 16 et 32 tuiles : faits confirmés et limites
L'accélération matérielle des calculs matriciels au sein des processeurs généralistes x86 constitue un axe majeur d'évolution des architectures de jeux d'instructions (ISA) modernes. L'introduction par Intel des extensions AMX (Advanced Matrix Extensions) sur l'architecture Xeon Sapphire Rapids a marqué une étape décisive en intégrant des registres bidimensionnels (tiles ou tuiles) et une unité d'exécution dédiée à la multiplication matricielle (Tile Matrix Multiply, TMUL). Les implémentations Intel commercialisées à ce jour utilisent 8 tuiles avec la configuration standard « Palette 1 ». Un message publié sur la liste de diffusion du noyau Linux le 27 juillet 2026 décrit cependant le comportement d'implémentations à 16 et 32 tuiles et affirme qu'une telle solution fonctionne déjà à grande échelle. Le concepteur, le produit et les performances mesurées ne sont pas révélés.
L'identité de l'entité à l'origine de ces implémentations n'est pas publique. Le fait que l'auteur ait évoqué séparément, en 2025, une entreprise x86 autre qu'Intel ou AMD ne prouve pas que cette même entreprise soit derrière les variantes AMX à 16 et 32 tuiles. Leur intérêt potentiel est clair — davantage de données conservées dans le fichier de tuiles — mais leurs gains réels dépendront de l'unité de calcul, de la bande passante mémoire, du logiciel et du coût de gestion de l'état.
Spécifications architecturales : de 8 à 16 et 32 tuiles
L'architecture AMX d'origine repose sur un jeu de registres matriciels à deux dimensions associés à des métadonnées de contrôle. Dans le modèle standard d'Intel, la Palette 1 alloue une capacité totale de stockage de 8 Ko répartie sur 8 registres nommés tmm0 à tmm7. Chaque tuile peut stocker jusqu'à 16 lignes de 64 octets, soit 1024 octets par registre, adaptables dynamiquement en fonction des dimensions des sous-matrices opérées.
La configuration logique est décrite par TILECFG, un descripteur de 64 octets chargé depuis la mémoire par l'instruction ldtilecfg. Il contient notamment l'identifiant de palette (palette_id), la ligne de reprise après interruption (start_row) et les dimensions de chaque tuile prise en charge par la palette.
| Paramètre Architectural | AMX Intel Standard (8 Tuiles) | Implémentation signalée (16 Tuiles) | Implémentation signalée (32 Tuiles) |
|---|---|---|---|
| Identifiant de Palette | Palette 1 | Non communiqué | Non communiqué |
| Nombre de Registres (tmm) | 8 registres (tmm0–tmm7) | 16 registres (tmm0–tmm15) | 32 registres (tmm0–tmm31) |
| Capacité du Fichier de Registres | 8 Ko (8 × 1 Ko) | 16 Ko (16 × 1 Ko) | 32 Ko (32 × 1 Ko) |
| Dimensions Max par Tuile | 16 lignes × 64 octets | 16 lignes × 64 octets (non confirmé) | 16 lignes × 64 octets (non confirmé) |
| Surcoût potentiel de l'état XSAVE | 8 Ko (XFEATURE_XTILEDATA) | 16 Ko théoriques | 32 Ko théoriques |
| Prise en charge des types de données | Selon les sous-extensions CPUID | Selon les sous-extensions CPUID | Selon les sous-extensions CPUID |
Le message LKML décrit des implémentations à 16 et 32 tuiles, mais les détails publics disponibles ne suffisent pas à fixer leur identifiant de palette, leur encodage TILECFG ni toutes leurs sous-extensions de calcul. Si chaque tuile conserve la capacité maximale de 1 Ko du modèle Intel, le fichier atteindrait respectivement 16 et 32 Ko. Cette capacité supplémentaire peut réduire certains rechargements dans les boucles GEMM, sans garantir à elle seule un gain de débit.
Implications microarchitecturales et surcoût des changements de contexte
Davantage de tuiles augmente la capacité de travail locale, mais agrandit aussi l'état architectural susceptible d'être sauvegardé, restauré ou virtualisé. Le compromis dépend donc autant du logiciel système que du matériel.
Croissance de l'état par thread et impact XSAVE
Dans l'architecture x86_64, la sauvegarde et la restauration de l'état des registres étendus lors des changements de contexte reposent sur le sous-système XSAVE. À titre de comparaison, l'ensemble des registres vectoriels AVX-512 représente 2 Ko d'état. L'implémentation AMX à 8 tuiles ajoute à elle seule 8 Ko d'état via le composant XFEATURE_XTILEDATA.
Avec des tuiles de 1 Ko, 32 registres représenteraient 32 Ko de données par fil d'exécution. Cela augmente le coût potentiel des changements de contexte et de la virtualisation, mais il serait incorrect d'en déduire une dégradation « critique » systématique : le coût réel dépend de l'énumération XSAVE, de l'état effectivement utilisé, des optimisations du noyau et de la fréquence des changements de tâche.
Gestion dynamique par le noyau Linux via arch_prctl
Afin d'éviter de pénaliser les processus n'utilisant pas les instructions matricielles, le noyau Linux met en œuvre une allocation d'état dynamique à la demande (Dynamic State Allocation). Un processus doit obligatoirement émettre un appel système préalable sollicitant l'autorisation d'utiliser la fonctionnalité via le contrôle d'architecture SYS_arch_prctl et le fanion ARCH_REQ_XCOMP_PERM associé à XFEATURE_XTILEDATA.
Cet appel permet au noyau d'allouer la mémoire nécessaire à cet état dynamique. Il ne faut toutefois pas confondre cette allocation à la demande avec un retour à la restauration paresseuse historique de l'état FPU. Pour des variantes à 16 ou 32 tuiles, les points déterminants seront le format XSAVE réellement énuméré, les optimisations de sauvegarde disponibles et l'organisation des charges de calcul afin de limiter les changements de contexte.
Potentiel de performance et pression sur les registres
L'accélération des opérations GEMM dépend directement de l'efficacité du tuilage mémoire (tiling) et de la capacité du matériel à masquer les temps de chargement des données par du calcul utile.
Avec 8 tuiles, la pression sur les registres peut limiter l'ordonnancement de certains noyaux. Une répartition classique attribue 2 tuiles pour la matrice d'entrée A, 2 tuiles pour la matrice B, et 4 tuiles pour les accumulateurs de la matrice de sortie C. Cette structure impose un rechargement séquentiel des tuiles A et B via l'instruction tileloadd entre chaque produit matriciel intermédiaire (tdpbf16ps), ce qui peut créer des temps d'attente lorsque la hiérarchie mémoire n'alimente pas assez vite les registres.
Avec 16 ou 32 tuiles, le logiciel disposerait de davantage de marge pour dérouler les boucles, conserver plus d'accumulateurs et organiser un double ou multi-buffering. Cela peut favoriser le recouvrement entre chargements et calculs, mais tileloadd n'est pas présenté comme une opération explicitement asynchrone et aucun « recouvrement parfait » ne peut être promis. Le gain dépendra du moteur d'exécution, des caches, de la bande passante et de la qualité du noyau logiciel ; des benchmarks sont indispensables.
Analyse des cas d'usage hors intelligence artificielle
AMX a d'abord visé les charges matricielles d'intelligence artificielle, notamment via AMX-INT8 et AMX-BF16. D'autres sous-extensions, comme AMX-FP16 ou AMX-COMPLEX, dépendent du processeur et doivent être détectées par CPUID. Un nombre supérieur de tuiles pourrait profiter à d'autres calculs matriciels, mais cela reste à démontrer pour chaque usage.
- Traitement d'image et calcul numérique dense : des filtres, transformations et noyaux réorganisables sous forme de blocs matriciels pourraient exploiter davantage de tuiles. En revanche, aucun résultat public ne permet aujourd'hui d'affirmer une forte réduction de consommation face à AVX-512 ou à un GPU.
- Algèbre linéaire creuse et graphes : les formats creux par blocs contenant des sous-matrices denses pourraient bénéficier d'un fichier de tuiles plus grand. Les structures très irrégulières restent toutefois difficiles à exploiter efficacement avec une unité matricielle dense ; le bénéfice doit être mesuré cas par cas.
Dynamique industrielle, concurrence et standardisation de l'ISA
Cette divulgation est techniquement intéressante, mais elle ne suffit pas encore à établir un changement de l'équilibre concurrentiel de l'écosystème x86. Aucun fabricant, produit, calendrier ni chiffre de performance n'est public.
Intel a introduit AMX, tandis que la spécification ACE publiée en 2026 est portée par l'écosystème x86 et décrit toujours 8 tuiles dans sa version 1. Le message de Christian Ludloff documente des comportements à 16 et 32 tuiles, mais il ne s'agit pas, dans les éléments publics examinés, d'une série de patchs Linux attribuée à un fabricant. Toute identification d'un concepteur asiatique, d'un hyperscaler ou d'un concurrent précis serait spéculative.
La comparaison avec ARM SME/SME2 ou les Tensor Cores des GPU doit rester prudente : ces architectures diffèrent par leur modèle de programmation, leurs types numériques, leur alimentation en données et leur débit. Un fichier de tuiles plus grand peut réduire la pression sur les registres, mais ne suffit pas à « rattraper » un GPU ni à prédire l'efficacité énergétique.
Le principal risque logiciel est une divergence d'énumération, d'encodage ou de format d'état entre implémentations. Une spécification publique commune, une détection fiable par CPUID et une prise en charge cohérente dans le noyau, les hyperviseurs, GCC, LLVM et les bibliothèques sont nécessaires pour préserver la portabilité.
Conclusions et recommandations système
L'information est crédible et techniquement significative : des implémentations AMX/ACE à 16 et 32 tuiles sont décrites comme opérationnelles à grande échelle. Elle reste néanmoins préliminaire et anonyme. La capacité de registre pourrait être multipliée par deux ou quatre par rapport au modèle à 8 tuiles, mais ni l'architecture complète, ni le produit, ni les performances ne sont publics.
Trois points devront être vérifiés avant de conclure à une avancée concrète :
- Gestion du contexte : vérifier l'énumération XSAVE, la taille réelle de l'état, son allocation dynamique et le coût mesuré des changements de tâche et de machine virtuelle, sans présumer qu'une restauration paresseuse constitue la bonne solution.
- Chaîne logicielle : adapter assembleurs, compilateurs, noyau, hyperviseurs et bibliothèques afin qu'ils détectent et exploitent correctement plus de 8 tuiles.
- Validation des performances : publier des benchmarks reproductibles sur GEMM, l'inférence, la virtualisation et les changements de contexte, avec consommation et bande passante mémoire.