Deux têtes pensantes de l'Intel Development Center nous livrent la recette secrète de Raptor Lake

À l’occasion de l’Intel Technologie Tour, outre les divers stands montrant des prototypes Thunderbolt et autres nouvelles technologies de la firme, nous avons pu glaner des informations auprès des concepteurs de Raptor Lake (et d’Alder Lake…). Si, auparavant (comprenez, l’époque d’Ivy Bridge), les équipes tournaient entre les ingénieurs américains et israéliens en ce qui concerne la mise au point de la prochaine microarchitecture, le balancier est resté bloqué au Moyen-Orient depuis Skylake et ses moult refresh — en attendant qu’une nouvelle équipe se forme sur le sol américain. Ainsi, les États-Unis se sont contentés du design des E-Core pour la 12ème et 13ème génération, avec le succès qu’on leur connait, alors que le P-Core a été dessiné ici, à l’Israel Development Center, sous la supervision d’Adi Yoaz pour ce qui est de l’architecture, et Moshiko Emmer pour la vérification et le debug. Entre deux couloirs et trois cafés, nous avons pu nous entretenir avec les deux personnages : de quoi vous donner une vision plus interne de Raptor Lake et des choix effectués par Intel sur cette treizième génération.

 Pour les améliorations architecturales, l’autre face des gains de Raptor Lake, c’est à Adi Yoaz qu’il faudra s’adresser…

À y regarder de loin, Raptor Lake ne semble pas issu d’années acharnées de développement comme Zen a pu l’être en son temps. Une simple remise au goût du jour de la génération précédente en gonflant les cœurs et la fréquence, voilà qui semble être une tâche aisée. Pas si vite : toper les 6 GHz sur un futur i9-13900KS tout en doublant de nombre de E-Core n’est pas une mince affaire, loin de là !

Tout commence il y a deux ans, une époque à laquelle Meteor Lake était censé succéder directement à Alder Lake, rattrapant ainsi les retards du 10 nm et de Ice Lake, finalement travestis en 14 nm sur Rocket Lake pour sortir sur PC de bureau. Les nouvelles du front, côté lithographie, ne sont pas bonnes : le météore ne sera pas prêt à temps, et il va falloir bricoler une gamme cohérente à partir du travail existant pour meubler une année. Le projet est tout naturellement confié à l’équipe israélienne, déjà aux commandes des multiples versions de Skylake (Kaby Lake, Coffee Lake, Coffee Lake Refresh, Comet Lake !) et du P-Core d’Alder Lake. Similairement au 14 nm, le 10 nm a gagné en maturité, et offre une densité supérieure de transistor, et, surtout, des rendements (yield) en hausse : de quoi permettre des puces plus grandes tout en restant rentables. Très bien : il suffit d’augmenter le nombre de E-Core pour gagner en patate en applicatif, le gain en fréquence des P-Core — voir ci-dessous pour un voyage dans les détails — devant suffire pour ce qui est du gain monocore. Cependant, un souci de taille survient : sur les plus gros designs d’Alder Lake, le débit mémoire est déjà un goulot d’étranglement des performances, les cœurs se tirant trop la bourre pour charger leurs données, parfois de manière contre-productive du fait de la cohérence des caches. Ce rajout d’E-Core et la progression de la puissance de calcul des P-Core via la cadence en hausse est la goutte d’eau qui fait déborder le vase : le sous-système mémoire doit être revu.

Or, impossible d’augmenter le débit mémoire sans toucher au nombre de canaux, qui est chasse gardée pour le segment professionnel (et impensable du point de vue de la rétrocompatibilité) : il faut optimiser avec les 2 canaux existants. Si l’architecture en ring est conservée (les données transitent sur un anneau, où les P-Core, le GPU et les clusters de 4 E-Core ont chacun un « arrêt »), les caches sont revus à la hausse, notamment par le passage à 2 Mio du L2 sur les P-Core, et 4 Mio sur les clusters d’E-Core. Enfin, pour éviter les problèmes de partages de données — rapatrier des données du L3 prend du temps, en particulier si ces données viennent juste d’être modifiées par un autre cœur —, un nouvel état est ajouté aux lignes de caches du L3 : INI/non-INI, permettant aux données d’être incluses/non-incluses dans les caches plus proches des cœurs. Ainsi, les performances en multithreading devraient être améliorées, sans pour autant recourir à un mesh (notez que Skylake-X a été le premier à utiliser cette solution, pour des CPU montants jusque 28 cœurs… de quoi donner une idée de la date d’arrivée de cette topologie sur le segment grand public). Au passage, un microcontrôleur se charge du prefetch, une solution à base de machine learning permettant de mieux limiter les cache miss : toujours cette logique d’optimisation de la bande passante mémoire.

