Astro Bot (PPSA21564)

[DotDebian]

Tested

• Title: Astro Bot, PPSA21564, v01.007.000
• Host: Windows 11, Intel Core Ultra 9 285K, RTX 5080. Relinked with --windows --to-intel.
• Last update: 2026-10-02

Status

Not in game on Windows. With the stacks below, the title resolves all its imports, reaches main(), loads fonts and configuration, finishes PlayGo, creates the Vulkan device, compiles shaders and submits frames. It then stops within about 10 seconds on blocker A or B. The updates below give the cause of both, and the first frames on screen.

On Linux, the public astrobot integration branch reports the tutorial as playable.

Open blockers

	Stop	Seen
A	shared mapping outside the guest arena	2 launches out of 4, within the first 2 seconds
B	Access violation on guest thread SceSndzAudioOutMain	2 launches out of 4, about 10 seconds in

No open issue or pull request mentioned either of them when this was posted. Not established at that point: whether they are specific to Windows, to Intel hosts or to this version of the title.

A and B as first observed

A. Thrown at core/libs/prx/libc/src/GuestArena.cpp:177, before any output on stdout; the process aborts. The check is on main. Not established: whether #286, which touches GuestArena, plays a part (without it the title stops earlier, so the two could not be compared). Hypothesis: an address space layout that varies between launches, like the VirtualAlloc fixed failed of stack 1.

B. Always in the same loop: an audio mixing loop in the title's own code, with no system function in the captured call stack. The loop takes its destination pointers from a table on the stack, and that table does not hold valid buffer addresses. Seen once as a write to 0x7ce1aeb3d7, once as a read at 0x4000. Not established: who fills that table. Candidates: the audio libraries the thread calls earlier (libSceAudioOut, libSceAudioPropagation, libSceAcm, libSceAjm) returning wrong buffers, or, unverified, a wrong result from one of the 94 EXTRQ instructions the relinker replaced with stubs for --to-intel.

Stops on main before A and B, in the order they are hit

Stop	Covered by
Failed to load module libSceJpegDec.prx	#296
24 unresolved imports: libSceAudioPropagation (16), libSceAudioIn (3), libSceNpSessionSignaling (2), libSceContentExport, libSceShare, libScePlayerInvitationDialog	#289
sceKernelSyncOnAddressWait, sceKernelSyncOnAddressWake, imported by the libc.prx (SDK 9) shipped with the title	#349
sceKernelMapNamedFlexibleMemoryInternal, same libc.prx	#355
Non-fixed mapping address hints are not implemented	#286

Stacks tried

1. main + feat(libSceJpegDec): implement JPEG decoding #296, feat(libs): declare missing AudioPropagation, AudioIn, NpSessionSignaling and dialog exports #289, feat(libkernel): support mapping address hints and no-overwrite fixed mappings on Windows #286, fix(videoout): read the open param as the service thread's priority and affinity #297, feat(libScePad): implement scePadSetTiltCorrectionState #287, feat(libSceAgcDriver): back the global data share with driver-owned guest memory #285, feat(libkernel): implement sceKernelSyncOnAddressWait and sceKernelSyncOnAddressWake #349, and a local stand-in for the function feat(libkernel): implement sceKernelMapNamedFlexibleMemoryInternal #355 now implements. The title starts drawing. Three runs gave three different stops:
   • sceAudioPropagationSystemQueryMemory not implemented
   • compute shader ...: AGC driver: guest memory is not readable at 0x30
   • VirtualAlloc fixed failed (core/libs/prx/libkernel/DirectMemory/DirectMemory.cpp:95), seen once, after adding feat(libSceAgcDriver): back the global data share with driver-owned guest memory #285
2. The astrobot branch (eeda258c, 253 commits ahead of main) + feat(libSceJpegDec): implement JPEG decoding #296, feat(libkernel): implement sceKernelSyncOnAddressWait and sceKernelSyncOnAddressWake #349, feat(libkernel): implement sceKernelMapNamedFlexibleMemoryInternal #355, feat(libkernel): support mapping address hints and no-overwrite fixed mappings on Windows #286 and feat(libs): declare missing AudioPropagation, AudioIn, NpSessionSignaling and dialog exports #289 without its libSceAudioPropagation file. This goes furthest and gives blockers A and B.

[DotDebian]

Update 2026-10-02: both blockers have a cause

Same host and stack 2 as above.

• A (shared mapping outside the guest arena): when Windows has already placed a private region low in the address space, the guest arena moves off its usual base and the title's fixed-address mappings fall outside it. 3 launches out of 30. Covered by fix(libc): reserve the guest arena at its fixed range around what Windows already placed in it #231, not run here yet.
• B (crash on SceSndzAudioOutMain): when a write fault on a write-protected shared view is resumed, Windows overwrites the bytes just below rsp, where System V leaf functions keep their locals. This is on main and not specific to the title. Now tracked in Windows: resuming a write fault overwrites the guest red zone when AVX state is live #361.
• With B bypassed by a local diagnostic, a window opens and stays black, and the run stops after about 32 to 34 s.

