OlliOlli World (PPSA02327)

[santhoshkumar-dev]

Existing thread

• Searched Game bring-up for PPSA02327 and OlliOlli; no existing discussion found.

Title and content version

OlliOlli World (PPSA02327) — content version 01.005.000 from sce_sys/param.json.

AnyPS5 commit and system

• Upstream main at 2a2a3dc650b9245fb0fb9b088afb1a6c27637f7d, without additional patches.
• Windows 11 Pro 10.0.26200; AMD Ryzen 5 5600X; AMD Radeon RX 6700 XT.
• Windows display driver version: 32.0.21045.5002.
• WinLibs MinGW-w64 GCC 15.2.0, ucrt-posix-seh r7; Release build; ANYPS5_ENABLE_SPIRV_TOOLS=ON.

Furthest point: Menu / character customization

With the default settings, the game remained running and its FPS counter advanced, but the screen was almost entirely white with a faint diagonal line.

The character-customization / Clothing screen renders with APS5_STORE_AT_FLIP=1. The character, clothing items, text and menu controls are visible. The title-bar counter showed about 85 FPS in the successful screenshot; this is a single observation, not a sustained performance measurement. Level gameplay, audio and saving still need verification.

Current blocker and verified workaround

The white-screen run contains these messages (addresses omitted):

[gpu] storage image ...: guest memory changed while GPU results were pending; keeping the CPU's blocks
[gpu] storage image ...: memory no longer registered; 1 pending ranges dropped

The successful run's profile confirms the setting is active:

[storage] ... write-backs by reason (count/MiB): flip 469/3957.2; 469 write-backs GPU-direct, 0 stored nothing ...

The successful launcher also enables CPU/GPU profiling and exit tracing. A same-scene comparison keeping those profiling settings identical is still needed to isolate the setting completely. The observed workaround is useful, but the warnings alone do not establish the underlying bug.

How it was run

The executable and bundled modules were relinked with:

relinker --windows --windows-diagnostics --registry --module-dir Media/Modules --module-dir Media/Plugins source/eboot.bin run/app.exe

From the relinked game's runtime directory, the successful run used:

$env:APS5_STORE_AT_FLIP = '1'
$env:APS5_PROFILE_DRAW = '1'
$env:APS5_PROFILE_GPU = '1'
$env:APS5_TRACE_EXIT = '1'
.\app.exe

The import audit has no absent imports or missing libraries. It lists 14 exported throwing stubs on this commit; the white-screen run did not report a fatal exception in the supplied log.

Fix investigation and related work

• Confirmed workaround: APS5_STORE_AT_FLIP=1, introduced by merged PR feat(agc): store pending storage-image results at each flip with APS5_STORE_AT_FLIP #1995.
• The storage-image technical debt at the tested commit describes deferred GPU results and their visibility/lifetime around guest memory reuse. Issue agc-driver: write-back drops GPU results of full 64 KiB blocks of 1920x1080 render targets (PPSA12544 backgrounds garbled) #1970 is related background from another title; equivalence has not been established for OlliOlli World.
• Open PR fix(agc): store small pending storage results at each flip #4841 stores small host-imported storage results at each flip. It is a candidate to evaluate, not a verified fix for this title; it deliberately leaves large targets pending.
• A permanent fix still needs to identify which image results are read too early or lost, and make them visible at the correct synchronization point while preserving actual newer CPU writes. No OlliOlli-specific source fix is claimed here.

Progress tracker

• Converts and loads the bundled modules.
• Default run's white-screen symptom recorded.
• Character-customization rendering confirmed with the workaround enabled.
• Repeat an identical-scene comparison with profiling held constant.
• Verify skating gameplay, audio and saving.
• Retest the earlier main-menu abort (ucrtbase.dll, 0xc0000409); it has not been linked to the rendering issue or confirmed fixed.
• Link a verified source fix/PR, then retest without APS5_STORE_AT_FLIP.

This thread will be updated with new test results and verified fixes. Report prepared with AI assistance; rendering was confirmed by the tester on this machine.

[santhoshkumar-dev]

2026-10-14 follow-up: main + rendering/audio PR test

