Grand Theft Auto III – The Definitive Edition (PPSA03527)

[snoozedDev]

Existing thread

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

Title

Grand Theft Auto III – The Definitive Edition (PPSA03527)

Content version tested

01.007.000 (retail disc)

AnyPS5 commit

main af0fff7, plus #6236 (merged since), #6681 (head ce0b767) and #6814 (head 83eb3ed); the table under Current blocker says which stop each one gets past.

System tested

Linux (kernel 7.2.5), GCC 16.2.1, Release, -DANYPS5_ENABLE_SPIRV_TOOLS=ON, Ryzen 7 7700X, RTX 3090 (NVIDIA 610.57.04)

Furthest point

Stops before the first frame

What is shown

Black. With the PRs below the title runs with no stop for up to 1500 s. In the four runs with frame summaries it presented 900 frames in every 30 s summary interval after the first (p50 frame about 33.37 ms); the 900 s warm run counted 263,239 completed draws and 144 compute dispatches. Twelve screenshots taken through gamescopectl screenshot between 31 s and 510 s after launch, in two other warm runs, are all black (highest channel value 2 of 255); the same capture of glxgears in the same headless gamescope shows the gears. No input was given; audio and input were not tested.

Unreal Engine 4. The title ships libc.prx, libSceFace.prx, libSceFaceTracker.prx, libSceJobManager.prx, libSceNpCppWebApi.prx and libScePfs.prx in sce_module/. Its sce_sys/ has no PlayGo file.

Current blocker

No stop within 1500 s with two open PRs and one setting, but the picture stays black; I have not looked into why. This answers the request in #2010 ("If Cyberpunk 2077 or GTA III DE stops on main, please open an issue with the title ID and the log line"). Each stop already has a thread, so the data went there:

Stop, in order	Thread	What gets past it
1 to 2 s: scePlayGo: sce_sys/playgo-chunk.dat and sce_sys/playgo-scenario.json are missing, so chunk ID 1 cannot be checked	#6205	APS5_PLAYGO_UNLISTED_CHUNKS=absent (#6236, merged after af0fff7). With installed instead, the title runs out of memory at 19 s (Ran out of memory allocating 5565054976 bytes with alignment 65536), the same allocation as Sackboy and Horizon on #6236
main thread SIGSEGV at 0x800000021 about a second after the swapchain is created	#6681 (comment)	#6681: the bss tail shares a page with the next PT_LOAD and reads file bytes
SIGSEGV in LinkPipelineFromLibraries at the window attach, warm cache only	#6805, #6814 (comment)	#6814, or APS5_NO_LIBRARY_PREBUILD=1

How it was run

Converted with relinker --registry from the same tree. Run inside gamescope --backend headless -W 2304 -H 1296, no input, with APS5_PLAYGO_UNLISTED_CHUNKS=absent.

• Cold: 575 s of shader registration (about 3,550 shaders) before the swapchain, with nothing logged in between except the shader cache ticks. On the tree with fix(agc): drain library prebuilds before device replacement #6814, the swapchain came at 626 s (3,676 shaders) and the run went on to its 1500 s limit with no stop.
• Warm: with APS5_NO_LIBRARY_PREBUILD=1, the swapchain is created at 3 s. With fix(agc): drain library prebuilds before device replacement #6814, at 75 s, because the window attach now waits for the queued library prebuilds (details on fix(agc): drain library prebuilds before device replacement #6814).

AI-assisted: yes (Claude Code, Claude Opus 5.5), operating under my supervision; I am accountable for this report and will respond to review.

[pushkarreddyy]

I am taking this up to investigate the black-screen presentation and render pipeline in Grand Theft Auto III – The Definitive Edition (PPSA03527). I will reproduce the headless/warm runs with trace dumps to pinpoint why the 263,239 draws and presentations stay black (e.g. swapchain layout transition, color target clear/resolve, or format normalization).

[pushkarreddyy]

GTA III DE (PPSA03527): Initial Investigation & Diagnostic Findings

Following up on the report by @snoozedDev (263,239 completed draws and continuous presents with black frames):

I analyzed the presentation pipeline in core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp (PresentDisplayBuffer -> PresentableResident) and compared behavior across UE4 titles:

1. Resident Surface Miss:
   • In PresentDisplayBuffer(), when a flip buffer is presented, the driver calls Graphics::StorageTexture::FindPendingSlice(buffer.address, DisplayBufferSize(buffer)) to locate the active resident render target.
   • In Unreal Engine 4's render graph transient allocator, render targets are aliased dynamically across passes. If the display buffer's address does not match an un-evicted pending slice in the storage image table, resident is dropped to nullptr.
2. Fallback to Clear:
   • When resident == nullptr, VulkanDevice::PresentDisplayBuffer falls back to CompressedClearPixel or scaler->RecordClear / Upload. If DCC keys or uncompressed clear pixels evaluate to black (uniform = {{0, 0, 0, 1}}), the swapchain continuously presents black frames despite draw dispatches completing in the background.
3. Array Slice XOR & DCC Handover:
   • Similar to the UE4 sky/lighting issues fixed in fix(agc): preserve array slice XOR in color target views #4551 and AGC: a cube's packed-tail mips rendered per face are not seen by the cube's sampled view; the reflection capture filters a clear value (High on Life PPSA15388, black lighting) #4736 (High on Life), UE4 color target views with shifted 2D addresses can lose the slice XOR contribution or drop out of ResidentServesDisplay when DCC keys are marked register-cleared before publication.

We are tracing the flip address resolution with APS5_PROFILE_DRAW=1 and APS5_STORE_AT_FLIP=1 to pinpoint whether the final UE4 backbuffer is getting evicted from resident presentation or presenting unmapped DCC clear values.