ELDEN RING (PPSA04610)

[wrocketdev]

Existing thread

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

Title

ELDEN RING (PPSA04610)

Content version tested

01.017.000 (USA), own dump.

AnyPS5 commit

main at ad2fbd74cd3f with the tessellation cull distance change (#13492), which this title needs.

System tested

Windows 11 Pro (build 26300), Intel Core i5-12600KF, NVIDIA GeForce RTX 3060 Ti (driver 617.42), WinLibs GCC 15.2.0 r7, Release.

Furthest point

Gameplay

What is shown

The title screen appears within about 20 s at 60 fps with no input. With a keyboard or pad, the game goes through the menu into the first area. The player walked indoors and outdoors in that area; the character, buildings, foliage, particles, fog and sky look correct, and text prompts work. Window captures will follow in a comment.

In the measured scene it presents 73 to 78 frames per 10 s (about 7.5 fps), none dropped; the window title showed up to about 18 fps elsewhere. Memory use reached 18.7 GB, GPU memory about 5.2 of 8 GB. The game's output is 3840x2160.

The HP, FP and stamina bars are not visible on the two captures; the compass is. Not known yet whether they are hidden by the game or missing.

Current blocker

No blocker in this short run. Performance: in the measured scene, queue 0x0 spends about 9 of 10 s on packets, mostly DRAW_INDEX_OFFSET_2 (about 4.7 s for about 108,000 draws, about 1,600 draws per frame), with GPU busy about 90 ms per frame. GPU mutex waits are 3 ms per 10 s and shader recompilation is negligible there. Combat and later areas are untested.

How it was run

tools/audit_dump.py reported 0 absent imports and 2 stubs (sceAgcUpdateInterpolantMapping_0100, sceVoiceWriteToIPort), neither of which stopped this run. Only the audit needed a local workaround, because tools/import_audit.py fails on main (#13002). Converted with relinker --registry --windows --trace-imports from main at ed1e0ed08fc2; the libraries were then built from the commit above. Run with APS5_PROFILE_DRAW=1 APS5_LOG_TIMESTAMPS=1 APS5_TRACE_EXIT=1 APS5_TRACE_CALLS=all.

AI-assisted: yes (Claude Code)

[wrocketdev]

Window captures from the first area, indoors and outdoors (cropped to the game image).

[wrocketdev]

Performance measurements in the first area, for whoever looks at this title. The in-game setting was already Prioritize Frame Rate with ray tracing off, so these are the title's fastest settings. The output stays 3840x2160 on a 1920x1080 display.

Same machine and build as above (i5-12600KF, RTX 3060 Ti, driver 617.42, main at ad2fbd74cd3f with #13492), APS5_PROFILE_DRAW=1 APS5_PROFILE_GPU=1. Three short runs, walking by hand, so the scenes are not identical from run to run.

What bounds the frame

About 7 fps. The GPU and the committer are both near their limit:

Steady 10 s windows
Presents	69 to 73
GPU busy per frame	about 113 ms, of which draw class 93 ms
Committer	8.2 to 8.4 s busy, 150,000 to 160,000 draws
Other GPU classes, per frame	shadow-publish 12 ms, storage-writeback 2.4 ms, storage-upload 1.5 ms

APS5_DRAW_PIPELINE=1

No result: [finisher] reports 0 handed to the draw finisher in every window of that run. I do not know why. That run did show 9.2 fps against 7.3, but with about 115,000 draws per window against about 155,000, and the baseline run reached 8.5 to 9.8 fps on its own lighter windows. So I read that as the scene, not the switch.

readTarget

1.3 to 2.1 s per 10 s on the committer, up to 4.6 s just after entering the area:

• About 0.8 s is the per-draw proof: about 280,000 lookups per window, about 65 pages each.
• About 0.6 to 1.3 s comes from 70 to 220 lookups over 1 ms, about 8 ms each. hook waits inside draws is 911 ms in a window where those took 650 ms, and the longest are 10.2 ms and 10.7 ms, so these may be GPU waits. That is not proven: I did not time them against the flushes.

APS5_TRACE_FLUSH

About 5,000 write-backs per 10 s, about 60 per frame, of which 78 % are storage refresh. The same images come back every frame at overlapping addresses and different sizes, for example 0x33efe0000 as 22.2 MiB and as 2.5 MiB, and 0x340fc0000 as 31.9 MiB and as 15.9 MiB, with other targets inside those ranges. That looks like transient targets sharing memory within a frame, which is my reading and not something I confirmed from the title. A 0.5 MiB image at 0x43fd01000 is also stored about 5 to 6 times per frame over its exact range.

This gives about 10 GB stored and 10 GB uploaded per 10 s, but on this GPU those classes cost only about 4 ms per frame. It looks like the same class as #6189. I am not proposing a change: skipping those stores would need proof that the title never reads the old contents.

Indirect arguments

One sync per frame on DRAW_INDIRECT indirect-args, 390 to 600 ms per 10 s, about 5.5 ms each. In the windows I read, the bytes were unchanged after every wait (unchanged 70 of 70, 110 of 110), with the target batch still open. Compare #5694. An unchanged result here does not prove the wait can go.

AI-assisted: yes (Claude Code)

[EagleBearerYS]

@wrocketdev on 0 handed to the draw finisher: that's expected with APS5_PROFILE_DRAW=1. The finisher hand-off (Execution/src/Driver/Draw/Draw.cpp, around line 735 on main 9310f48) requires the per-draw profile to be off, so while APS5_PROFILE_DRAW is set every draw is finished on the worker. Indirect draws and a few trace and verify switches also keep draws on the worker. APS5_PIPELINE_STATS=1 prints the same [finisher] line without turning the hand-off off, so a run with APS5_DRAW_PIPELINE=1 APS5_PIPELINE_STATS=1, and without APS5_PROFILE_DRAW, shows how many of ELDEN RING's draws the finisher takes. This is a reading of the code, not a run.

[wrocketdev]

@EagleBearerYS thanks, that was it, and it voids my APS5_DRAW_PIPELINE=1 note above. I ran it the way you suggested, without APS5_PROFILE_DRAW. In that run [finisher] hands off about 125,000 to 170,000 draws per 10 s, with 61 to 179 left on the worker.

Windows 11, i5-12600KF, RTX 3060 Ti (driver 617.42), 74164be133 (main 556547d plus #13492), with the 1080p patch from this thread. All arms set APS5_PIPELINE_STATS=1 APS5_TRACE_SUMMARY_EVERY=10. FPS is from aps5-summary.jsonl, one run per arm, about a minute walking by hand in the first area, so the routes differ:

Arm	FPS, mean	FPS, 10 s windows	Windows	Commit
neither	12.6	9.3 to 18.3	7	34 to 36 us
APS5_DRAW_PIPELINE=1	13.7	9.9 to 16.5	5	31 to 34 us
APS5_DRAW_PIPELINE=1 + APS5_WORKER_AFFINITY=1 + committer pinned	12.5	9.1 to 16.7	7	about 34.5 us

The windows overlap, so 13.7 against 12.6 is not proven. The committer stays about 8 s of 10 busy in all three, so it still bounds this title at 1080p.

The third arm is a local two-line change, PinWorkerThread("draw committer") at the start of DrawPipeline::run(), the idea of #7246. The binary of all three arms had it, and it only acts with APS5_WORKER_AFFINITY. The log confirmed [affinity] with mask 0xfff. I see no gain, so I dropped it and am not opening a pull request.

Two more 1080p runs, with APS5_PROFILE_DRAW=1 APS5_PROFILE_GPU=1 and without the two switches above except where named:

• APS5_WORKER_AFFINITY=1 alone: about 12.0 fps against 12.2.
• APS5_DRAW_INPUTS_IN_PLACE=1: about 6.9 fps against 12.2. vertex drops from 1.7 s to about 0.4 s per 10 s, but GPU busy goes from about 41 to 127 ms per frame and readTarget from about 1 s to about 4 s, with about 70 slow lookups of about 55 ms each. I do not know why.

AI-assisted: yes (Claude Code)

[wrocketdev]

A 1080p patch for 01.017.000 that raised the frame rate from about 7 to about 12 fps in the first area, with a clean image on a short run.

The title reads CS.PS5.frameBufferW and CS.PS5.frameBufferH at start, and their defaults are a global at 0x43b0320 holding 3840 and 2160. Changing those defaults is enough to make the guest present 1920x1080. No file in app0 sets them.

format = 1

[[patch]]
name        = "framebuffer_width"
target      = "eboot.elf"
va          = 0x43b0320
type        = "u32"
expected    = 3840
value       = 1920
description = "default CS.PS5.frameBufferW"

[[patch]]
name        = "framebuffer_height"
target      = "eboot.elf"
va          = 0x43b0324
type        = "u32"
expected    = 2160
value       = 1080
description = "default CS.PS5.frameBufferH"

Convert with relinker --patches <file>, or name the file relinker-patches.toml beside the input executable. expected makes the conversion fail on another content version.

Same machine, build and in-game settings as the comment above, in the first area:

	3840x2160	1920x1080 patched
FPS	about 7.3	about 12.2 (11 to 13.7)
GPU busy per frame	about 105 ms	about 41 ms
draw class per frame	93 ms	27 ms
shadow-publish per frame	12 ms	3.4 ms
readTarget per 10 s	1.3 to 2.1 s	0.8 to 1.1 s
Draws per 10 s	about 155,000	about 130,000

The GPU then has about 40 ms idle per frame, so the limit moves to the CPU side and a lower resolution should not help much more.

Limits:

• About one minute of play in the first area, walking by hand, on a route that differs from the baseline run. Treat the numbers as an order of magnitude.
• The image was reported clean by the player. Menus, combat, cutscenes and other areas were not checked, and no captures were taken.
• The guest stayed at 1920x1080 and the log shows no error in that run. A function at 0xf6a840 can still write this global at run time, and a display mode at 0x2b2eec7 and some tables keep 3840x2160, so another scene may behave differently.
• The title still needs fix(agc): accept cull distances from tessellation evaluation shaders #13492 to get past the title screen.

AI-assisted: yes (Claude Code)