12 KiB
12 KiB
Fiche PIPE1-REVUE-02 (modèle v2) — Niveau N3 — Modèle prévu opus xhigh | utilisé claude-opus-5-5 — Session Medium-xHigh · PIPE1
PIPE1-REVUE-02-MODELE : barème de mesure v2, en grille, prêt à adopter (2026-10-15)
Demande de l'utilisateur à cette session : « retravaille le modèle et envoie le à Big Boss ». Ce fichier remplace le
§ 4 de PIPE1-REVUE-02.md. Les faits F1 à F13 de cette revue restent valables ; F14 et l'état de M4 sont corrigés
ici (F15 à F18). Statut : proposition, non approuvée ; aucun skill modifié ; rien n'a été lancé.
0. Principe
Plus de score. La fiche lit une cellule d'une grille question × enjeu, qui donne les paliers. L'exigence donne le nombre de passes. Le reste se déduit : parties jouées, budget, épreuves préalables. Les paliers reprennent le système de mesure déjà en place dans le projet (doc 18 : scénario O0, sessions A et C ; doc 11 § 12 : export Insights sans interface) au lieu d'en inventer un.
1. Faits nouveaux depuis la revue (établis)
| # | Fait | Preuve | Effet |
|---|---|---|---|
| F15 | Le projet a une base chiffrée et des critères : scénario O0 (environ 15 min) ; référence O0 (build 5.5 L7cdj, 36 004 images) : médiane 16,7 ms, 159 images > 50 ms, 112 > 100 ms ; critère de la Session C : médiane ≤ 17 ms (± 1) ou écart expliqué | Docs\18_Build_Debug.md:40-41, :86-87, :128 |
F14 nuancé : aucun seuil standard d'Epic, mais des critères du projet, établis en 5.5. La première épreuve de M1 en 5.8 donne la base O0-5.8 |
| F16 | La Session C a tourné en 5.5 (Dbg-I6 : 9 000 images, médiane 16,66 ms) ; elle se joue sans -LPHitchLog |
18_Build_Debug.md:128, :197-207 |
les à-coups de M1 se lisent dans le CSV (images > 50 et > 100 ms), pas dans LPDebug hitch |
| F17 | Export d'une trace Insights sans interface éprouvé en 5.5 (lot O9) : UnrealInsights.exe -OpenTraceFile=… -AutoQuit -NoUI -ExecOnAnalysisCompleteCmd="@=export.rsp" avec TimingInsights.ExportTimerStatistics … -threads=GameThread. Pièges : chemins avec / ; une trace de 10 min (3,3 Go) demande plus de 50 Go de mémoire à l'analyse |
Docs\11_Audit_Optimisation.md:276-281 |
M4 est lisible par script ou par agent (en 5.5) : à rééprouver en 5.8, avec des traces de 4 min au plus (841 Mo pour 4 min) |
| F18 | Session A : build DebugGame dans le tableau des lanceurs ; la trace G6 a été faite en Development, canaux cpu,frame,bookmark,loadtime, sans memory |
18_Build_Debug.md:45, :222-233 |
M4 : DebugGame ou Development, sans le canal memory |
2. Paliers (outils du projet)
| Palier | Recette | Build | Répond à | Passe jouée | État en 5.8 |
|---|---|---|---|---|---|
| M0 | Tools\LogStats.ps1 -Compare <A>,<B> -Stats sur LifePlay.log |
Development | compteurs du jeu : F5, DESTROY ; à-coups ≥ 50 ms seulement si la partie a été lancée avec -LPHitchLog |
scénario O0 ; peut être la passe de M1 (compteurs seulement) | en service |
| M1 | lanceur Session C : -csvGpuStats -llm -llmcsv -ExecCmds="csvprofile repeat=20, csvprofile frames=9000", sans -LPHitchLog, jamais -csvCaptureFrames ; puis Tools\SummarizeDebugCsv.ps1 ; PerfReportTool en option |
Development | cadence instrumentée (médiane, images > 50 et > 100 ms), coût par fil (GT, RT, GPU), mémoire LLM | scénario O0, environ 15 min | éprouvé en 5.5 (Dbg-I6) ; à rééprouver en 5.8, ce qui donne la base O0-5.8 |
| M2 | trace ETW hors ligne (wpr ou logman, fournisseurs relevés dans le source de PresentMon 2.6.0), puis PresentMon --etl_file |
Shipping | cadence ressentie par le joueur | scénario O0 ou extrait nommé ; session élevée | jamais essayé (fiche B2-ter) ; peut échouer comme la capture en direct |
| M3 | journal de performance d'AMD Adrenalin | toutes | cadence (grain à relever) | activation par l'utilisateur | format inconnu |
| M4 | lanceur Session A, canaux cpu,frame,bookmark,loadtime (gpu si besoin, sans memory), -statnamedevents ; trace de 4 min au plus ; export par UnrealInsights.exe -NoUI -AutoQuit -ExecOnAnalysisCompleteCmd (TimingInsights.ExportTimerStatistics) |
DebugGame ou Development | quelle fonction, quel Blueprint | passe courte, à part : la trace fausse la cadence | éprouvé en 5.5 (O9, G6) ; à rééprouver en 5.8 |
Hors grille : Gauntlet (rejouer M1 sans humain, Development seulement, éditeur hôte requis, R11-17 et R11-18) ; Session B (fuites, mémoire physique) ; Tracy abandonné ; FPS chart retiré (redondant avec M1, F3).
3. Entrées de la fiche (trois)
| Q. Question | Sens |
|---|---|
| Q0 | compteurs du jeu : rien n'a cassé ni régressé (F5, DESTROY, gros à-coups) |
| Q1 | cadence de la build instrumentée (médiane, images longues) |
| Q2 | cadence ressentie par le joueur (Shipping) |
| Q3 | quel fil coûte (GT, RT, GPU), ou quelle catégorie de mémoire |
| Q4 | quelle fonction, quel Blueprint |
| E. Enjeu | Sens |
|---|---|
| E0 | contrôle, aucune décision |
| E1 | changement réversible, sans gain revendiqué (nettoyage, réglage) |
| E2 | gain de performance revendiqué (Blueprint, C++) |
| E3 | rendu, plateforme ou peu réversible (SM6, Lumen) |
| X. Exigence | Sens | Passes |
|---|---|---|
| X0 | constat (oui ou non) | 1 |
| X1 | médiane ou moyenne | 1 par côté |
| X2 | distribution : médiane, p95, p99, images longues | 3 par côté, valeur provisoire recalée sur la dispersion mesurée à l'épreuve de M1 |
Le doute (D) ne se note pas à la demande : il sert à la règle R3, après un résultat.
4. Grille question × enjeu (lire une seule cellule)
| Q \ E | E0 contrôle | E1 réversible sans gain | E2 gain revendiqué | E3 rendu, plateforme (★) |
|---|---|---|---|---|
| Q0 compteurs | M0 | M0 | M1 + M0 | M1 + M0 + M2 |
| Q1 cadence instrumentée | M1 | M1 + M0 | M1 + M0 | M1 + M0 + M2 |
| Q2 cadence Shipping | M2 | M2 + M0 | M2 + M1 + M0 | M2 + M1 + M0 |
| Q3 quel fil, mémoire | M1 | M1 + M0 | M1 + M0 | M1 + M0 + M2 |
| Q4 quelle fonction | M4 | M4 + M0 | M4 + M1 + M0 | M4 + M1 + M0 + M2 |
★ E3 : décision explicite de l'utilisateur avant lancement, et session sans plantage GPU exigée en plus (ERR-138). Construction de la grille : base de Q (Q0 → M0, Q1 → M1, Q2 → M2, Q3 → M1, Q4 → M4), plus le plancher de E (E1 → M0 ; E2 → M1 + M0 ; E3 → M1 + M0 + M2). « M1 + M0 » est une seule passe Session C : M0 y lit les compteurs du journal, et les à-coups viennent du CSV (F16).
5. Ce qui se déduit de la cellule
5.1 Parties jouées (coût humain)
Parties = passes (X) × côtés (2 en A/B, 1 en constat), par build :
- Development : M0 et M1 partagent la passe ;
- Shipping : M2 et M3 demandent leurs propres passes ;
- M4 : une passe courte par côté, à part.
5.2 Budget en jetons (estimé)
| Palier | Rodé, lancé par la session (par A/B) | Épreuve en 5.8 (une fois, fiche à part) |
|---|---|---|
| M0 | ≤ 5 k | — (en service) |
| M1 | ≤ 15 k | 80 à 120 k ; donne la base O0-5.8 et la dispersion du poste |
| M2 | ≤ 10 k | 90 à 140 k (fiche B2-ter) |
| M3 | ≤ 10 k | 60 à 90 k |
| M4 | ≤ 25 k (export limité à un fil, 30 lignes lues) | 60 à 90 k (recette 5.5 connue) |
- Budget de la fiche = somme des paliers de la cellule (colonne « rodé »). Les épreuves restent hors du budget de la fiche.
- Un agent ajoute environ 60 k : on n'en lance un que si le script manque ou échoue. Base : 55 à 140 k par agent neuf (chiffre de Big Boss). Un budget rodé ne contient donc aucun agent.
- Au-delà de 120 k : décision explicite de l'utilisateur.
- Recalage après 3 fiches par palier, d'après
Tools\FicheStats.py.
5.3 Notation dans la fiche (vérifiée par Big Boss au BUILD-GO)
Mesure : Q3 E2 X2 → M1 + M0 ; 6 parties Session C ; budget 20 k ; épreuve M1 requise (fiche à part)
6. Règles
- R1. Rien sous la cellule. Un palier de la cellule ne s'omet qu'avec l'accord de Big Boss, consigné dans la fiche.
- R2. Réutiliser. Un résultat déjà acquis sur la même build, le même scénario et dans les mêmes conditions ne se refait pas. Exemple : le M1 de G3 sert à l'à-coup qui suit.
- R3. Montée par le doute, après un résultat, d'un cran.
- Transitions : M0 → M1 ; M1 → M4 (du fil à la fonction) ; M1 ↔ M2 (instrumentée contre Shipping).
- Deux montées au plus par demande, puis retour à l'utilisateur.
- R4. Repli.
- M2 indisponible → M3.
- Les deux indisponibles → « cadence Shipping non mesurable », consigné, décision de l'utilisateur.
- M4 ne remplace jamais une mesure de cadence.
- R5. A/B honnête.
- Mêmes conditions : même build hors changement, scénario O0 (ou extrait nommé), mêmes conditions de poste (secteur, plan d'alimentation), X passes par côté.
- Un chiffre Development n'est jamais présenté comme un chiffre Shipping.
- Les options de la Session C (
-llm,-csvGpuStats) gonflent les valeurs absolues : valables en A/B, pas comme chiffre du joueur (estimé).
- R6. Épreuve d'abord. Un palier non éprouvé en 5.8 l'est par une fiche à part, recette seule. Ordre proposé : M1 (base O0-5.8), M4, M2, M3.
- R7. Sortie fixe. Chaque passe rend une ligne :
palier | build | passe n/N | côté | médiane | > 50 ms | > 100 ms | GT | verdict | chemin. La session ne lit ni CSV brut ni journal entier. - R8. Seuils.
- Ils viennent des critères du projet (doc 18:128), rebasés sur O0-5.8 après l'épreuve de M1.
- Aucun seuil n'est inventé dans une fiche.
7. Exemples (grille OPT0-A3-GRILLE.md § 4)
| Demande | Q | E | X | Cellule | Parties | Budget rodé | Épreuves préalables |
|---|---|---|---|---|---|---|---|
| G2 nettoyage U9 : rien n'a régressé ? | Q0 | E1 | X1 | M0 | 2 | ≤ 5 k | aucune |
| G3 Ticks de Person | Q3 | E2 | X2 | M1 + M0 | 6 | ≤ 20 k | M1 |
| G4 AnimBP thread-safe | Q3 | E2 | X2 | M1 + M0 | 6 | ≤ 20 k | M1 |
| G6 SM6 / DX12 | Q2 | E3 | X2 | M2 + M1 + M0, session sans plantage, décision ★ | 12 (6 Development, 6 Shipping) | ≤ 30 k | M1, M2 (ou M3) |
| à-coup inexpliqué après G3 | Q4 | E2 | X1 | M4, avec le M1 + M0 de G3 réutilisé (R2) | 2 passes courtes | ≤ 25 k | M4 |
| « Quel Blueprint coûte au menu ? » | Q4 | E0 | X0 | M4 | 1 passe courte | ≤ 25 k | M4 |
Avec l'ancien score, G3 et G4 payaient M2 sans motif, G6 sortait à M1 + M2 sans plancher, et la dernière demande tombait en M1, qui ne descend pas à la fonction.
8. Points à trancher par l'utilisateur
- U1. La grille question × enjeu remplace-t-elle le score additif ? (Recommandé.)
- U2. La build Development est-elle la seule build instrumentée ? Test n'est pas disponible avec le moteur du lanceur (F2). (Recommandé.)
- U3. Ordre d'épreuve M1, M4, M2, M3 ? (Recommandé : M1 donne la base O0-5.8 dont G3, G4 et G6 ont besoin.)
- U4. Écrire un script enveloppe pour M1 et pour M4 (sortie R7) ? C'est la condition des budgets rodés.
- U5. X2 à 3 passes par côté, soit 6 parties jouées pour G3, à titre provisoire ? Ou X1 jusqu'à la mesure de la dispersion ?
- U6. Une même passe sert-elle à M0 et à M1, avec les compteurs lus dans le journal et les à-coups lus dans le CSV,
sans
-LPHitchLog?
9. Limites
- Estimé :
- les budgets et N = 3 ;
- la présence des compteurs F5 et DESTROY dans le journal d'une passe Session C (DESTROY ne vient ni du C++ du jeu ni de celui de l'addon, grep nul : il vient probablement des Blueprints) ;
- la tenue de l'export Insights en 5.8 ;
- l'effet de
-llmet-csvGpuStatssur les valeurs absolues.
- Non vérifié : le refus d'UBT en configuration Test (F2) ; le motif écrit de « sans
-LPHitchLog» pour la Session C (seul le résultat est relevé : le journal d'à-coups éteint ne déplace pas la médiane,18_Build_Debug.md:216-218).