Moshiko Emmer : la montée en fréquence, c’est lui !

Pour autant, gagner de la performance en multicore est sympathique, mais ne suffit pas à un grand nombre d’applications, notamment du côté des jeux. Pour convaincre les clients, ils faut progresser sur le plan du monothread ; et si l’IPC progresse légèrement du fait du L2 plus volumineux, les gains ne sont pas suffisants au goût de la firme. Cela tombe bien, car l’optimisation des architectures pour monter en cadence, l’équipe israélienne en connait un rayon ! Dans la pratique, l’architecture d’un processeur décrit les blocs logiques qu’il intègre, mais ne possède pas la granularité des portes logiques et des mémoires : c’est au niveau du RTL que se situe cette information. RTL qui est par la suite transformée en GDS avec l’aide d’une bibliothèque propre au processus de gravure utilisée, permettant de sélectionner quelle cellule utiliser à quel endroit.

C’est ici que vont se trouver les limitations à la montée en fréquences, nommées chemins critiques : il s’agit de zones dans lesquels le temps de propagation de l’information des électrons va se retrouvé trop proche de la cadence d’horloge du processeur : en cas de montée de la cadence, l’information ne sera plus transmise correctement, occasionnant crashs et autres BSOD bien connus des clockers. Or, puisque Raptor Lake fait suite à Alder Lake, déjà optimisé, les ingénieurs savaient en avance les endroits limitants, et ont donc pu raboter pour passer de 5,5 GHz à 6,0 GHz sur le 13900 KS, encore à venir. Au passage, nous avons pu assister à une démonstration live de surcadençage validant (pour quelques secondes) les 8 GHz sous azote liquide : les fuites étaient donc fondées !

Parmi les endroits les plus difficiles à optimiser, Moshiko cite le Reorder Buffer — mémoire contenant toutes les instructions en passe d’être exécutées et le décodeur, comme quoi les vieilles casseroles de l’x86 sont bien un désavantage quelque part. Puisque les supprimer (les casseroles, pas le ROB !) ne ferait gagner que quelques pourcents — moins de 10, nous a-t-on dit —, la logique responsable de compatibilité reste là, bien que la question se repose à chaque nouvelle révision majeure des microarchitectures.

Sur cette base, qu’est-ce que l’équipe va bien pouvoir sortir par la suite ? La réponse a été catégorique : une révision de l’ensemble du pipeline est nécessaire — de l’ordre de celle effectuée pour Sunny Cove. De quoi espérer une nouvelle fois de sacrés gains d’IPC ; si tant est que la fréquence suive côté procédé de gravure — Intel 4, à toi de jouer ! Quant à des directions de design sur le plus long terme, la chose est difficile à prédire, mais deux piliers se détachent. D’une part, l’ajout de nouvelles instructions spécialisées semble incontournable pour s’adapter aux nouveaux algorithmes : nous pensons de suite au VNNI pour les réseaux de neurones, mais aussi les extensions dédiées au chiffrement tel GFNI ou encore l’essai raté des mémoires transactionnelles avec TSX. De quoi imaginer toujours plus de logique spécialisée dans nos processeurs, une révolution somme toute déjà en marche. Cependant, des capacités de calcul fixées ne satisferont pas tous les programmes, et c’est bien là que le second pilier entre en scène : l’ajout d’unités reconfigurables. Intel a investi dans Altera, AMD a récemment racheté Xilinx : autant de signes rapprochant le monde des FPGA de celui des CPU, d’autant plus que les technologies de gravure employées sont similaires (contrairement à la DRAM ou la HBM, par exemple). Reste que ces unités seront coûteuses, en surface comme en temps de développement (du CPU comme des programmes accélérés), autant dire que les designeurs devront épuiser toutes les autres pistes d’accélération des programmes avant de s’y engouffrer : voyez donc cela comme un objectif long terme. Autant dire que le monde des processeurs n’est pas mort — loin de là — et qu’il reste encore assez d’essence pour propulser quelques générations avant de sentir la fin de la loi de Moore !