dolphin/docs/Wii_LLE_Update_P1_Trace_2026-09-23.md

Wii IOS LLE : première trace CPU native de mise à jour

Date : 2026-09-23 (Europe/Paris). Cible : atteindre à terme environ 60 FPS pendant une mise à jour système, sans raccourci HLE ni régression BootMii/HBC. Ce document rapporte une mesure exploratoire, pas un gain de performance.

Périmètre et qualité

• NAND : copie isolée .starlet_update_ab_20260913/P1-trace-002, créée depuis le journal pré-mise-à-jour vérifié (31 fichiers, SHA du seed 07B2F4BC543CFD4203EFC448538505E9D503B2727C16AAFF8D8C0B286D8B4F0C). .starlet_user3 et les anciens essais A–F n'ont pas été modifiés.
• Build diagnostic figée : .starlet_update_ab_20260913/build-P1-trace-002 ; exécutable SHA-256 D809E04E2E8E900DB06D3813A67805E66EADB2BB79924CB8E805CB724360EAD4.
• ETL source : .starlet-profile/P1-native-update-001/capture.etl (3,88 Gio), session WPR de 600 s. Le champ EndUTC du manifest inclut environ 100 s de fusion de la trace : ce n'est pas la fin de la collecte.
• Analyse : .starlet-profile/P1-native-update-001-update-window/, Xperf limité à 2026-09-22 22:57:00–23:00:33 UTC. Les échantillons cibles couvrent en fait 114,15 s seulement, jusqu'à l'arrêt de la collecte vers 22:58:52 UTC. Les premières écritures NAND de mise à jour sont observées vers 22:57:23 UTC. La fenêtre CPU comprend donc aussi environ 23 s avant cette première écriture. La fin de la mise à jour, confirmée par l'utilisateur, n'est donc pas profilée.
• TDH : 780 781 événements natifs décodés, zéro perte de buffer/événement et zéro erreur de décodage. Fusion Xperf : 25 419 ancres QPC, erreur maximale cinq ticks (QPC 10 MHz), 128 329 échantillons CPU sur 18 threads, 549 607 changements de contexte retenus, zéro événement cible invalide. Les 57 événements Xperf invalides sont hors PID cible.
• Le surcoût du collecteur WPR en mise à jour native n'est pas qualifié par le lot synthétique précédent ; ces FPS ne constituent pas un A/B sans trace.

Observations dans la fenêtre CPU retenue

Mesure	Valeur
Images « produced », intervalle médian	21,16 ms (≈47,3 FPS)
Images « produced », p95	35,33 ms (≈28,3 FPS)
Images « produced », p99	68,58 ms (≈14,6 FPS)
Thread principal TID 28212	95 154 / 128 329 échantillons (74,2 %)
Thread GPU TID 13804	16 125 / 128 329 (12,6 %)
Thread audio TID 22388	5 095 / 128 329 (4,0 %)
JIT ARM / JIT PPC, échantillons de feuilles	27 817 / 16 450
Instructions ARM, delta de snapshots	4 566 790 374
Instructions ARM JIT natives, delta	4 522 113 258
Accès lents JIT lecture / écriture, deltas	59 486 963 / 218 257 365
Fallbacks ARM, delta	42 433 964

Les symboles hôte les plus visibles sur le thread principal comprennent StarletMemory::Read32 (3 246 échantillons), ARMCore::TranslateVirtualAddress (2 909), StarletMemory::Write32 (2 613), PowerPC::MMU::WriteToHardware (2 420) et StarletMemory::CalculateNANDECC (1 918). Ce sont des feuilles : leur somme ne décrit pas une pile ni un chemin critique. Le thread GPU occupe aussi du CPU, mais il ne domine pas ce relevé. Les 218 millions d'écritures lentes JIT sont un compteur d'appels, pas 218 millions d'accès NAND.

Les compteurs de scopes échantillonnés distinguent NAND, journal, NAT, DMA, ARM/JIT et périphériques, avec zéro erreur de comptabilité. Ils mesurent du temps mur de tranches sélectionnées 1/1024, pas une durée CPU exhaustive ; ils ne justifient donc pas d'affirmer qu'un autre poste est nul. Les événements Frame et Snapshot natifs couvrent toute la session alors que les échantillons CPU Xperf sont filtrés ; les chiffres de FPS ci-dessus viennent de cpu-threads-phase2.json, qui borne les deux à la même fenêtre QPC.

Décision

La première minute de mise à jour est surtout limitée par le thread principal d'émulation, mais aucun helper unique mesuré ne démontre à lui seul les ~21 % de réduction de temps par image nécessaires pour passer de la médiane observée à 60 FPS. Un simple gain de microbenchmark ECC ou TLB ne doit pas être présenté comme un correctif 60 FPS. Les écritures lentes sont le candidat à qualifier : le fast path direct SRAM écrit avait déjà régressé BootMii, donc élargir son masque sans savoir quelles adresses dominent serait risqué.

Prochain essai borné : la nouvelle copie initiale P1-trace-003 est préparée et vérifiée. Activer -ProfileJitMemory dans cette copie seulement et relever dans dolphin.log les compteurs RAM/SRAM/MMIO et les adresses les plus fréquentes pendant le même début de mise à jour. Ce mode ajoute du coût et ne sert qu'à classer les adresses, pas à comparer ses FPS à la présente trace. Ensuite seulement, choisir une optimisation limitée à une famille d'adresses, ajouter des tests de fidélité BootMii/HBC/NAND et réaliser un A/B sans instrumentation sur deux NAND identiques. L'objectif de 60 FPS reste ouvert.

Le lancement du relevé ciblé est manuel depuis un PowerShell interactif, car une instance créée par l'outil de commande de l'agent s'est retrouvée invisible sur le bureau utilisateur :