A in detail

• The title maps direct memory at fixed addresses: 0x300000000, 0x400000000, 0x500000000, 0x1000000000, 0x10c8000000.
• 30 launches with the arena range printed: 3 stops, each one with the arena moved off 0x200000000 (to 0x1200000000 or 0x2200000000) because a private region that Windows had placed before libc.prx loads sat below 0x1e00000000. The other 27 kept the base, with the arena ending at 0x7200000000 (full size), 0x3a00000000 or 0x1e00000000.
• Deterministic reproduction: start the process suspended, reserve one page in it with VirtualAllocEx, resume. A page at 0x200000000, 0x800000000 or 0x1b00000000 gives the stop on every launch; a page at 0x4000000000 does not.
• feat(libkernel): support mapping address hints and no-overwrite fixed mappings on Windows #286 plays no part: the constructor that picks the base is unchanged by it.
• fix(libc): reserve the guest arena at its fixed range around what Windows already placed in it #231 describes the same cause and keeps the arena at [0x200000000, 0x7200000000) around what is already there.

B in detail

• The faulting function (eboot +0xec6090) is a System V leaf: it keeps locals at [rsp-0x08] .. [rsp-0x31] without moving rsp. It also stores into a ring buffer that lives in direct memory.
• Direct memory is mapped as section views. WindowsMappings::Collect write-protects collected views, and the vectored handler (CrashReport.cpp, GuestArenaHandleWrite) restores the protection and returns EXCEPTION_CONTINUE_EXECUTION.
• Windows delivers the exception on the faulting thread's own stack, directly below rsp. There is no red zone in the Windows ABI. When the thread's AVX state is live, the kernel writes the upper halves of ymm0-ymm15 (0x100 bytes) at the top of that frame; measured, they start rsp mod 64 bytes below rsp. The function resumes with its locals replaced.
• With clean AVX state the first 0x120 to 0x140 bytes below rsp are left alone (the reserved, unwritten extended-state area), which is why code without live ymm registers survives.
• Evidence, with every resumed exception recorded per thread: in 3 of 3 captured crashes the last resumed write fault on the crashing thread was at the same rsp as the crash, a few instructions away (+0xec61e1 then +0xec64ab or +0xec64b5; +0xe46400 then +0xe4636d). In the +0xec64ab case rsp mod 64 is 8 and [rsp-0x10], the saved rbx, reads back as 0.
• With views never write-protected (a local diagnostic that makes Collect report them as untracked, so callers compare bytes), 4 of 4 launches ran past that point (31 to 60 s). This is a diagnostic, not a proposed fix.
• The SSE4a emulation in the same handler resumes an exception on the guest stack in the same way.
• Not established: which fix fits the project. The fault has to be avoided rather than handled, since the bytes are gone before any handler runs.

Standalone reproduction with no AnyPS5 code (redzone.cpp, MinGW-w64 GCC 15.2, g++ -O1): the source is in #361. Its output:

no fault: nothing below rsp changed
byte write faulted and resumed: 197 of 512 qwords changed, the nearest at rsp-0x140
ymm write faulted and resumed: 229 of 512 qwords changed, the nearest at rsp-0x40

Seen once B is bypassed with the diagnostic

• A window opens (ASTRO BOT | FPS: 0.00), black at 20 s.
• compute shader 0x...: AGC graphics: guest snapshot differs from registered memory, 2 of 4 launches at about 32 s (GuestBufferMemory.cpp:1603, astrobot branch). Not established: whether the diagnostic causes it.
• With APS5_NO_SNAPSHOT_CHECK=1: sceAvPlayerAddSource (built without FFmpeg) not implemented at 34 s. ANYPS5_ENABLE_FFMPEG defaults to off on Windows in that branch.

Investigated with AI assistance (Claude Code).

[DotDebian]

Update 2026-10-02 (2): runs for minutes with sound, frames still black

The next update corrects this one: the black frames came from a local diagnostic, not from the title.

• With FFmpeg enabled and three local diagnostics, the title now runs for 75 to 200 s: it loads its assets at about 2 FPS, starts its first video at about 150 s, and the logo sound is audible. Every presented frame is black.
• New blocker C: guest texture descriptor starts past the surface's last mip level, hit once per frame from about 35 s. It is on main, with no open issue or pull request.

The three local diagnostics (none is a proposed fix)

• Shared views never write-protected, to avoid blocker B (callers compare bytes instead).
• APS5_NO_SNAPSHOT_CHECK=1.
• A storage descriptor whose base level is past MAX_MIP bound to the last existing level, see C.

Where it gets to

