Mesa 26.3 a activé le mode Large GRF pour les cartes graphiques Intel, ce qui double la part de registres attribuée à un fil matériel, de 128 registres à 256. Les commits sont arrivés pendant le week-end du 8 août et couvrent DG2 Alchemist, donc les Arc série A, ainsi que Xe2 Battlemage et les graphiques intégrés de Lunar Lake. Xe3 atteint les mêmes 256 registres par un autre mécanisme, le Variable Register Thread. Le gain, ce sont moins de déversements de registres vers la mémoire. Le coût est réel et mérite d'être compris avant d'attendre des performances gratuites : une unité qui donne deux fois plus de registres à chaque fil ne peut en garder que moitié moins en vol.
The short answer
Le git de développement de Mesa 26.3 a activé le mode Large GRF pour les cartes Intel, doublant la part du fichier de registres généraux donnée à un fil matériel, de 128 registres à 256. Sont couverts DG2 Alchemist, Xe2 Battlemage et les graphiques intégrés de Lunar Lake, Xe3 atteignant le même compte par le mécanisme plus récent du Variable Register Thread. L'objectif est d'empêcher les shaders complexes de déverser des valeurs en mémoire. Le prix, c'est l'occupation : le fichier de registres est fixe, donc deux fois plus de registres par fil signifie deux fois moins de fils résidents sur une unité d'exécution.
Deux commits ont atterri dans le git de développement de Mesa 26.3 pendant le week-end du 8 août, et ils changent quelque chose que les auteurs de shaders sur matériel Intel voulaient depuis longtemps sans pouvoir le demander. Le mode Large GRF est désormais actif, ce qui permet au compilateur de donner à un seul fil matériel 256 registres généraux au lieu des 128 par défaut.
Cela ressemble à un simple doublement de ressource, et ça l'est presque. Ce qui rend la chose intéressante, c'est que la ressource n'a jamais été gratuite.
D'où viennent les registres
Une unité d'exécution Intel contient un fichier de registres généraux, un bloc de stockage rapide physiquement attaché à l'unité. Sa taille est fixe. Chaque fil matériel qui tourne sur cette unité en prend une part, et la taille de cette part détermine combien de fils peuvent être résidents simultanément.
Dans la configuration par défaut, un fil obtient 128 registres de 64 octets chacun, et l'unité garde huit fils en vol. Passez en Large GRF et un fil obtient 256 registres, ce qui veut dire que le même fichier physique n'en supporte plus que quatre. Rien n'a été ajouté au silicium. La répartition a simplement changé, et le nombre de fils simultanés découle de l'arithmétique.
Sur Xe2, la même relation apparaît dans le budget de jetons : un fil reçoit 16 jetons quand le moteur vectoriel fait tourner huit fils, et 32 en mode Large GRF quand il en fait tourner quatre.
Le problème que cela résout
Le déversement de registres est la raison pour laquelle on veut ce mode.
Quand un shader garde vivantes plus de valeurs simultanées qu'il n'a de registres pour les tenir, le compilateur en déplace une partie en mémoire et les recharge quand elles servent. Sur un processeur c'est désagréable mais supportable, puisque la valeur atterrit d'ordinaire en L1, à quelques cycles. Sur un GPU c'est nettement pire. La hiérarchie mémoire est relativement plus lointaine, et le shader tourne en des milliers d'instances simultanées, si bien qu'un seul déversement dans la source devient un trafic considérable dans la machine.
Les shaders qui heurtent ce mur sont les compliqués : noyaux de lancer de rayons, calcul lourd, tout ce qui porte beaucoup d'état vivant. Doubler le budget de registres peut prendre un shader qui déversait et le faire tenir entièrement en registres, ce qui ne le rend pas un peu plus rapide, cela supprime toute une catégorie de trafic mémoire.
L'arbitrage qu'il ne faut pas sauter
L'occupation, c'est la façon dont un GPU masque la latence. Pendant qu'un fil attend un chargement mémoire, l'unité en fait tourner un autre. Ramener les fils résidents de huit à quatre réduit de moitié la capacité de la machine à faire cela.
Que ce soit grave ou non dépend entièrement du shader.
Un shader très arithmétique qui bloque rarement sur la mémoire n'a pas besoin de huit fils pour remplir le pipeline. En perdre la moitié coûte peu, et si le même changement supprime les déversements, le bilan est clairement positif. Un shader limité par la mémoire est l'image miroir : il comptait sur ces fils pour couvrir la latence, et les lui retirer fait plus de mal que les déversements évités ne font de bien.
C'est pour cette raison que Large GRF est une heuristique de compilateur et non un interrupteur. Le pilote décide shader par shader si la pression sur les registres justifie de payer ce prix. Le guide d'optimisation d'Intel dit la même chose plus platement : le bénéfice dépend de la charge.
Xe3 s'y prend autrement
Le matériel récent emprunte une voie plus souple. Plutôt que de choisir entre deux configurations figées, Xe3 utilise le Variable Register Thread, qui laisse l'allocation varier au lieu de se caler sur 128 ou 256. Le second des deux commits Mesa ouvre cette voie.
C'est une meilleure conception, parce que le choix binaire est un instrument grossier pour une décision aussi sensible à la charge. La contrainte de fond n'a pas bougé pour autant. Le fichier de registres reste un budget fixe, et chaque registre donné à un fil est un registre qu'un autre fil n'aura pas.
Ce que nous ferions
Rien, et pour une fois c'est la réponse honnête.
Il n'y a aucun drapeau à poser et aucun réglage à faire. Le travail est dans le git de développement de Mesa 26.3, il vous parviendra donc quand votre distribution empaquettera cette version, et les distributions à publication continue le verront bien avant les autres. Nous avons couvert récemment Mesa 26.2 et les mesh shaders dans le pilote NVK, et le motif est le même : le travail intéressant dans Mesa se déplace vers le compilateur plutôt que vers les cases à cocher.
Le seul public à qui cela mérite d'être signalé, ce sont ceux qui mesurent les performances des graphiques Intel sous Linux d'une version de Mesa à l'autre. Une heuristique de compilateur qui change l'allocation des registres peut faire bouger sensiblement un titre chargé en shaders sans qu'une seule chose ne change dans votre configuration, et si vous ignorez que ce mode a atterri, cela ressemble à du bruit de mesure plutôt qu'à un vrai résultat.
Sources et pour aller plus loin
- Mesa 26.3 Intel driver code enables Large GRF mode for newer GPUs, Phoronix, 9 août 2026
- Mesa turns on Intel Arc Large GRF mode, 256 registers, half the threads, Hardware Busters
- Architecture GPU Intel Xe, guide d'optimisation oneAPI
- Registerization and avoiding register spills, guide d'optimisation Intel oneAPI
- Looking ahead at Intel's Xe3 GPU architecture, Chips and Cheese
Questions fréquentes
Qu'est-ce que le déversement de registres et pourquoi coûte-t-il si cher sur un GPU ?
Un compilateur de shaders affecte à des registres matériels les valeurs qu'un programme garde vivantes. Quand un shader a besoin de plus de valeurs vivantes simultanées qu'il n'y a de registres pour les tenir, le compilateur doit en placer une partie en mémoire et les recharger plus tard. C'est un déversement. Sur un processeur la pénalité reste modeste parce que la valeur atterrit dans le cache L1, à quelques cycles. Sur un GPU c'est pire pour deux raisons : la hiérarchie mémoire est relativement plus lointaine, et le shader tourne en des milliers d'instances simultanées, donc un seul déversement dans le code devient un trafic énorme en pratique. Les shaders complexes, les noyaux de lancer de rayons et les charges de calcul lourdes sont ceux qui heurtent ce mur, c'est exactement la population visée par Large GRF.
Pourquoi doubler les registres divise-t-il le nombre de fils par deux ?
Parce que le fichier de registres généraux est une quantité fixe de stockage physique sur l'unité d'exécution, et que les fils se le partagent. Chaque registre fait 64 octets de large, et dans la configuration par défaut un fil matériel reçoit une part de 128 d'entre eux. L'unité peut alors garder huit fils résidents à la fois. Demandez 256 registres par fil et le même fichier physique n'en supporte plus que quatre. Rien n'a été ajouté au matériel, seule la répartition a changé. Sur Xe2, la même arithmétique apparaît dans le budget de jetons : un fil obtient 16 jetons quand le moteur vectoriel fait tourner huit fils, et 32 en mode Large GRF quand il en fait tourner quatre.
Si l'occupation chute de moitié, quand est-ce vraiment gagnant ?
Quand le shader déversait et n'avait pas besoin de beaucoup de fils pour rester occupé. L'occupation, c'est la façon dont un GPU masque la latence mémoire : pendant qu'un fil attend un chargement, d'autres travaillent. Un shader très arithmétique et peu bloqué sur la mémoire n'a pas besoin de huit fils pour remplir le pipeline, donc en perdre quatre coûte peu tandis que supprimer les déversements rapporte beaucoup. Un shader limité par la mémoire est le cas inverse, et diviser par deux les fils disponibles pour masquer la latence fera plus de mal que les déversements évités ne font de bien. Intel le dit dans son propre guide d'optimisation : le bénéfice dépend de la charge. C'est pour cela qu'il s'agit d'une heuristique de compilateur et non d'un interrupteur global.
Quel matériel Intel est couvert, et qu'en est-il de Xe3 ?
Les commits couvrent DG2 Alchemist, c'est-à-dire les cartes dédiées Arc série A, et Xe2 Battlemage, qui couvre les Arc série B ainsi que les graphiques intégrés de Lunar Lake. Xe3 arrive au même endroit par une autre route. Plutôt qu'un mode Large GRF fixe, Xe3 utilise le Variable Register Thread, qui laisse l'allocation de registres varier au lieu de choisir entre deux configurations figées. C'est une conception plus souple, et cela signifie que le compilateur prend une décision plus fine sur les puces récentes, mais l'arbitrage de fond ne change pas : le fichier de registres reste un budget fixe et en donner plus à chaque fil revient à en faire tourner moins.
Faut-il faire quelque chose pour en profiter, et quand sort Mesa 26.3 ?
Non, et pas tout de suite. Le travail a atterri dans le git de développement de Mesa 26.3, ce qui veut dire qu'il arrive sur votre machine quand votre distribution empaquette cette version, et les distributions à publication continue le verront bien avant les autres. C'est une décision interne au pilote, pas une fonctionnalité à activer : le compilateur décide shader par shader si la pression sur les registres justifie le mode. C'est la bonne conception vu à quel point l'arbitrage dépend de la charge, et cela veut aussi dire qu'il n'y a rien à configurer ni rien à rater. Si vous mesurez les performances des graphiques Intel sous Linux d'une version de Mesa à l'autre, il vaut mieux savoir que cela a atterri, car un titre chargé en shaders peut bouger sans que rien ne change chez vous.