A local Windows Release build based on main 31bfc4e8693d86318824d83c47cfa418703a7cc8 with PR #4794 (eager storage-image writeback) and PR #5198 (AudioOut2 completed grains) merged at local commit 148bf6934e0c90ba004fca6f4430e1b2de22ff26 built and converted OlliOlli World 01.005.000. The relinker converted all 13 bundled modules. A full audit of executable and bundled-module imports found 0 absent imports and 0 missing libraries; it reports 35 exported throwing stubs.

With PR #4794's default eager writeback enabled and APS5_STORE_AT_FLIP unset, the title reached the main menu, but the tester reports approximately 1 FPS after the menu, much worse than the earlier build played with APS5_STORE_AT_FLIP=1. The PR combination therefore is not currently a playable replacement. Its audio behavior and later graphics artifacts could not be judged reliably in this slow run.

This is a preliminary performance regression observation, not a confirmed cause. PR #4794's draw-time writeback is a plausible contributor, while current main also differs substantially from the earlier 2a2a3dc65 build. The draw pipeline PR series #1201/#1202 was not included because it conflicts with the selected main revision.

The next controlled run uses the same local build with APS5_DEFERRED_WRITEBACK=1 and APS5_STORE_AT_FLIP=1, keeping the audio PR and CPU/GPU profiling active. This turns off draw-time writeback and restores the earlier flip-store policy without rebuilding. Its FPS, rendering, audio and load-stutter results are pending. I will update this thread after that comparison.

[santhoshkumar-dev]

Previous run update

Sharing the results from my latest OlliOlli World test before I rebuild and retest on the newest main.

The good news is that this no longer looks like a simple startup/crash issue.

The game successfully booted and continued running for roughly 10 minutes. The process eventually exited with code 0, there were no Windows crash events recorded, and GPU/present activity continued throughout the run.

Near the end of the test it was still producing around 223 presents over a 10-second interval, so the emulator was continuing to execute/render rather than getting stuck completely.

The main issue is still rendering correctness.

APS5_STORE_AT_FLIP=1

The biggest finding from this run was that enabling:

APS5_STORE_AT_FLIP=1

made the problematic rendering significantly more correct.

In particular, scenes such as the character/customization rendering that were previously almost completely white became much more usable/correct.

That makes this flag a very useful debugging clue.

However, I don't think it should be considered the actual fix.

The profiling data showed that using STORE_AT_FLIP causes an extremely large amount of image data to be written back.

One of the final profiling intervals showed approximately:

• 1084 GPU-direct write-backs
• around 8.4 GiB of image data written back
• within roughly a 10-second interval

So it appears that STORE_AT_FLIP is brute-forcing visibility of GPU image results by publishing a very large amount of pending data back to guest memory.

It improves correctness, but at a very high cost.

What this suggests

My current suspicion from this run is that there may be a GPU image coherency / StorageTexture issue somewhere in the rendering path.

Something approximately like:

GPU renders into an image
→ the newest result remains pending
→ the game later samples/reuses the same logical surface
→ an older sampled texture / guest-memory representation may sometimes be used instead
→ incorrect/white rendering appears

Then with APS5_STORE_AT_FLIP=1, the pending result is forced back into guest memory before that later access, which hides the problem.

This is only a working theory at this point — I haven't identified the exact resource or lookup that causes it yet.

Other messages seen during the run

There were also several things worth recording:

DescriptorBindingBuilder::Populate multisampled image resources have no descriptor image shape

appeared during shader-library prebuild.

I also saw:

todo: void GfxDevicePS5SharedData::CreateWorkload()

and:

sceSysmoduleLoadModule unknown id: 295

However, none of these stopped the title from continuing to run, so I don't currently have evidence that they are responsible for the main white-rendering problem.

There were also many successful cases of textures being backed directly by storage images, with logs such as:

Texture address=... viewed from storage image

so this does not appear to be a case where the entire StorageTexture path is broken.

It may be a specific image/view/format/version relationship.

Important note

This test was done while AnyPS5 is moving very quickly and AGC/rendering work is landing frequently.

Because of that, I'm keeping this run primarily as a baseline and evidence.

I'm going to rebuild from the newest upstream main and run the game again from a completely clean configuration before investigating this path further.

The next goal is simply to determine whether the same rendering problem is still reproducible on current main without APS5_STORE_AT_FLIP.