WIP: docs(tested): record Deck transition and clock measurements #470
No reviewers
Labels
No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Longshot!470
Loading…
Reference in a new issue
No description provided.
Delete branch "zeldaootr/Longshot:deck-transition-evidence"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
Steam Deck OLED runs stopped under memory pressure when entering Hyrule Field on RC3. A second problem left the GPU at 200 MHz after a failed suspend, which obscured the performance of the recovered system.
What changed
Twelve short test records cover baseline, corrected guest memory accounting, sleep/wake recovery and the recorder-thread comparison, one exploratory affinity run, and a GPU timing breakdown of the Field entrance (
RX_VK_PASS_TIMING=2: 27.16 ms GPU time a frame, 8.04 ms of it compute dispatches; instrumentation affects timing).mainalready includes the accounting change (a4c77174, #324).Flags and settings
None.
Measurements
main@cf605c85and this documentation-only PR @f2b46643have identical runtime code. Runs used RC3 with both guest-reporting modes in one executable and the stock renderer. On SteamOS 3.9.5, RADV VANGOGH, Mesa 26.2.0-devel, 16 GB, 1280×720, frame generation off, a copied child Kokiri save was teleported to the Field. The low-memory guard stopped all three legacy-report runs. All five default-renderer corrected-report runs finished the 45 s stationary sample. At Kokiri the first two paired runs had 1,507 and 1,566 MiB less guest backing with the corrected report. The GPU stayed at 200 MHz during a 6.03 FPS sample. Following a successful deep sleep and Bluetooth wake the same corrected build reached 20.47 FPS. One exploratory run with the reserved guest CPU core released (HOS_RESERVE_CORE=0) measured 20.73 FPS; one run is too small to justify changing the default. See the individual rows for settings and all comparison arms.Testing
Tested: The run records passed
tests/test_tested_configurations.py. The guard stopped the old-report runs before an actual kernel OOM. Full suite on this branch: 472 passed, 5 failed, 82 skipped. Failures:test_bake_portability,test_lift_cache,test_menu_keys,test_module_ids,test_pad_layout. All of these also failed on unmodifiedmain(cf605c85) in this environment.Not tested: Windows and other GPUs.
Needs other testers: None: records only.
Screenshots
Nothing on screen changes.
Risk and rollback
This changes measurement records only. Revert the documentation commit to remove them.
Reviewer notes
This provides Deck evidence for existing code and for the separate suspend problem. The recorder comparison found no repeatable increase at the entrance.
Issues
Related hardware report: https://github.com/ValveSoftware/SteamOS/issues/2964
Checklist
For everyone
type(scope): description).main. One commit behind:maingaineddc390e59(crash records, unrelated); rebased before ready.python -I -B tests/run_all.pyrun and passing (any failure that also fails onmainis named above).third_party/untouched (a new folder with aPROVENANCE.mdinstead).If applicable
Assisted-by:/Co-Authored-By:trailers.docs/tested/for each new measured run (format indocs/tested-configurations.md; no appended row or assembled view).View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.