• 5 launches of 75 to 200 s. The title opens /app0/data/prein/video/ps_studio_armadillo.mp4 and at about 150 s starts binding 3840x3240 R8 video frames. One reading after that point gave 0.29 FPS.
• Black frames: mean 0 over the first 300 frames (APS5_DUMP_FRAMES). The dumps stop about where the video starts, so the video frames themselves were not seen.
• Not established: whether the black frames and the frame rate come from running without write tracking.
• Two launches ended on their own: vkAllocateMemory device buffer: Vulkan result -2 at 186 s, and at 191 s an access violation on a queue worker (read of 0x10 inside libstdc++-6.dll, called from libSceAgcDriver.prx, right after WAIT_REG_MEM_64 ... timed out after 1000ms). The other three were stopped by the harness.

C in detail

GuestTextureResource.cpp:132.

• The descriptor is a storage binding of a compute shader, one element, with a store in the shader: 1920x1080, format 71, tile 27, BASE_LEVEL = LAST_LEVEL = 6, MAX_MIP = 5. Two surfaces alternate from frame to frame (0x560040000, 0x55ea00000).
• Not established: whether the shader executes that store. A downsampler that declares one destination per mip and binds all of them, whatever the surface holds, would produce this binding without ever addressing the level.
• For comparison, resolveImageBinding already clamps the dynamic-mip storage elements: std::min(resource.baseLevel + mipOffset, resource.mipCount - 1u).
• Two general ways out, neither started: decode such a view as naming no level and bind a placeholder that never reaches guest memory, with a recorded fault if the shader does access it; or clamp to the last level as the line above does, which writes into a real level if the store runs.

Smaller points

