Yaya48
c230971f07
Preserve formatted NAND boot and Wii Remote pairing, add DMA/SRAM conformance tests and a Wii comparison probe. Keep P1 profiling tools and native update A/B evidence; reject the unhelpful targeted SRAM shortcut.
183 lines
10 KiB
Markdown
183 lines
10 KiB
Markdown
# 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 :
|
||
|
||
```powershell
|
||
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.
|