Legion Go S (SteamOS): GPU reset mid-run, then ~10 fps with the GPU pinned at 2200 MHz until a reboot

Abierto
  • ¿Algo no está bien?
#405 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp, linux
Área
backend, performance

Línea de trabajo

Start by reading the GPU reset kernel log and the slow-state pkp.log details in the issue; the reporter can provide a full log and kernel excerpt. Investigate whether the runtime can detect persistent GPU sync waits after a reset and where it reports runtime diagnostics. Done looks like a useful log line for that state and documentation or launcher guidance that rebooting may be needed; the issue does not identify specific files or tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happened

Twice during the #276 test batches the kernel reset the GPU while pkp.exe was running. Both times the game then ran at about 10 fps with the GPU reporting 100% busy at its top clock (2200 MHz) the whole time, until the device was rebooted. Restarting the game doesn't help: every fresh run after the reset (a new pkp.exe each time) sat at 9.6 to 12 fps where the same runs hold 40 fps capped before and after.

Kernel log, the same both times (amdgpu.lockup_timeout=5000,10000,10000,5000, the SteamOS default):

amdgpu: ring gfx_0.0.0 timeout, signaled seq=6269814, emitted seq=6269817
amdgpu:  Process pkp.exe pid 63475 thread pkp.exe pid 63510
amdgpu: Starting gfx_0.0.0 ring reset
amdgpu: Ring gfx_0.0.0 reset failed
amdgpu: GPU reset begin!
amdgpu: MODE2 reset
amdgpu: GPU reset succeeded, trying to resume
[drm] device wedged, but recovered through reset

Two seconds before it: "Dumping IP State Completed" and "AMDGPU device coredump file has been created". I didn't save the coredump before rebooting; I will next time.

When:

  • 2026-11-07 22:56:18, 0.7.8, 71 s into a run with the defaults, 40 fps cap.
  • 2026-11-09 19:34:50, 0.9.0, 168 s into a run with readback_defer = false and readback_log = true, 40 fps cap.

Both were runs on the non-deferred readback path. None of the 12 deferred runs or the 20 readback_async = false runs has reset so far, out of about 35 non-deferred runs in all. Too few to call it related; noting it.

What the slow state looks like in pkp.log (every frame, not once a second):

hitch: frame 4936 took 179.8 ms (t=292.4 s); during it: pool_copy_copied_kb +42864, pool_copy_landed_kb +10241, texture_uploads +1; render thread ms: idle 168.4, replay 11.2 (gpu slot wait 0.1, uploads 0.1), present 0.2 (acquire 0.1), other 0.0; game ms: longest gap between presents 178.4, GPU sync waits (all threads) 161.0, presenting thread in system calls 124.7 (waits 124.6)
hitch: 98 frames in 10.0 s: mean 9.8 fps, 1% low 4.8 fps, worst 207.2 ms, 4 over 2x the median (101.0 ms)

Sampled while slow: gpu 100% at 2200 MHz, package 27 to 44 W, 85 to 90 C. The same runs when healthy: gpu swinging 0 to 100% at 400 to 1635 MHz.

What you expected

No reset, or the GPU back at normal speed after one. It's most likely the kernel or firmware side (a fresh process is just as slow), but two cheap things would help people who hit it: a line in the docs or launcher saying "after a GPU reset, reboot, restarting the game won't fix it", and a pkp.log line when the runtime can tell it's in that state (GPU sync waits over 100 ms on every frame from the start of a run).

Version

0.7.8 and 0.9.0 (exe 4bbe12d8)

Platform

Legion Go S, SteamOS 3.8.16, kernel 6.16.12-valve24.5-1-neptune-616, GE-Proton10-34

GPU and driver version

AMD Radeon 680M (Rembrandt, 1002:1681 rev c3), RADV from SteamOS 3.8.16

pkp.log

The slow-state logs are from test batches on a save copy; I can attach one (and the kernel log excerpt) if useful.

Lenguaje dominante
C++
Estrellas
224
Forks
0
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de featureJosh/Recompia

Todos los issues de featureJosh/Recompia

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.