• FFmpeg on Windows in the astrobot branch (core/libs/FFmpeg.cmake, not the build in feat(avplayer): decode H.264 and AAC with FFmpeg #307): with ANYPS5_ENABLE_FFMPEG=ON and MinGW-w64, libSceAvPlayer.prx fails to link on BCryptOpenAlgorithmProvider, BCryptGenRandom and BCryptCloseAlgorithmProvider; adding bcrypt to anyps5_ffmpeg on WIN32 fixes it. Built with Git's sh, MSYSTEM=MINGW64 and mingw32-make.
• The runtime SSE4a emulation was not exercised in a 35 s traced run: 0 instructions emulated; the relinker had lowered 94 EXTRQ.
• feat(libkernel): implement sceKernelMlock #359 implements sceKernelMlock, imported by the title's libc.prx but not called by it.

Investigated with AI assistance (Claude Code).

[DotDebian]

Update 2026-10-02 (3): first frames, and a correction to the update above

• Correction: the black frames reported above came from my own diagnostic, not from the title. The guest snapshot differs from registered memory stop and the access violation inside the driver were only seen with it: treat them as unconfirmed. Blockers A, B and C stand as described.
• B does not occur with APS5_NO_WRITE_WATCH=1, at the cost of the byte comparisons that replace the tracking.
• First frames: the window shows Sony Interactive Entertainment presents at 60 s, then the opening cinematic from about 180 s, at 1.6 to 1.9 FPS. Colours are wrong in the cinematic. Device memory runs out after about 8 minutes.

Open, in order

1. A: fix(libc): reserve the guest arena at its fixed range around what Windows already placed in it #231.
2. C: the storage descriptor whose base level is past MAX_MIP, on main, no issue or pull request.
3. B: avoided by the switch at the cost above; the cause is still there for the default configuration.
4. Device memory exhausted after about 8 minutes.
5. Colours in the cinematic.

How the correction was checked

The diagnostic reported shared views as untracked while private memory stayed write-watched. Checked with Dreaming Sarah (PPSA02929) on main (e1654a97 plus #359):

Run	Result
default	frames rendered, 60 FPS
APS5_NO_WRITE_WATCH=1	frames rendered, 38 FPS
that diagnostic	black frames, 41 FPS

The two unconfirmed stops did not appear in the two launches described below.

Why the switch avoids B

Without write watching CollectWrites returns before WindowsMappings::Collect, so no view is ever write-protected and no write fault is resumed on a guest stack. Two launches of 240 s and 498 s, no crash on SceSndzAudioOutMain.

The runs that showed frames

Stack 2, FFmpeg enabled, APS5_NO_WRITE_WATCH=1, and one local diagnostic left: the storage descriptor of blocker C bound to the last existing level.

• Colours in the cinematic are blue and posterized; the title card is correct. Not established: whether the diagnostic for C causes that.
• 1.6 to 1.9 FPS after the first minute.
• The 498 s launch ended on vkAllocateMemory device buffer: Vulkan result -2 after about 830 frames, preceded by skipped draws and color targets left non-resident for the same reason (RTX 5080, 16 GB). The 240 s launch was stopped by the harness.

Investigated with AI assistance (Claude Code).

[DotDebian]

Blocker B (the red zone overwritten when a write fault is resumed on Windows) now has its own issue, since it is on main and not specific to this title: #361. It carries the mechanism, the standalone reproduction, the cost of APS5_NO_WRITE_WATCH=1 and the possible directions, with none chosen.

Written with AI assistance (Claude Code).

[oneandonlydean]

Great write-up, thanks for digging into the Windows side. My astrobot branch is Linux-only so far (CachyOS, RTX 4090, i9-14900KF with --to-intel), so I can't confirm any of this on Windows, but several of your blockers have changed on the branch since eeda258c. It is now at a58477db, 53 commits later, level with upstream main as of e1654a97.

Here is a Linux gameplay capture from last night, through the intro cinematic, the crash site tutorial and the world map into Sky Garden: https://www.youtube.com/watch?v=62wl_LddNnQ. It was recorded before most of the fixes below, so frame rate and visuals are better now.

Relevant to your list

• C (descriptor base level past MAX_MIP): fixed on the branch, and it is not a clamp. On RDNA2 a level past MAX_MIP is addressed like any other level: for that 1920x1080 RGBA16F SW_64KB_R_X surface, a 6 and a 7 level chain have identical offsets for levels 0 to 5, and level 6 lands in a mip tail slot (checked against Mesa addrlib). The branch now extends the chain over the same guest bytes when the allocation and tail are unchanged, and still throws otherwise (9de1ac28, 6c95f529). In PPSA21564 that dispatch is the last step of two bloom downsample chains and stores level 6, which nothing reads back, so binding the last level as your diagnostic does writes over a real level.

• Device memory exhausted after about 8 minutes: the old sampled and storage texture caches had a fixed 2 GiB LRU budget that thrashed in long scenes, and nothing reacted to the real VRAM budget. a58477db takes its limits from VK_EXT_memory_budget, evicts by age (never a texture used in the current frame), and on VK_ERROR_OUT_OF_DEVICE_MEMORY evicts and retries once. On Linux this cut texture rebuilds in a long intro run from about 52k to 3k, and Sky Garden went from 0.4 to about 2 FPS. With 16 GB it should matter even more for you.

• Colours in the cinematic: several things that changed the image landed overnight:

  • flips now complete only after the frame's GPU work (2ce680c9). Before that the title reused per draw constants the GPU was still reading, which gave exploded geometry, flat colour frames and runaway shader loops;
  • samplers selected by control flow are split per edge instead of skipping the draw (91807571);
  • native depth bounds and colour targets with gaps (e57b0ac0, 806851ea), which brought back lighting passes that were being skipped.

  I would retest the cinematic on the current head before chasing colours further.

• FFmpeg on Windows: the branch's AvPlayer still builds its own FFmpeg and defaults it off on Windows. My upstream feat(avplayer): decode H.264 and AAC with FFmpeg #307 moves the decoder to main's shared ffmpeg target, and its CI passes the AvPlayer test on MinGW, so that may be the easier route there.

• A and B: nothing new from me. On Linux write tracking goes through userfaultfd, so the resumed fault on the guest stack from Windows: resuming a write fault overwrites the guest red zone when AVX state is live #361 does not happen there.

Tips for testing

• Settings my runs use: APS5_TWO_LANE=500597a00 APS5_INEXACT_SINGLE_LANE=500597a00 APS5_LOOP_GUARD=2000 APS5_TOLERATE_DISPATCH_FAILURES=1. The first two pin one wave64 compute program to layouts that avoid an NVIDIA spill hang I hit on the 4090; the 5080 is also NVIDIA, so it may well apply to you too.
• Skip the intro: the title has a built in -lvl <level file> argument, e.g. -lvl underwater_aerial_garden or -lvl hub_crashsite, with the level list in app0/data/prein/product_levels.xml. It needs the relinker fix eeda258c ("hand the guest the real argv on Linux"); I only fixed and checked the Linux entry stub, so the Windows stub may need the same change.
• Copyright line on the title screen: the branch can open the PS5 system font sets from a folder (ANYPS5_SYSTEM_FONTS, 447004e1). Noto Sans and Noto Sans CJK work as stand-ins for SST.
• Frame rate: expect a slow intro either way. The game advances its logic once per presented frame, so below 60 FPS everything runs in slow motion rather than dropping frames.

Happy to compare logs if you try the newer head.

[Raghuramcoding]

If you release this and Gran Turismo I will not need a PS5 PLS add GT7 support in the future after astros playroom. Add them all

[Raghuramcoding]

I understand this is very difficult and hard and may takes months to years to complete

[SP4C3B4R-8]

Windows: in game, Gorilla Nebula first level reached

Thanks to @oneandonlydean: the rendering and gameplay progress below is the work on his astrobot branch; what I added are the Windows fixes it needs to run there.

• Host: Windows 11, AMD CPU, RTX 5070 Ti, MinGW-w64 GCC 15.2.0.
• Stack: Dean's astrobot branch (9121abe) plus four Windows fixes, without which it stops ~17 s after start: fix(libSceAgcDriver): prefer a discrete GPU over the first suitable device #282, fix(libSceFiber): fix fiber stack switching under write tracking on Windows #283 (two commits), fix(libSceAgcDriver): destroy host imports of a replaced Vulkan device #284. Branch: https://github.com/SP4C3B4R-8/AnyPS5/tree/astrobot-windows
• Run with APS5_HOST_IMPORT_MIB=20480 APS5_NO_SNAPSHOT_CHECK=1. Without the second one, choosing a save slot stops with guest snapshot differs from registered memory.
• Result with a DualSense: boot videos, title, save selection, Crash Site tutorial completed, controller ship into the Gorilla Nebula, flying into its first level.
• Performance: 5-10 fps, about 0.1 fps once that first level appears. No crash: I stopped it myself in the level because of the frame rate. Not profiled yet.

Video: galaxy map, Sky Garden, the dive and the flight into the level, with the log console beside the game window. About 41 s of the white cloud transition are cut and the recording is re-encoded to fit the 10 MB attachment limit, so it is softer than the original 1440p capture.

astrobot-windows-8bit.mp4

Written with AI assistance (Claude Code).

[Raghuramcoding]

Error in video, video cannot be played. says file is corrupt, can you fix that

[SP4C3B4R-8]

@oneandonlydean thanks for pulling #282, #283 and #284 into astrobot. With that, Windows users can build your branch directly, and I'll point my fork's astrobot-windows branch at yours instead of keeping a separate stack.

I'll run both of your requests on your current head:

1. Snapshot stop at the save slot: without APS5_NO_SNAPSHOT_CHECK=1, and I'll post the lines before the stop with the range and the resource it names.
2. ~0.1 fps in the first level: a few seconds with APS5_PROFILE_DRAW=1 in the level, so we can see whether it's write-protect faults on the section views, the snapshot work, or something else on the queue 0 worker.

I'm away until Wednesday 7 October: I'll run both on Wednesday afternoon or evening, Thursday at the latest. Sorry for the wait.

@QDarkRex about blocker B not showing up here: my CPU is a Ryzen 7 7800X3D with AVX-512 enabled. Your redzone.cpp overwrites from about rsp-0x650 here, far out of reach of the leaf's locals, which confirms your guess. Details in #361.

@Raghuramcoding thanks for flagging the video. It isn't corrupt, but it is 10-bit H.264 (High 10), which browsers can't decode. The comment above now has an 8-bit version, which should play in the browser.

Written with AI assistance (Claude Code).

[oneandonlydean]

Thanks, this is great to see, and thanks for the Windows fixes. I've brought #282, #283 and #284 into my astrobot branch at their current heads, so it should now run on Windows without the extra branch (your commits, authorship kept).

The branch has moved on since 9121abeb (now d2a5d103), with two changes that matter on Windows:

• 4419104d: a driver CPU store that lands in a host heap or thread stack inside the arena range no longer throws collect private guest writes on Windows (the arena range there can include regions that were in use before it was reserved).
• f65102e3: the cross-queue ordering from 9121abeb could hold queue 0 until the 1 s WAIT_REG_MEM give-up when the label it waited on came from somewhere other than the held submission; that hold is now released whenever queue 0 can't go on without it.

Also new: the occlusion dumps no longer drain the GPU (Snowy Canyon went from 1.2 to 2.3 fps on Linux), and on Linux the queue workers are pinned to P-cores on hybrid CPUs. That is off on Windows unless APS5_WORKER_AFFINITY=1, and it does nothing on a non-hybrid CPU like yours.

Two things I can't reproduce on Linux and would like to understand:

1. The guest snapshot differs from registered memory stop at the save slot. Could you try the current head without APS5_NO_SNAPSHOT_CHECK=1 and post the lines just before the stop (the range and the resource it names)? On Linux that check never fires, so I suspect a write the Windows tracking misses, possibly the same mechanism as Windows: resuming a write fault overwrites the guest red zone when AVX state is live #361.
2. About 0.1 fps in the first level. On Linux that level runs at about 3 fps on an i9-14900KF and is bound by the queue 0 worker's CPU (about 5,800 draws a frame). 0.1 suggests something Windows-specific on top: write-protect faults on the section views, or the work APS5_NO_SNAPSHOT_CHECK=1 puts back. A few seconds with APS5_PROFILE_DRAW=1 would show where the worker's time goes.

[QDarkRex]

Windows on an AMD GPU (Radeon RX 9060 XT): title card, blocker B in every launch with write watching on

• Title: PPSA21564 v01.007.000, dumped from my own console.
• Host: Windows 11, Ryzen 7 5700X (Zen 3), Radeon RX 9060 XT (RDNA4, 16 GB), AMD driver 26.9.2, MinGW-w64 GCC 15.2.0. Relinked with --windows only: no --to-intel, so the image has none of the EXTRQ stubs.

Run	Build	Settings	Result
1	upstream main 9f9a8f5	default	stops at 40 s, before the first flip: compute shader ...: AGC graphics: unsupported descriptor role Gds (GDS support is only on astrobot, 94eca93)
2	astrobot 159b633 (includes #282–#284, 4419104, f65102e)	default	black window, then blocker B at 95 s: 0xc0000005 on SceSndzAudioOutMain, rip eboot+0xec64b5, write
3	same	APS5_NO_WRITE_WATCH=1	no crash in 240 s; "Sony Interactive Entertainment presents" renders correctly at 1.2 FPS; ps_studio_armadillo.mp4 opened
4	same	APS5_HOST_IMPORT_MIB=20480 APS5_NO_SNAPSHOT_CHECK=1	blocker B at 35 s: rip eboot+0xec64ab, read of 0x4000

Run 3 on the Radeon: the title card, 272 frames in, at 1.19 FPS. It stayed on this card until I stopped the run at 240 s; the title advances once per presented frame, so the video it had opened was not reached on screen.

• B here is the same as DotDebian's (+0xec64ab / +0xec64b5, the read at 0x4000), so Windows: resuming a write fault overwrites the guest red zone when AVX state is live #361. It happens without --to-intel on an AMD CPU, which rules out the EXTRQ stubs, and it hit 2 of 2 launches with write watching on. SP4C3B4R-8's runs with the same fixes did not report it, so it may depend on the host.
• No GPU-specific stop so far. Separately, the wave32-on-64-lane-subgroup issue in Wave32 pixel shaders read the wrong half of a 64-lane subgroup on AMD (agc_driver_pixel_helper_lanes fails on RDNA4) #487 applies to this card.

B reproduces on every write-watched launch on this machine, so I can test a fix for #361 quickly if that helps.

Tested with AI assistance (Claude Code).

[oneandonlydean]

@QDarkRex thanks for the AMD run, that's a useful data point. Blocker B on every write-watched launch, on an AMD CPU and without --to-intel, fits #361 being host-dependent rather than tied to the EXTRQ stubs. I'm on Linux only so I can't reproduce it, but if a fix for #361 goes up, your machine is the best place to confirm it, so I'll mention you there.

On #487: #587 (isolate wave32 operations in wide host subgroups) was merged today and may cover the wave32 on 64-lane subgroup issue on your card. If you get a chance, agc_driver_pixel_helper_lanes on current main would tell.

[ThisIsAkill]

PPSA21567 (the other region's release) on the astrobot branch

Hi @oneandonlydean, I've been working on Astro Bot from the other side: PPSA21567 v01.018 on Linux (RTX-class NVIDIA, Xvfb), so far on upstream main plus open PRs (#426's stack). Your branch gets much further, so I'm moving my work onto it instead of solving the same things twice.

astrobot 159b633 as-is on PPSA21567 (Linux, virtual display, fresh shader cache, Return pressed every 15 s for Cross):

Run	Settings	Result
1	default, no input	Logos, title ("press any button") by about 140 s; idle there to 560 s. No error, no GPU hang.
2	default	Title, NEW GAME save-slot menu, warp. Then it stops: compute shader 0x500622100: AGC graphics: guest snapshot differs from registered memory. That's the same stop SP4C3B4R-8 hit on Windows.
3, 4	APS5_NO_SNAPSHOT_CHECK=1	Both run the full 15 min into the intro cinematic (the mothership, Nebulax's attack, the ship breaking up). No error, no GPU hang, no skipped draws.
5	as 3 and 4, 35 min	Through the intro cinematic to the crash landing in the desert (Crash Site), then waiting in the tutorial with a controller icon in the corner (no stick input sent). No error, no GPU hang.

So PPSA21567 v01.018 needs nothing region-specific on top of your branch to get this far. On upstream main it hung the GPU (Xid 109) a few minutes in, inside a heavy compute shader. Your e6ff9656 explanation (two-lane register pressure, spilling) fits everything I'd measured, including why a loop guard that never trips made the hang go away.

What I have that the branch lacks (on my branches built on upstream main, #419 and #425; none merged; each with tests):

1. Exact colour compare emulation. For a colour image bound to a comparison sampler, it does the compare in the shader the way the hardware does: per texel, before filtering, including clamp-to-border with black and white borders. Currently the result there is left to the driver (1ad8fe93). Unsupported formats, clamp modes, the border colour table and aniso still throw.
2. Single-sample CMASK fast clear. It models the two fill values: CMASK 0 is "cleared to the CB_COLOR_CLEAR_WORD value", and 0xFFFFFFFF is "expanded". It's not rendered uncompressed. Anything else throws. Scoped as MichonGoddijn231849 asked on feat(agc): multisampled color and depth targets with CB resolves #419.
3. Depth layout matching / write-back. A colour or storage view of memory a depth surface holds is served from the depth surface in the view's layout: it's written back through an R32 plane view and reloaded. That replaces a stale read. This is the proposal on feat(agc): depth surfaces read as textures and storage images #425; you raised there that the refusal should stay for the case without write-back.

How would you like contributions: PRs against your astrobot branch, or upstream PRs you then pull in? I'd start with whichever of the three you find most useful.

[ThisIsAkill]

@oneandonlydean the exact colour compare emulation, ported onto astrobot, is here: https://github.com/ThisIsAkill/AnyPS5/tree/fix/agc-emulated-color-compare-astrobot (one commit on top of 159b633; no PR).

• What it does: a sample_c / sample_c_lz on a colour texture that isn't natively comparable is compared in the shader the way the hardware does. It fetches red, applies wrap, clamp-to-edge or clamp-to-border (black and white borders), compares per texel, then blends the four comparisons for bilinear. R32 float and R16 unorm keep the native depth path.
• Out-of-scope cases keep your fallback from 1ad8fe93 (the colour image under the comparison sampler), with a one-time log per reason. Those are: other formats or view types, gradients or an explicit LOD, bias, offsets, LOD clamps, gathers, bindless tables, mirror or half-border addressing, the border colour table, aniso, mip filtering, and samplers that disagree. The choice is made per image before emission: the resource tracker now records each compare-sampled image's sample flags. Integer formats still meet the general path's existing refusal.
• Cache: FormatVersion 8 -> 9, with the new digests recorded in agc_shader_disk_cache.
• Tested on PPSA21567, APS5_NO_SNAPSHOT_CHECK=1, virtual display. It reaches the Crash Site tutorial (through the intro cinematic and the crash landing), with no skipped draws and no fallback hit; one earlier run of this commit stopped out of GPU memory just before the crash landing, which the unmodified branch also does on this 8 GB RTX 3070 (it peaks at about 7.2 GB there). The format 56 texture now goes through the emulation, so your fallback's log line for it is gone. Tests: the new agc_driver_emulated_color_compare (CPU reference for point/bilinear, edge/wrap/border, plus the fallback cases) and the full ctest pass, apart from guest_standard_streams, guest_memory and guest_system_font. Those three fail identically on unmodified 159b633 in my local build, which links libc with -Bsymbolic, and all three pass in a default build of 159b633. So they come from my build option, not from the branch or this commit.

I'm away for about a month from today. You're welcome to take it as-is, adapt it, or PR it upstream yourself, whichever suits the branch. The single-sample CMASK model waits until I'm back.

[oneandonlydean]

Thanks @ThisIsAkill much appeciated

[ThisIsAkill]

Two measurements from PPSA21567 on astrobot 159b633, Linux, RTX 3070 (8 GB), virtual display unless noted, APS5_NO_SNAPSHOT_CHECK=1:

Internal resolution. I added a local counter (not pushed) that logs, every 2 s, the colour-target and viewport sizes of the draws and the pixel programs drawing into 3840x2160 targets.

• In the title, the menus and the intro cinematic (about 15 min of one run, through Nebulax's attack), the main scene renders into 1920x1080 targets with full 1920x1080 viewports every minute. Smaller 2432x1368 and 960x540 targets also appear.
• The 3840x2160 output is drawn by pixel program 0x500782900, from a 1920x1080 scene. So the picture is upscaled 2x from 1080p. That's consistent with the game's resolution choice (it measures GPU time, 97e9a3e6) sitting at its floor on this GPU, but I didn't trace the choice itself.
• About 9 fps in the title and menus, 3 to 5 fps in the cinematic.
• Gameplay wasn't reached in the traced run, so I have no gameplay figure. I didn't get to APS5_GPU_TIMESTAMP_SCALE.
• The game imports sceKernelIsTrinityMode and sceAgcGetIsTrinityMode (both return 0 in AnyPS5), and its binary has PSSR, FSR and checkerboard upscale stages. I haven't traced which one runs.

Out of device memory on 8 GB. GPU memory (nvidia-smi, desktop about 0.5 GB included) climbs to about 6.8 GB in the cinematic and peaks at about 7.2 GB at the crash landing. Results of today's long runs (35-minute tests plus one play session), all on this branch, leaving out one real-display run that ended in a GPU hang (Xid 109) instead, 9 in all: 3 unmodified, 4 with my compare commit and 2 with the local counter. Neither of those adds GPU allocations of its own. Both kinds of result happen in each group:

• Ran the full 35 min without an error: 5 runs (1 unmodified, 3 compare, 1 counter), 4 of them checked to the Crash Site tutorial.
• Stopped with vkAllocateMemory ... Vulkan result -2 (VK_ERROR_OUT_OF_DEVICE_MEMORY): 4 runs (2 unmodified, 1 compare, 1 counter).
  • At about 19 min, just before the crash landing: one virtual-display run, and one real-display play session (fullscreen, APS5_HOST_IMPORT_MIB=6144). The fatal allocations were in compute shaders 0x500797d00 and 0x5007d2800. In the play session the first failure was a 10 MB staging shadow, after about 49k refused host imports.
  • At 6.5 min, virtual display (compute shader 0x5005a5400: vkAllocateMemory storage texture, 7.9 GB).
  • At 9.5 min, real display, APS5_HOST_IMPORT_MIB=4096 (compute shader 0x50740a700: vkAllocateMemory texture).

So on an 8 GB card the margin from the intro to the crash landing is a few hundred MB. Each run either fits or doesn't.

[Raghuramcoding]

https://www.youtube.com/watch?v=zv_gRGT1dAQ

[ThisIsAkill]

@oneandonlydean one region-specific blocker on PPSA21567 (v01.018), relevant to #476.

Without my -Bsymbolic libc build option, astrobot doesn't start PPSA21567 at all. Unmodified 159b633, default configuration, Linux, launched twice. Both launches crash within about 2 s with exit 139 (SIGSEGV), before the first log line:

app.elf: segfault at 0 ... error 6 in libc.prx.guest.prx[7d35, ...]

The faulting address is the same offset (+0x7d35) in the title's bundled sce_module/libc.prx both times. It matches the #476 problem: the title ships its own libc.prx, and the host libc's references bind to the guest copy's exports. On upstream main I traced the same startup crash to that binding (a NULL memcpy destination in the guest libc, reached from puts, through _Stdout); on astrobot I haven't traced it, only matched the symptom.

With libc linked -Bsymbolic (a local build option, see #476), the same commit boots, and on PPSA21567 reaches the Crash Site tutorial. The cost of that option is three tests that then fail (guest_standard_streams, guest_memory, guest_system_font); all three pass in the default build.

Does PPSA21564 bundle sce_module/libc.prx too? If it doesn't, that would explain why the branch never hit this.

[ThisIsAkill]

@oneandonlydean a quick question about where I can help most. I test on a mid-range PC: Ryzen 5 5600X, RTX 3070 8 GB (NVIDIA 615.71), CachyOS, with PPSA21567 (v01.018) on your astrobot branch. There it reaches the Crash Site tutorial at about 9 fps in the menus and 3-5 fps in the intro cinematic. Its main problem on this card is running out of GPU memory around the intro's texture burst, in some runs.

Which of these would be most useful to you?

• Memory / out-of-memory work on 8 GB cards (the feat(agc): host import windows, least-recent eviction under the budget, recoverable GPU out-of-memory #290 relief plus the texture caches; I have a local prototype I'm measuring now).
• CPU performance profiling (perf and flame graphs of the queue worker over the intro, to find the hottest per-draw costs).
• Testing later levels on PPSA21567 and reporting what breaks.
• Region differences between PPSA21567 and PPSA21564 (like the bundled libc.prx).

Happy to go with whatever you'd rank first.

[oneandonlydean]

@ThisIsAkill thanks for all of this, and sorry for the slow reply.

Bundled libc.prx: PPSA21564 ships sce_module/libc.prx too, but in my setup it never loads: only libSceNpCppWebApi.prx is relinked into a .guest.prx, and the host libc serves every libc import. That's why the branch never hit the #476 crash.

Contributions: upstream PRs, please. The astrobot branch pulls upstream in regularly, so anything merged there reaches it, and everyone else gets it too. If something only makes sense on the branch, a link to a branch like the colour compare one is fine.

Where you'd help most, in order:

1. Memory on 8 GB cards. I can't test that here (24 GB), and your numbers show the margin is only a few hundred MB. Anything that cuts the intro's peak is very welcome.
2. Region differences between PPSA21567 and PPSA21564, like the bundled libc.
3. Later levels on PPSA21567: what breaks and where.

Level select: you don't need to play through to reach later levels. The astrobot branch has one: run with APS5_LEVEL_MENU=1, press F2 in game, filter the game's level list, and Enter restarts straight into the chosen one through the game's own -lvl argument (the relinker fix for that is #418, on main). APS5_LEVEL_MENU_AUTOSELECT=<seconds>:<level file> picks one automatically, which helps for unattended runs. It's Linux only for now, since the restart re-executes the process.

CPU profiling I'm covering on this side: today's profile on the branch put the Snowy occlusion queries first, and that fix (+18% there) is already on astrobot.

The 1080p internal resolution measurement is useful, thanks; it matches what I see in the title.