FEX 2608 est sorti le 4 août, et le changement à comprendre concerne la consommation. Quand du code x86 émulé tourne en boucle en attendant un atomique, FEX utilise désormais l'instruction ARM WFE sous Wine, ce qui place le cœur en état basse consommation au lieu de brûler des cycles dans une boucle vide. Le projet indique que cela peut économiser plusieurs watts sur les applications concernées. S'y ajoutent des améliorations SVE 256 bits, une correction de l'état AVX mal sauvegardé et restauré au passage des signaux, deux bogues Wine autour de VirtualProtect et des threads non suivis, et la suppression du binaire FEXInterpreter.
The short answer
FEX 2608 est disponible. Le changement principal : les boucles d'attente sous Wine passent par WFE, donc un cœur ARM qui attend un atomique bascule en basse consommation au lieu de tourner à vide, ce qui économise des watts selon le projet. La version apporte aussi des améliorations SVE 256 bits, une correction de l'état AVX au passage des signaux, des correctifs Wine pour VirtualProtect et les threads non suivis, et du travail d'optimisation dans le JIT. FEXInterpreter est supprimé.
Les notes de version d'un émulateur alignent d'habitude des correctifs de compatibilité. Celle-ci contient un changement sur l'art de ne rien faire efficacement, et c'est un plus beau problème qu'il n'y paraît.
FEX, l'émulateur soutenu par Valve pour exécuter des binaires x86_64 sur ARM64, a publié sa version 2608 le 4 août. Le changement que nous mettrions en avant concerne les boucles d'attente. Quand du code émulé reste dans une boucle serrée à guetter un atomique, FEX traduit désormais cette attente sous Wine avec WFE, l'instruction ARM qui gare le cœur en basse consommation jusqu'à l'arrivée d'un événement. Le projet décrit lui-même le gain comme plusieurs watts économisés sur les applications concernées.
Pourquoi une boucle vide est un problème d'émulateur
Un verrou tournant est un choix raisonnable pour un programme. Le thread anticipe une attente courte, plus courte que le coût d'un aller-retour vers le noyau et d'un réordonnancement, alors il boucle et vérifie au lieu de dormir.
L'ennui vient du coût de cette boucle sur l'hôte. Le binaire a été compilé pour x86, où l'idiome inclut une indication PAUSE qui prévient le processeur qu'il s'agit d'une attente et qu'il peut lever le pied. Traduisez cela naïvement vers ARM64 et vous obtenez une boucle qui martèle une adresse mémoire à pleine vitesse, sans rien qui invite le cœur à se détendre. Multipliez par un jeu dont plusieurs threads se coordonnent, et vous avez des cœurs à pleine puissance qui ne font strictement rien.
WFE comble cet écart. La boucle lit une fois, puis attend un événement, et le cœur reste en basse consommation jusqu'à la libération du moniteur exclusif ou un signal. La sémantique vue par le programme émulé ne change pas. Le profil énergétique, si.
Sur un poste fixe, cela se lit sur un wattmètre. Sur un portable ARM64 ou une console portable, c'est-à-dire précisément là où les gens font tourner FEX, cela s'appelle autonomie et bruit de ventilateur.
Le reste de la version
Les correctifs Wine sont les plus concrets. VirtualProtect pouvait échouer là où l'appel aurait dû réussir, et des threads non suivis pouvaient dérégler le suivi du stockage local de thread. Les deux appartiennent à cette catégorie de bogues qui se manifestent par un plantage mystérieux dans une application précise, sans qu'on puisse les attribuer.
L'état AVX était mal sauvegardé et restauré, ce qui provoquait des plantages sur des transitions d'état incorrectes. Si vous traînez un plantage inexpliqué dans une application riche en AVX, cette version mérite un test.
Côté JIT, il y a du travail pour le matériel doté de SVE 256 bits, une pile de correctifs sur des cas limites et de l'optimisation au niveau instruction. L'exemple cité est VMOVMASKPD et VMOVMASKPS, qui se compilent désormais en sept instructions au lieu de onze et dix. C'est le travail ordinaire et cumulatif d'un émulateur : personne ne remarque l'un de ces gains isolément, et ensemble ils expliquent pourquoi la version de cette année est plus rapide que celle de l'an dernier.
Une note de mise à jour qui piégera quelqu'un
FEXInterpreter n'existe plus. Déprécié depuis près d'un an, il est supprimé dans 2608.
Cela ne pose aucun problème si vous lancez FEX à la main. Cela en pose un si l'ancien nom est enfoui dans un enregistrement binfmt_misc, un script d'enrobage, une image de conteneur ou un job d'intégration continue, parce que l'échec arrivera plus tard, dans un contexte où le lien avec la mise à jour ne saute pas aux yeux. Le correctif est un renommage vers le binaire FEX plus récent. Le travail consiste à retrouver tous les endroits où vous l'aviez écrit.
Fouillez votre configuration avant la mise à jour, pas après. Cinq minutes maintenant, ou un après-midi confus plus tard.
Sources et pour aller plus loin
- Notes de version FEX 2608, FEX-Emu, 4 août 2026
- Version FEX-2608 sur GitHub
- FEX 2608 released with more fixes for running x86_64 binaries on ARM64, Phoronix, août 2026
- Le projet FEX
Questions fréquentes
Que fait exactement l'instruction WFE ?
WFE signifie Wait For Event, attendre un événement. C'est une instruction ARM qui place le cœur en état basse consommation jusqu'à ce que quelque chose le réveille : un autre cœur qui signale un événement, une interruption, ou le moniteur exclusif qui est libéré. L'usage classique est le verrou tournant. Au lieu d'une boucle serrée qui relit une adresse mémoire aussi vite que le cœur en est capable, la boucle lit une fois, exécute WFE et cesse toute activité jusqu'à ce qu'il y ait une raison de regarder à nouveau. Du point de vue du logiciel, l'attente est identique. Le coût énergétique, non. x86 dispose d'équivalents approximatifs avec PAUSE et, sur les puces récentes, avec le couple MONITOR et MWAIT, mais le binaire que FEX émule a été compilé pour x86 et ignore qu'il a atterri sur ARM.
Est-ce que mes jeux vont tourner plus vite ?
Sans doute pas en images par seconde, et le projet ne le prétend pas. Il s'agit d'un gain de consommation, pas de débit. Ce qui s'améliore, c'est ce que fait votre machine pendant qu'un thread attend, et sur un portable ou une console portable cela se traduit en autonomie et en chaleur plutôt qu'en performance. Un effet secondaire de débit reste possible sur du matériel limité thermiquement, parce qu'un cœur qui ne tourne pas à vide est un cœur qui ne produit pas la chaleur qui finit par imposer une baisse de fréquence ailleurs. Prenez cela comme un effet plausible, pas comme l'objectif.
Qu'est-ce que FEX et en quoi diffère-t-il des autres solutions x86 sur ARM ?
FEX est un émulateur libre, soutenu par Valve, qui exécute des binaires Linux x86 et x86_64 sur des hôtes ARM64. Son centre de gravité, ce sont les usages bureautiques et le jeu, ce qui explique la place de Wine et Proton dans chaque version : le cas courant est une machine Linux ARM qui fait tourner un jeu Windows via Proton, avec FEX en dessous pour traduire les instructions x86. D'autres projets existent dans ce domaine et font des compromis différents, notamment sur la part traduite à l'avance plutôt qu'à l'exécution et sur la fidélité au modèle mémoire x86. Si votre usage tient dans les jeux et les applications de bureau sur Linux ARM64, FEX est celui dont les notes de version méritent une lecture mensuelle.
J'utilise FEXInterpreter dans des scripts. Qu'est-ce qui casse ?
Le binaire FEXInterpreter disparaît dans 2608 après environ un an de dépréciation. Si vous avez des scripts d'enrobage, des unités systemd, des enregistrements binfmt_misc ou des jobs d'intégration continue qui l'appellent par son nom, ils échoueront après la mise à jour, et ils échoueront au moment de l'usage plutôt qu'à l'installation. Cherchez l'ancien nom dans votre configuration avant de mettre à jour, pas après. Le remplacement est le nom du binaire FEX plus récent, et la migration est un renommage, pas un changement de comportement : exactement le type de mise à jour qui est triviale quand on la prépare et pénible quand on l'ignore.
Le travail SVE 256 bits sert-il sur le matériel que je possède ?
Seulement si votre puce implémente SVE avec une longueur de vecteur de 256 bits, ce qui est loin d'être universel. Beaucoup de matériel ARM64 en circulation implémente SVE en 128 bits, où le chemin plus large n'est pas sollicité, et une partie n'implémente pas SVE du tout. Si ce travail compte pour le projet, c'est que AVX sur x86 est en 256 bits : un hôte doté d'une longueur de vecteur de 256 bits peut donc transposer ces opérations beaucoup plus directement au lieu de les découper. Pour savoir ce que vous avez, regardez la longueur de vecteur remontée par votre noyau plutôt que de la déduire du nom commercial du SoC.