FINAL FANTASY RESONANCE (PPSA31544)

[JJenkx]

Existing thread

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

Title

FINAL FANTASY RESONANCE (PPSA31544)

Content version tested

01.000.001, from sce_sys/param.json (the title screen shows 1.0.1.0). Unreal Engine title. The dump has its PlayGo files, so no PlayGo setting was used.

AnyPS5 commit

main 924b18f59c + #10515 (f179568345). #10515 only adds a two-sample alpha-to-coverage table, which this title does not use as far as seen.

System tested

Arch Linux, Ryzen 9 7950X, Radeon RX 6650 XT (RADV NAVI23), Mesa 26.2.4, Linux 7.2.9. Release build.

Furthest point

Intro cutscene of a new game: the crystal legend narration, after the title screen and the difficulty selection.

What is shown

• The dump's root eboot.bin is not the game. It is a scene-release launcher (an OpenGL demo). After Cross it logs /app0/_DUPLEX_/eboot.bin missing - home screen and quits after about 45 s. The game's executable is additional_files/eboot.bin (179 MB). I relinked that one in place of the root eboot.bin, with the other files unchanged. No imports are absent.

• With the real executable (scripted input: Cross every 30 s, then Up and Cross to accept the difficulty prompt):

  • by 120 s: the title screen with "Select difficulty" (Casual, Normal, Expert);
  • then the "Start with Normal difficulty?" prompt;
  • after "Yes": the opening cutscene ("A great legend is told about the eight mystical crystals...").

• The runs end at the scheduled close with exit 0. There is no driver error or exception, and no GPU fault in the kernel log.

• Speed:

  • about 6 FPS on the title screen and 1.6 FPS in the cutscene;
  • the host import budget is lowered after vkAllocateMemory failures;
  • a 460 s run refused 4.5 million imports (3.2M from builds, 1.3M from accesses) and made 270.

  This is the case fix(agc): pin the import ceiling only on memory exhaustion #8091 changes; it has not been tested with fix(agc): pin the import ceiling only on memory exhaustion #8091 here yet.

Current blocker

Speed: the refused host imports, which is #8091's area. No stop.

How it was run

1. Build libs and relinker from the pinned commit.
2. Stage the title with additional_files/eboot.bin as the executable, then unwrap the SELFs with tools/unwrap_self.py. The modules are in sce_module; fakelib/ holds the dump's own stand-ins and was not used.
3. Relink and run:

<build>/core/relinker/relinker --registry --rpath <build>/core/libs/libs <stage>/eboot.elf app.elf
LD_LIBRARY_PATH=<build>/core/libs/libs ./app.elf

Not verified

• gameplay;
• audio;
• fix(agc): pin the import ceiling only on memory exhaustion #8091;
• Vulkan validation during the title runs.

AI-assisted: yes (Claude Code)

[JJenkx]

With #8091

With #8091's head 71d29197ff merged onto the same build, the same 460 s run refuses no host imports. It gets further into the opening cutscene. Both runs exit 0.

Build	Title screen	Cutscene
without #8091	about 6 FPS	1.6 FPS
with #8091	26-31 FPS	12-15 FPS

The figures are the window title's FPS counter, n=1 per build (comment on #8091).

AI-assisted: yes (Claude Code)

[XatiX]

On commit: #fa515de I am ingame at around 25-30fps minus large drops to 0.5-1fps during shader caching.
RTX 5080/9800X3D

[Whitesun123]

Windows run on main c8d34aa8f

System: Windows 11 Pro 10.0.26200, RTX 5080 (driver 617.42), Ryzen 7 7800X3D, 31 GB RAM. Built from c8d34aa8f with no pull requests on top, GCC 15.2.0 (WinLibs UCRT), Release.

Content version: 01.000.001.

