edujiro5972/LifePlay-Revival
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LifePlay-Revival/Docs/Migration/etat/ST/STG/STG-COMMUN13-GPU-DIAG.md
edujiro5972 8084622450 LifePlay UE 5.8 : état de développement au 2026-10-19 
Tickets : REP1-T4

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-19 22:57:42 +02:00

11 KiB
Raw Blame History

Fiche STG-COMMUN13-GPU-DIAG — Niveau N3 — Modèle prévu claude-opus-5-5 | utilisé claude-opus-5-5 — Agent orchestrateur STG (session principale) — Skills lp-lot, sk-protocol

STG-COMMUN13-GPU-DIAG : plantage GPU de l'essai COMMUN-13 (14:21:45 UTC, 2026-10-14)

DIAG en lecture seule demandé par Big Boss, sans jeton UE, sans écriture hors de ce livrable.

Sources :

  • journal de l'essai D:\Game\LifePlay_Backup_5.5\COMMUN-13\essais\commun13_LifePlay.log (MD5 d99efd4b4f6d9a2c449d1afdf7c12135, 17 963 lignes) ;
  • rapport …\COMMUN-13\essais\Crashes\UECC-Windows-ADBF65FE4C1D06399ACA8880B07C3684_0000\ ;
  • journaux des essais COMMUN-10 à COMMUN-12 ;
  • journal Système de Windows (lecture Get-WinEvent).

