The Last of Us Part I (PPSA03396)

[Pacuka]

Existing thread

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

Title

The Last of Us™ Part I (PPSA03396)

Content version tested

02.000.000

AnyPS5 commit

main adca8cf (2026-10-21) with open PRs #4449, #9551, #9989 and #6553 merged on top, plus local changes (listed under Current blocker). Plain main does not reach the menu on this system (see #9295).

System tested

CachyOS Linux, kernel 7.2.2, GCC 16.2.1; AMD Radeon RX 6650 XT, 8 GB (RADV, Mesa 26.2.4); Ryzen 9 5950X, 32 GB RAM, GTT raised to 24 GiB (amdgpu.gttsize=24576)

Furthest point

Menu

What is shown

Shown in order: the SIE and Naughty Dog logos, the PlayStation intro video, the language menu, the title screen ("PRESS ANY BUTTON") and the main menu.

• The intro video plays at 59.94 fps.
• The title screen and the menu run at about 0.7 fps (7 to 9 presents per 10 s; the GPU is busy 250 to 1000 ms per frame).
• The title screen has a magenta and blue vertical band over its left half.
• I did not start a new game: every run so far ended within 5 to 12 minutes (see below).
• Audio and input not assessed beyond pressing a button at the title screen.

Current blocker

Memory. On this system (8 GB VRAM, 32 GB RAM) the title runs out of memory 5 to 12 minutes in, on the title screen or menu. I stop it with a watchdog first, because when GTT reached 24 GB the whole PC froze once. In a 4-minute sample:

• GTT 15.5 to 16.5 GB:
  • about 12.3 GB is guest memory imported through dma-buf (feat(agc): import shared direct memory through udmabuf on Linux #943 and feat(libSceAgcDriver): import scattered direct memory as a dma-buf run list and probe its coherence #4449); the import budget of 12288 MiB is full;
  • about 2.1 GB is image mirrors;
  • the rest is storage textures placed in host memory once VRAM is full.
• The process's own anonymous memory is 3 to 5 GB; swap use grows to 1.4 GB.

Two things make it worse:

• Storage-texture churn. When VRAM is full, the storage-texture budget falls to its 512 MiB floor. An image-table element at the base of the 5.2 GB GPU pool (0x1180000000, 16384x16384 RGBA8, exactly 1 GiB) is then recreated hundreds of times. Every time it evicts the rest of the cache, which re-uploads 50 to 120 GB per 10 s. With APS5_TEXTURE_CACHE_MIB=3072 that falls to 10 to 15 GB per 10 s, but fps does not change.
• Large array textures. Other large arrays are created repeatedly, for example 2560x1440 with 23 to 142 layers, 512x512x526 and 120x68x4097. I have not yet checked whether the shaders use all of these layers.

Local changes in this run (not proposed as fixes):

• Image views of 1 GiB or more are bound as absent when they run past their guest allocation or are 16k by 16k. 2D arrays over 512 MiB are cut to the slices that fit.
• ShaderMemory::readWords copies its lazy blocks through process_vm_readv. In 2 of 7 runs it crashed with SIGSEGV (SEGV_ACCERR) in TableSnapshotter::ReadRuns: an image-table read hit a page in Retail CPU memory (0x102a800000, 0x102e000000) that was no longer readable. My guess is that the title decommitted the page while a capture was reading it. I have not opened an issue for this yet.
• Earlier local work for this title (MEM_SEMAPHORE, 64-bit image atomics, S# chain): see The Last of Us Part I (PPSA03396): runs past loading on Linux/RADV but presents only black frames #9295.

How it was run

tools/unwrap_self.py   (the dump has SELF files only)
cmake --build build --target libs && run-tlou/prepare.sh
env APS5_HOST_IMPORT_MIB=12288 APS5_TEXTURE_CACHE_MIB=3072 setarch -R ./tlou.elf

app0 is a read-only mount of the dump image. A script polls /proc/meminfo and the amdgpu mem_info_gtt_used counter every second. It kills the process below 2.5 GB MemAvailable or above 22.5 GB GTT.

Prepared with AI assistance.