• Set up as in the first post: the 179 MB game eboot from _DUPLEX_ is relinked as the root executable, and its SELF is placed as app0/eboot.bin. The DUPLEX launcher and fakelib/ are left out; the dump's five sce_module ELFs are bundled.
• app0/ holds ffrs/content, engine/, sce_sys/, uecommandline.txt, package.manifest and contentids.json. The game names the last two in its own strings.

Relink: relinker --windows --registry --windows-diagnostics exits 0 in 51 s.

• tools/import_audit.py: 0 absent, 20 stubs. The stubs are 4 Agc calls the guest JobManager imports, 2 FontGraphics draws, Http2 SendRequestAsync/WaitAsync, scePadSetAngularVelocityBiasCorrectionState, sceVoiceQoSGetLocalEndpointAttribute and __tls_get_addr. None was hit in play.
• The audit also lists sceSystemServiceLoadExec as a stub, although it is implemented; only its unsupported-case helper calls NotImplemented_nid_no_patch.

Furthest point: past the opening boss fight and the summon cutscene, into the castle. That took about 45 minutes over five runs.

• Menus and settings work, keyboard and DualSense alike. The DualSense was on Bluetooth: Pad: connected game controller (slot 0): DualSense Wireless Controller, with motion sensors, touchpad and light bar detected.
• Audio works.
• The touchpad skips cutscenes (Tab on the keyboard).
• The autosave is written, and loading it works after a restart.

Frame rate:

• About 50-55 FPS in the menus, 13-21 FPS in fights (48-93 ms frames) and about 30 FPS in the castle.
• The F10 overlay shows only 190-430 draws and 150-255 dispatches per frame, with 2.4-7.5 of 14.9 GB VRAM in use. The frame rate does not change with window size (render 1536x864 to 2240x1260), so this does not look GPU-bound.
• A 26-minute run ended with host imports at shutdown: ... made 6912, refused 0, failed 1. The fix(agc): pin the import ceiling only on memory exhaustion #8091 budget collapse does not appear on Windows/NVIDIA.
• Shaders: each new effect stalls about 1 s the first time. On the next run the pipeline journal loaded 495 pipelines, the shader cache reported 1,445 hits against 36 misses, and effects already seen no longer stalled.

One crash, probably caused by the host:

• While Windhawk (a Windows mod injector) was injected into the process, a loading screen crashed with FATAL: unhandled exception 0xc0000005 on thread 25904 'Background Worker #8', a read of 0x38 at eboot.exe+0x4c1c114. A game function received a null second argument and read through it.
• Loading the same save with Windhawk closed got past that screen, and there was no Windhawk module in the process. That is one run each way, so check for injected tools first if this crash shows up.
• After the crash report the process stayed alive and kept presenting frames. It exited with code 0 when the window was closed.

How it was run: ANYPS5_GPU="RTX 5080", APS5_CRASH_STACK_BYTES=512 and APS5_STALL_WATCHDOG_SECS=30, started from the directory that holds app0/, libs/ and the MinGW runtime DLLs.

[JJenkx]

Linux / AMD RX6650XT / RADV bring-up update: the opening movie completes, the Move/Sprint and Mini-Map tutorial pages respond to R1/Circle, and the tutorial closes into the gameplay scene with the character, System Menu/Mini-Map controls and map visible.

Exact private integration 69e4e3082871 = main 57f506f81192 + #8091 public 71d29197ffb2 + #4449 public 829f605e7767, with the previously reported test-only munmap address cast. This native run does not include the newer descriptor-ownership delta posted on #4449.

The 882 s diagnostic run exited normally (0), restored its configuration, and did not trigger the host-pressure guard. Host MemAvailable stayed above41.45GiB, so this does not clear #8091's lower-memory or JUMANJI blockers. Shader caches were warm; GPU readbacks and independent CPU builds were active. No loading/FPS comparison is claimed.

Player movement and audio remain unverified; scene lighting/smoke fidelity has not been compared against a reference. The page automation misread 1/2 as V2 and 2/2 as 212; I advanced those pages from visually verified screenshots. That was a test-controller issue, with no new Pad library change.

