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

未关闭
  • 哪里不对？
#405 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
cpp, linux
领域
backend, performance

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
C++
星标
224
派生
0
30 天内没有已合并 PR

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

featureJosh/Recompia 的其他 Issue

查看 featureJosh/Recompia 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。