Red Dead Redemption (PPSA30528)

[HQasper]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

Red Dead Redemption (PPSA30528)

Content version tested

01.002.000

AnyPS5 commit

main 29b25aa with #5965 (abd3af9) and #9913 (9da4a9607) merged on top

System tested

Windows 11 Pro 26300, MinGW-w64 GCC 15.2 (Release), NVIDIA GeForce RTX 5090 (driver 617.42)

Furthest point

In game

What is shown

The opening cutscene plays through. After about 7 minutes the game reaches Armadillo station ("Go to the saloon") and runs there at about 6.7 FPS. The log has no FATAL, unsupported or NotImplemented line.
Picture: yes. Audio: not checked. Input: walking with the left stick works (pad input driven with APS5_PAD_INPUT_FILE); keyboard and mouse not checked.

Current blocker

Without #9913 the opening cutscene stops after about 2.5 minutes with AGC graphics: stencil operation 12 is unsupported (DB_STENCIL_CONTROL logic operation STENCIL_XOR).

Open pull requests the title needs:

• feat(libSceAudioOut): implement sceAudioOutGetSystemState #5965 (sceAudioOutGetSystemState): needed to load.
• fix(agc): draw stencil AND, OR, XOR and XNOR on the bits they change #9913 (stencil AND, OR, XOR and XNOR): needed to get past the opening cutscene.

No local changes beyond these two.

Performance: about 6.7 FPS at Armadillo station on an RTX 5090. #5895 tracks the G-buffer draws that read vertex and index data in place from host imports.

How it was run

Relinked with relinker --windows from the title's eboot.bin and sce_module, then started the relinked exe from the game folder. No settings; the only environment variable was APS5_PAD_INPUT_FILE, which drove the pad input.

[akkadbakkad89]

Second datapoint — same stack, slower card

Content version: 01.00 (UP1004-PPSA30528_00-REDEMPTION000001)
Stack: main 4883171f9f + #5965 + #9913 (both merge cleanly on current main, relinked relinker --windows from the title's eboot)
System: Windows, MinGW-w64 Release build, NVIDIA GeForce RTX 3070 (driver 617.42, ReBAR on), i7-10700

Furthest point: in game. Boot reaches the legal screens, the loading screen, and the main menu, which renders the live game-world backdrop behind the logo — at ~3.6 FPS by the title's own counter, so the draw bottleneck shows even in the menu. Play > Normal loads a saved game into Armadillo; gameplay runs at about 2 FPS, matching the #5345 queue-worker / #5895 host-import profile scaled down from the 5090 and 4070 SUPER reports. No FATAL, unsupported or NotImplemented line in the log.

Picture: yes, renders correctly end to end. Audio: working correctly (music and effects audible). Input: pad input accepted.

Legal screen	Loading	Main menu

For the perf queue: two open PRs target this scene's costs — #9712 (draw snapshots in resizable BAR memory; this card exposes the full 7.83 GiB heap host-visible, so the path should engage) and #9875 (copy only the vertex records a draw fetches). I'll stack both next and post trace_digest numbers from this machine.

[akkadbakkad89]

Follow-up datapoint on the perf-stack question, PPSA30528 (content 01.002.000, RTX 3070, driver 617.42, Windows 11, ReBAR on).

Stack tested: main 4883171f9f + #5965 + #9913 + #9712 + #9875, full MinGW Release .prx set, commit e427d74f06. Pad-scripted past the menu into Story — reached stable in-game rendering with clean visuals and working audio over a ~9-minute session.

Perf PRs: with #9712 + #9875 the title is still hard CPU-bound — trace_digest over the in-game window (87 intervals / 2456 presents): p50 ~422 ms/frame, GPU busy only ~151 ms/present, queue worker ~98.6% saturated. Top phases are all packet/draw CPU: Driver.Packet 411 ms, Driver.Draw 308 ms, Graphics.Draw 238 ms (committer). I also A/B'd APS5_DRAW_PIPELINE — it moves Driver.Draw off the worker (~216→145 ms) but the committer picks the work back up; net p50 slightly worse (~370 vs ~303 ms menu baseline). So the wall is the per-draw miss path described in #5345, not threading.

Cache-miss anatomy (diagnostic counters on this stack): ~73k draw lookups / 10 s, 11% exact hits, ~65k data-only hits — but ~118k stage re-materializations / 10 s. Rejection cause is ~94% usedEqual (a masked userData word the shader reads changed), validate-fails ~0. The changed words are overwhelmingly 64-bit pointer pairs (~90% map to guest memory) in the VS/PS SGPR blocks — hardware-fetched resource/table bases sliding through a bump-allocator arena.

Relocation experiment (local, not proposed upstream — reverted): tried rebasing DispatchVariant runs when a moved pointer provably matches a captured run (run.first == was or run.second == was cursor pattern) plus shader-data/push-constant repatching. Result: under APS5_VERIFY_DRAW_DATA_HITS the relocated stages are bit-exact vs fresh capture (~39k verified / 10 s, zero divergence), but:

• ~75% of moved pointers have no captured run — their targets were never SRT-walked, so the only handling is patching the forwarded word. That passes artifact-verify yet corrupts output in-game (gibberish text, white flashes): the new target region is never added to matchedRegions/memory, so it never reaches the committer snapshots — the draw then reads stale memory.
• Requiring run-evidence for every moved pointer is clean but fires ~1-5 times / 10 s — RDR's churning pointers are unwalked resource bases, so there's nothing to rebase against.
• Even the loose version cost more in clone+validate overhead than it saved (~322-435 ms p50 vs ~303 ms baseline).

Conclusion: for this title the draw-cache miss storm is driven by resource-pointer churn whose targets live outside variant.runs, and #5345's per-packet cost model holds — the fix needs those hardware-fetched regions to enter the capture/snapshot pipeline (or a cheaper miss path), not userData pointer rebasing at the variant layer. The stack itself is stable in-game.