1. Ce qui s'est passé (établi)

  • Plantage : à 14:21:45.329 UTC, LogD3D12RHI: Error: GPU crash detected: Device 0 Removed: DXGI_ERROR_DEVICE_RESET (l. 17611).
    • Aucun diagnostic de shader sur les files 3D, Copy et Compute.
    • DRED: No breadcrumb head found, No PageFault data : aucune faute d'adresse GPU n'a été enregistrée.
    • Mémoire vidéo : 1 941 Mo utilisés sur un budget de 7 379 Mo. Mémoire du processus : 1 222 Mo.
    • Le jeu se ferme ensuite par D3D12Util.TerminateOnGPUCrash.
  • Pass actif au moment de la perte, pile Graphics, Frame 95931 : SceneRender - ViewFamilies → Scene → PostProcessing → Histogram (exposition automatique de la vue principale).
    • Les étapes précédentes sont terminées (Translucency, ComposeTranslucency, TAA).
    • La pile AsyncCompute est au même point : RenderGraphExecute - Slate → SubmitBufferUploads.
    • FaceCapture, SecondScreen et le rendu Slate de l'interface sont tous [Not Started] : ils appartiennent à la Frame 95932, qui n'avait pas commencé. Le GPU s'est arrêté dans un pass du moteur, sur la vue principale.
  • État du jeu (relevé de 14:21:42, 3 s avant) :
    • le joueur est dans la pièce Room_C_0 (intérieur, échelle 8 × 8 × 0,2), sur le sol (delta -0.2), en C2, meshZ -90 ;
    • les 12 PNJ sont cachés sous la carte (MapMarkers…Plane), ce qui est normal en intérieur ;
    • sexOn=0 sceneOn=0, aucun menu.
    • CurrentScene=pinhole_camera_cms.lpscene n'est que le nom de la dernière scène chargée par le GI (14:09:03). Ce n'est pas une scène en cours (sceneOn=0) ni un rendu particulier.
  • Ce qui précède le plantage :
    • de 14:09:16 à 14:21:38, le jeu est immobile : seules les lignes périodiques (« Temoin C2 » toutes les 7,5 s, relevés de personnes) apparaissent, sans aucune autre action ;
    • à 14:21:40.089, un hitch de 213 ms (#56, le plus long depuis le chargement), 5 s avant la perte du périphérique, sans événement de jeu ;
    • dernière scène de sexe terminée à 14:06:05 (« fin de scene, etats rendus », B2p-J), soit 15 min 40 s avant.
    • La dernière « souris liberee » (B2p-J) date de 14:05:56.
  • Historique : aucune ligne GPU crash, DEVICE_REMOVED, DEVICE_RESET ni DEVICE_HUNG dans les journaux d'essai COMMUN-10, COMMUN-11 et COMMUN-12. Ces essais ont duré de 21 à 27 min, contre 27 min pour COMMUN-13.

2. Contenu du rapport (établi)

Fichier Contenu
CrashContext.runtime-xml (53 540 o) CrashType=GPUCrash, ErrorMessage=GPU Crash dump Triggered, Source=RHI, EngineVersion=5.8.3-58210709, BuildConfiguration=Development, SecondsSinceStart=1610, exe de LifePlay_Build_5.8_COMMUN-13_Development. Fil marqué IsCrashed=true : RHIInterruptThread, le fil qui constate la perte du périphérique ; ce n'est pas lui qui l'a provoquée. Piles : uniquement ntdll et win32u (attentes), aucune trame de LifePlay ni du moteur, ce qui est normal pour un plantage GPU.
UEMinidump.dmp (1,3 Mo) Minidump des fils CPU au moment du constat ; les piles sont celles du XML. Il n'est pas exploitable sans les symboles (PDB), et il ne contient pas l'état du GPU.
Breadcrumbs_RHIThread_0.txt EndDrawingViewport, Frame 95932 : le fil RHI préparait déjà l'image suivante.
LifePlay.log Copie du journal (identique au journal d'essai à 1 755 o près, la fin du constat).
CrashReportClient.ini Réglages du client de rapport (CrashReportClient-Win64-Debug.exe est introuvable dans l'archive : le rapport n'a pas été envoyé, ce qui est sans conséquence).

Matériel (journal l. 284, 627-643) :

  • portable AMD Ryzen 7 5800H, graphique hybride : adaptateur 0 AMD Radeon RX 6600M (8 Go), pilote Adrenalin 26.8.1 (32.0.21045.5002, daté du 17-08-2026), choisi par le jeu ; adaptateur 1, Radeon intégré, pilote 25.8.1 ;
  • Windows 11 26H2 (10.0.26300) ;
  • D3D12, SM5. 64 Go de RAM, dont 39,9 Go occupés par l'ensemble du système au moment du plantage.

Journal Système de Windows :

  • entre 16:15 et 16:26, heure locale, une seule entrée : Win32k 267, à 16:21:46 (contrôle du matériel tactile, sans rapport) ;
  • aucune entrée 4101 (« le pilote d'affichage a cessé de répondre et a récupéré »), ni ce jour-là ni avant : aucun TDR n'a été consigné par Windows ;
  • C:\Windows\LiveKernelReports n'est pas lisible sans droits d'administrateur : non vérifié.

Activité UE simultanée : aucun journal de la copie 5.8 n'a été écrit entre 15:44 et 16:26 locales. Le build REL-ALPHA démarre à 16:26:04, après le plantage (16:21:45 locales). Aucune compilation ni cuisson ne tournait sur le GPU en même temps (établi pour D:\Game).

3. Réponses

3.1 Cause du jeu ou cause extérieure ? Estimé : extérieure (pilote ou matériel), pas le code du jeu

Éléments contre une cause du jeu :

  1. Le pass actif est Histogram (exposition automatique) sur la vue principale. C'est un pass de calcul du moteur, petit et identique à chaque image. Aucun code LifePlay n'y intervient.
    • FaceCapture et SecondScreen (LPSecondScreenSubsystem, inchangé depuis le 2026-10-01, commit ed4bc46, présent dans tous les builds) n'avaient pas commencé leur rendu de l'image en cours.
    • Le rendu Slate (l'icône d'aide de B2p-I) non plus.
  2. Le jeu était immobile depuis 12 min : même pièce, même caméra C2 à 100 cm, aucune scène, aucun sexe, aucune entrée. La même image avait été rendue environ 40 000 fois sans incident (estimé : 95 931 images en 1 610 s, soit environ 60 images/s). Un défaut de contenu (shader, ressource, capture) se déclenche d'ordinaire à un changement.
  3. Le code nouveau de COMMUN-13 (CAM B2p-I, B2p-J) n'était pas actif.
    • B2p-J : souris libérée et fin de scène ne s'exécutent qu'en scène de sexe (dernière à 14:06).
    • B2p-I : icône d'aide (un widget Slate, une image) ; le pass Slate n'avait pas commencé.
    • Les changements STG (M-Z, S-F5p, B2q-b1) ne touchent que des positions et des bornes, sur le fil de jeu. Les relevés montrent meshZ -90 et des bornes stables.
  4. Aucune PageFault DRED et aucun diagnostic de shader : pas d'accès hors limites constaté. Une erreur de l'application, comme une ressource détruite en cours d'usage, laisse d'ordinaire une PageFault.
  5. DXGI_ERROR_DEVICE_RESET, et non DXGI_ERROR_DEVICE_HUNG.
    • HUNG désigne d'ordinaire des commandes de l'application que le GPU n'a pas pu finir (TDR imputable au jeu).
    • RESET désigne un périphérique réinitialisé ou perdu pendant l'exécution : pilote, réinitialisation demandée par un autre processus, gestion d'énergie, bascule hybride.
    • Estimé d'après la documentation DXGI ; les pilotes ne respectent pas toujours cette distinction.
  6. Hitch de 213 ms, 5 s avant, sans événement de jeu : le GPU (ou le pilote) commençait à ne plus répondre.

Éléments pour une cause du jeu (ce qu'on ne peut pas exclure) :

  • DRED n'était pas actif (No breadcrumb head found) : on ne voit que les marqueurs du moteur, pas les commandes GPU exactes.
  • Le constat porte sur un seul plantage ; le hasard d'un essai ne prouve rien.
  • 27 min, c'est aussi la durée d'une fuite lente. Mais la VRAM est à 1,9 Go sur 7,4 et le processus à 1,2 Go : pas de fuite visible.

Les pistes nommées par Big Boss :

  • FaceCapture et SecondScreen : non, ils n'avaient pas commencé l'image en cours (établi) ;
  • scène pinhole_camera : non, elle n'est pas en cours (établi) ;
  • CameraMode B2p-J et la souris libérée : non actifs depuis 15 min (établi) ;
  • pilote ou TDR : probable (estimé), mais aucun TDR consigné par Windows (établi).

3.2 Contenu du rapport

Voir le § 2. Rien dans le rapport ne désigne le code du jeu. Le minidump ne donne que les fils CPU en attente.

3.3 Risque pour le Shipping de l'alpha et essai qui le ferait apparaître

Risque (estimé) : faible pour le code, réel pour la machine.

  • Le Shipping utilise le même rendu ; s'il s'agit du pilote ou du matériel, il peut planter de la même façon, sans lien avec un correctif.
  • Un plantage GPU en Shipping se termine de même (TerminateOnGPUCrash), sans sauvegarde automatique : une partie non sauvegardée est perdue. C'est le seul effet pour le joueur.
  • Les autres machines ne sont pas touchées par un défaut propre à cet ordinateur.

Essais proposés (sur ordre, rien n'est lancé) :

  1. Reproduire avec diagnostic GPU : relancer l'archive COMMUN-13 avec les mêmes arguments plus -gpucrashdebugging (DRED et marqueurs détaillés), dans la même pièce, immobile en C2, 45 min :
    • si le plantage revient, le journal donnera le pass et la ressource exacts, avec une éventuelle PageFault ;
    • s'il ne revient pas en 45 min, cela plaide pour un incident isolé.
  2. Comparaison A/B : même scénario avec l'archive COMMUN-12 (sans B2p-I ni B2p-J). Un plantage sur les deux exclut le code de COMMUN-13.
  3. Côté machine, par l'utilisateur :
    • vérifier que le jeu tourne branché sur secteur, en mode performance (graphique hybride) ;
    • relever le journal Système (« Display », 4101) et AMD Adrenalin (rapports de plantage AMD) après un nouvel incident ;
    • option : désactiver le MPO, ou essayer un autre pilote. Ce choix revient à l'utilisateur.
  4. Shipping de l'alpha : une session de 30 min ou plus, dont 10 min immobile. Si le plantage revient en Shipping sans -gpucrashdebugging, relancer une fois avec l'option (-gpucrashdebugging reste lu en Shipping, à vérifier, estimé).

4. Verdict

  • Établi :
    • perte du périphérique en DXGI_ERROR_DEVICE_RESET, dans le pass Histogram de la vue principale, jeu immobile depuis 12 min ;
    • FaceCapture, SecondScreen et Slate pas commencés ;
    • code nouveau de COMMUN-13 inactif, aucune PageFault, VRAM à 26 % ;
    • aucun TDR dans le journal Système ;
    • premier plantage GPU des essais COMMUN-10 à COMMUN-13.
  • Estimé : cause extérieure au jeu (pilote AMD ou machine à graphique hybride). Elle n'est pas prouvée, faute de DRED.
  • Aucun correctif proposé côté STG. Il faut d'abord l'essai 1.

5. À verser

  • lp-build et fiches de tests communes : ajouter -gpucrashdebugging aux arguments d'essai tant que la cause n'est pas tranchée. Son coût est faible en Development (estimé).
  • Archive : CrashReportClient-Win64-Debug.exe est absent de l'archive Development (« Could not start crash report client »). C'est sans effet, mais à noter pour le Shipping, s'il doit envoyer des rapports.

6. Fichiers à commiter

A Docs/Migration/etat/ST/STG/STG-COMMUN13-GPU-DIAG.md.

Tours : 14