cd C:\Users\tpetkovic\Desktop\dolphin
.\Run-Wii-IOS-LLE.ps1 `
  -BuildDirectory .starlet_update_ab_20260913/build-P1-trace-003 `
  -UserDirectory .starlet_update_ab_20260913/P1-trace-003 `
  -Ethernet -ProfileJitMemory

Fichiers de résultat locaux : decoder-summary.json, xperf-summary.json, native-report.json, cpu-threads-phase2.json dans le répertoire d'analyse indiqué ci-dessus. Un export Xperf complet, interrompu car disproportionné, a été supprimé ; l'ETL source et l'export ciblé sont conservés.

Relevé ciblé P1-trace-003 : écritures SRAM

La copie isolée P1-trace-003 a été démarrée avec -ProfileJitMemory. La mise à jour est allée jusqu'au redémarrage/menu Wii (confirmé par l'utilisateur). Le journal a cessé de croître à 2 763 867 232 octets. L'analyse en lecture seule valide ses 651 690 transactions et 165 568 pages finales superposées. Le SYSCONF est valide ; les 9 contenus du menu v514 et les 15 d'IOS80 v6944 correspondent à leurs empreintes TMD. SHA-256 du journal : 49b19327a9b0d7c3aa08c4d59e81365aa17b82ef7452939c07281cbd499b5b56. Cela ne constitue pas une vérification exhaustive de tous les titres.

Entre les snapshots JIT de 11:57:06.905 (début des écritures de mise à jour) et 12:07:12.622 (fin des écritures), soit environ 606 s de temps mur :

Compteur d'accès ARM lents	Delta
SRAM	1 024 033 027 (78,74 % des accès classés)
MMIO	255 829 918
Autres	20 598 539
RAM	0
Lectures, toutes régions	292 651 794
Écritures, toutes régions	1 007 809 690
Écritures SRAM	971 531 207 (96,4 % des écritures lentes)

Les pages d'aperture SRAM 0x00 et 0x19 portent respectivement 556 332 042 et 348 178 857 écritures lentes, soit 93,1 % des écritures SRAM de cette fenêtre. L'alias bas n'augmente pas : ce trafic passe par l'alias haut. Les adresses qui reviennent le plus dans l'échantillonnage 1/256 sont notamment 0xffff97a0 et 0xfffe03c0 en écriture ; les lectures MMIO comprennent 0x0d800038 et 0x0d80003c. Le classement par page est exact dans les compteurs, tandis que les adresses individuelles ne sont que des échantillons (huit adresses au maximum par snapshot).

Conséquence : les écritures SRAM sont un candidat ciblé, pas un gain de FPS déjà établi. Ce run est instrumenté et ne doit pas être comparé en vitesse au run natif P1-trace-002. Le JIT conserve volontairement les écritures SRAM sur le bus exact : une ancienne écriture directe, même limitée aux pages 0x00/0x19, avait bloqué BootMii à son initialisation matérielle. Avant de réintroduire un fast path, il faut expliquer cette divergence et vérifier boot0/split/alias/endianness ainsi que le cycle BootMii → menu → HBC. Ensuite, seul un A/B non instrumenté sur deux copies identiques peut qualifier le gain sur la mise à jour réelle et la cible de 60 FPS.

Essai SRAM ciblé : rejeté après A/B natif

Un candidat a court-circuité le bus dans le helper JIT uniquement pour les stores alignés de 32 bits sur les pages SRAM hautes 0x00 et 0x19, avec gardes boot0/split et chemin bus conservé ailleurs. Le test dédié des gardes et 153 tests Starlet* ont passé. BootMii puis Wii ont démarré dans le profil isolé P1-trace-004. HBC est absent de cette NAND ; ce trajet n'a pas été testé. Le binaire candidat figé (SHA-256 B5F3C3BA1D6EE2C86E5A3EB685F3B3D5FCEF2674C51EA137B697903F9E210006) reste dans build-P1-trace-005 pour reproduire l'essai, mais le raccourci a été retiré du source courant après les mesures ci-dessous.

P1-trace-005 (candidat) et P1-trace-006 (témoin, exécutable SHA-256 D809E04E2E8E900DB06D3813A67805E66EADB2BB79924CB8E805CB724360EAD4) partaient des mêmes 31 fichiers, d'un journal vérifié de 533 705 344 octets et de la même configuration, hormis les chemins isolés. Le profilage détaillé était désactivé dans les deux builds. Une mesure hôte légère a relevé toutes les 10 s la taille du journal et le temps CPU du processus, sans lire la mémoire invitée ni injecter d'entrée. Les durées ci-dessous interpolent les franchissements des mêmes seuils de 600 Mo et 2,7 Go ; l'incertitude temporelle reste de l'ordre de l'intervalle d'échantillonnage.

Mesure 600 Mo → 2,7 Go	Candidat	Témoin
Temps mur interpolé	434,7 s	402,4 s
Temps CPU du processus	501,5 s	459,8 s
Journal final	2 763 867 232 octets	2 733 507 520 octets

Les deux mises à jour ont abouti et les journaux passent la vérification complète des transactions. Le SYSCONF est valide ; le menu v514 et IOS80 v6944 ont respectivement leurs 9 et 15 contenus cohérents avec les TMD. L'utilisateur a aussi trouvé le témoin plus fluide. Aucun flux FPS précis n'a été enregistré pour cet A/B. C'est un seul passage par variante, avec une taille finale de journal légèrement différente : il ne démontre pas la taille exacte d'une régression, mais ne montre aucun gain. Le nombre d'accès SRAM n'était donc pas, à lui seul, une justification suffisante pour ce raccourci. Ne pas le promouvoir. Les captures brutes restent dans P1-trace-005/Capture et P1-trace-006/Capture pour réanalyse.