AI-assisted: yes.

[JJenkx]

Corrected Battlefield performance comparison: main 401731067856 1.57 FPS /637.054ms p50 versus main + #4449 + descriptor-ownership/test-fixture follow-ups 975deb4c3156 12.80 FPS /78.003ms p50 — about 8.17× median frame-time reduction in one stationary save scene. The earlier8.80× warm-cache report is superseded because its main warm-up stayed at title. The replacement verifies prior actual gameplay on both caches, two HUD observations before capture180:20, clean heads and zero dropped events. Same RX6650XT/Linux machine and scene. No #8091 or memory-pressure qualification. Opaque black graphical effects remain; audio fidelity unassessed.

Exact source composition, official summaries, corrected trace archive and limitations. Separate AudioOut2 polling fix #11055 is ready; its native comparison establishes no FPS gain.

[JJenkx]

Linux/RADV black-effects investigation on unmodified main acb900c194325b9ee8c23c10768a9a491454f0b2: the 32×32×32 color-grading texture is populated only in depth slices 0–7; slices 8–31 are zero. An independent native storage readback without RenderDoc confirms this, with a clean native exit and restored configuration/saves.

The producer draw dispatches mesh workgroups (1,32,1) into a 32-layer attachment view, with rendering layer count 32. GPU-extracted mesh output contains the expected layer IDs 0–31, two unculled triangles per layer. This RX 6650 XT / RADV Mesa 26.2.4 reports maxMeshOutputLayers = 8. Vulkan specifies undefined framebuffer results when a mesh shader exports a layer at or above that limit. This identifies an unsupported host layer range in the current path, rather than a missing instance count.

Existing #6959 implements rendering in device-sized layer windows while preserving the guest fragment Layer input. Its current-main integration and title qualification are next; I have not verified the title with that change yet. No new rendering-fix or FPS claim.

Capture qualification: the draw-triggered instrumentation saved the producer successfully, but that native run aborted at shutdown with a heap-corruption error (exit134); configuration and saves were restored. Its capture is diagnostic evidence, not a clean native pass. The separate non-RenderDoc readback above exited0. A replay-only constant-color output-store control still populated only slices0–7, and restoring the original shader reproduced identical texture bytes; original control flow/discard remained enabled.

Metadata-only measurements — SHA256 8e196a4c842e1dfe97e37e1950379cd200cafea6bf8c70363be38cf590b87b01, uploaded archive downloaded and hash-verified. Raw title captures/resources/shader code remain private.

AI-assisted investigation; measurements were executed locally.

[JJenkx]

The layer-window fix is now verified for this checkpoint in #6959, refreshed as 98f52d1c8474788a0f5abaceed628368a2688a65 on main 517a7b12b87b42357d5a66fb11803648b9aca38d.

Native readbacks on RX 6650 XT/RADV show main populating only 8 of 32 color-grading slices; the change fills all 32 in four windows of 8. The same-checkpoint Battlefield screenshots confirm that the large opaque black effects are removed:

• Main: black effects obscure the scene
• Candidate: fire/smoke and background are visible

Both 200-second native gameplay checks exit 0 and restore configuration/saves. Each uses the same checkpoint and one Continue press; the PR records the differing input gates and excludes the earlier menu-only attempt. These are qualitative graphics checks, not FPS/loading comparisons, a full playthrough or a console-fidelity claim.

Paired focused validation passed 36 executions on main and 42 on the change, no skips/VUID errors, with actual Khronos insertion; existing non-VUID compatibility warnings match in common fixtures. The PR links download-verified test/readback metadata and original screenshots. The native confirmations above use the ordinary renderer, without the capture observer that aborted in the earlier diagnostic run. #7310 remains the declared merge-order dependency.

AI-assisted investigation; results executed locally.