L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
Une instruction atomique non alignée génère un SIGBUS sur Arm64 et le processus est terminé, où x86 exécute la même opération sans se plaindre, et c’est la raison au niveau de l’instruction pour laquelle certains jeux x86 traduits meurent carrément sur le matériel Arm. Un ingénieur d’Igalia a déclaré à la Linux Plumbers Conference du 5 octobre que la gestion des erreurs à l’intérieur du noyau est « plus de 5 fois plus rapide » que la façon dont l’émulateur FEX les piège actuellement dans l’espace utilisateur.
La conférence est répertoriée par la conférence comme « Émuler les atomes x86 sur arm64 », présentée par André Almeida d’Igalia dans un créneau de 30 minutes lors de la microconférence Gaming on Linux au Centre des congrès de Prague, et la motivation sur laquelle il ouvre est Steam Frame, qui place les jeux Windows x86 sur un appareil Linux Arm64. Le jeu de 19 diapositives est publié sur la page de contribution et a été lu à 21h02 UTC le 8 octobre.
Arm64 refuse une instruction x86 passe par
Les deux architectures permettent des instructions de mémoire simples sur des adresses non alignées, indique le document. La différence réside dans les instructions atomiques : « x86 autorise les instructions atomiques, contrairement à ARM64 », et « L’appel d’une instruction atomique non alignée dans ARM64 déclenche une exception SIGBUS ». Le résumé exprime clairement la partie gênante : « nous ne pouvons pas modifier leur code source pour éviter des opérations atomiques non alignées ».
L’émulation produit davantage de ces instructions plutôt que moins. x86 a un modèle de mémoire puissant et Arm64 un modèle faible, donc, selon les termes du jeu, « FEX utilise des instructions de synchronisation (barrières, LL/SC, atomiques) pour obtenir un ordre de mémoire plus fort. Cela crée beaucoup plus d’instructions « atomiques » que le code d’origine. «
FEX gère les retombées dans la même pile d’espace utilisateur qui place les jeux Windows sur Arm64 via Proton, piégeant le SIGBUS lui-même. « Tout ce changement de contexte est coûteux : nos travaux expérimentaux montrent qu’il est plus de 5 fois plus rapide de le faire directement côté noyau », indique le document. Il s’agit de la propre figure expérimentale d’Igalia et d’une comparaison de deux façons de gérer un défaut, pas une fréquence d’images ni un résultat de jeu.
Les serrures divisées sont un cas sans réponse claire
Le jeu pose la partie suivante sous forme de question et y répond en un mot : « Devinez quelle application utilise les verrous partagés ? Des jeux ! » Un verrou partagé est une opération atomique qui chevauche deux lignes de cache, ce que x86 autorise et pour lequel Arm64 n’a aucune instruction. Le matériel en paie le prix : « Le matériel émet une sorte de ‘verrouillage de bus’ qui bloque tout un cache », ce qui « ajoute de la latence à toutes les tâches non liées », et Linux propose une atténuation afin qu’il ne puisse pas être utilisé pour bloquer une machine.
Les propres extensions d’Arm ne comblent pas l’écart. Le document attribue à FEAT_LRCPC et à ses successeurs sur Armv8.3 et versions ultérieures leur aide à émuler l’ordre de la mémoire du x86, et note que « Apple Silicon a implémenté une émulation TSO complète sur le matériel », mais affirme que les extensions « ne peuvent pas résoudre un cas particulier : les verrous divisés ».
Il n’existe pas non plus de solution logicielle évidente. « Il n’y a pas de moyen simple de verrouiller deux lignes de cache », indique le deck, car « les instructions atomiques ne peuvent pas traverser une ligne de cache », et diviser une comparaison et un échange de 64 bits en deux de 32 bits permet à un autre thread de s’entrelacer. Le jeu fonctionne à travers les permutations et atterrit sur une valeur de retour qu’il étiquette « Résultat anormal, déchirure de la mémoire ».
La discussion se termine sur des questions, pas sur un patch
La diapositive de clôture est intitulée « Points de discussion » et demande s’il faut arrêter tous les autres processeurs pendant que l’un d’eux exécute la paire, s’il faut « avoir un verrou géant dans l’espace utilisateur ? et, catégoriquement, « La ligne principale devrait-elle prendre en charge ce type de cas d’utilisation ? » Rien dans le dossier ne prétend que le cas du verrouillage divisé est résolu, et la session a été réservée comme discussion.
Rien de tout cela n’indique qu’un jeu particulier échoue, et le deck n’en nomme aucun. Ce qu’il fournit, c’est la raison au niveau des instructions pour laquelle un jeu x86 traduit sur un casque Arm64 peut mourir plutôt que de simplement fonctionner lentement. Lorsqu’un développeur s’est donné la peine d’une version native, comme Wube l’a fait pour FactorioDans la version Arm64 de, toute la question disparaît.