Under The Waves (PPSA08056)

[JJenkx]

Existing thread

• I searched this category for PPSA08056 and "Under The Waves"; no thread exists.

Title

Under The Waves (PPSA08056)

Content version tested

The extraction's eboot.bin. The dump has no PlayGo metadata files.

AnyPS5 commit

main 474030e584, with no extra PRs. The second run below adds only a logging line at the vertex alignment check.

System tested

Linux 7.2.11 (Arch), Ryzen 9 7950X, Radeon RX 6650 XT, RADV Mesa 26.2.6, GCC, Release.

Furthest point

The first screen at 25 s, rendered bright at about 60 FPS. After that the frames are dark and the frame rate drops to 1 to 15 FPS.

What is shown

Cross every 12 s from 30 s, APS5_PLAYGO_UNLISTED_CHUNKS=installed. Two runs stopped at about the same point with different errors:

Run	Result
1	exit 134 at 127 s: AGC graphics: unaligned vertex buffer
2	exit 134 at 114 s: AGC driver: unsupported PM4 packet type: header 0x00000000 at DWORD 0 of 6640. The logging line at the vertex check did not fire before this.

Current blocker

Not identified. A different error at the same moment, including a command buffer whose first DWORD is 0, points to a timing or coherency problem around that point more than to one missing feature. The vertex refusal itself is deliberate on main: Vulkan requires vertex attribute addresses and strides aligned to the format, and there is no shader-side vertex fetch fallback.

How it was run

relinker --registry --rpath <build>/core/libs/libs eboot.elf app.elf
APS5_PLAYGO_UNLISTED_CHUNKS=installed ./app.elf

AI-assisted testing and report: yes.

[JJenkx]

More runs on main 474030e584, with a local diagnostic print at the vertex alignment checks. The print is not part of any PR.

The stop is random. Across eight runs with the same inputs:

• three stopped with AGC graphics: unaligned vertex buffer at 114 to 127 s;
• two stopped with AGC driver: unsupported PM4 packet type: header 0x00000000 at DWORD 0 at 114 s, with 6,640 and 3,550 DWORDs;
• three reached their scheduled close at 168 to 237 s, exit 0.

Two different refused vertex V#s were printed:

V# words	Base	Stride	NUM_RECORDS	OOB_SELECT	Format
00000000 00000000 00000000 0004022c	0	0	0	0	32_32 float
00000000 00000000 00001555 2004a3ac	0	0	0x1555	2	32_32_32 float

The first one reads only zeros. main already binds such V#s to a zero buffer but refuses them earlier on the null base; I have a local change for that. The second one is in range under OOB_SELECT 2, so it would fetch from address 0.

Together with the command buffers whose first DWORD is 0, at the same point in the run, this looks like the driver reading descriptors and command data before the title has finished writing them, rather than the title really binding such V#s. So I am not proposing the null-base change on its own: it would only hide one symptom. I haven't found which write is missed yet. One candidate is data the title writes on the GPU, or after submission, that the driver reads on the CPU while recording.

AI-assisted analysis: yes.

[JJenkx]

A negative result for the hypothesis above. With APS5_DRAIN_ALL=1, which drains every packet and disables the batched recording path, the same random stops occur:

• exit 134 at 116 s with unaligned vertex buffer;
• exit 134 at 136 s with the PM4 header 0 stop, here with 6,078 DWORDs;
• one run reached its scheduled close at 199 s, exit 0.

All three ran with the same inputs. The build was main 474030e584 plus my local null-base vertex change, which only affects the zero-record V#.

So the batched recording path is not the cause. The data these stops read is not yet written by some other route. Candidates I have not tested are writes on another queue, and guest CPU writes that land after the submission is read.

AI-assisted analysis: yes.

[JJenkx]

More on the PM4 stop. These used local diagnostic prints at the rejection, not part of any PR, on main 381891927c. That is the version with the descriptor force-sync retries; three runs on it still showed both stops and one clean run.

The rejected submission is not empty. In one run it was 4,228 DWORDs at guest 0x2028b2f218, with 3,704 of them nonzero. It starts with 70 zero DWORDs. Valid packets follow from DWORD 70, beginning c0004600 00000407 (EVENT_WRITE). The later zero runs are zero fields inside packets.

Not a late write. The copy and guest memory agree at the rejection, and the guest memory is unchanged 5 ms later. The driver copies and validates synchronously inside the submit call, so the title submits it like that. In another run the submission was 3,958 DWORDs, 3,522 nonzero, also with a zero prefix.

This is the pattern in the "PM4 type-0 packets" debt entry, which xXPBSXx recorded for PPSA15246: zero header DWORDs ahead of valid packets. What the console's command processor does with them is still unverified.

With #11346 merged onto the same main (head 15a4f95d4d), which reads an indirect buffer when execution reaches it, two of three runs reached their scheduled close at 237 s and one stopped at 114 s on unaligned vertex buffer. main alone is clean in about one run of three, so three runs show no clear difference.

AI-assisted analysis: yes.