Marvel's Spider-Man 2 (PPSA03016)

[hugodearaujo]

Existing thread

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

Title

Marvel's Spider-Man 2 (PPSA03016)

Content version tested

01.004.003

AnyPS5 commit

main 0c6a5bd (2026-10-21) with #9424 (fed7f19, which carries #7679) and #9457 (c00cb0f, stacked on #8939, #7395 and #7223). The last two runs add #9790's commits on that head, through EagleBearerYS's test branches test/sm2-9790-on-c00cb0f875 (aeb0b65) and test/sm2-9790-child-key (ac5f6f8).

System tested

Arch Linux (kernel 7.2.11), GCC 16.2.1, Release; AMD Radeon RX 9070 XT, RADV (Mesa 26.2.5)

Furthest point

Logos or loading screen

What is shown

The Insomniac Games logo, then a black screen until the stop at 133 s. Nothing needs input up to there.

Current blocker

On main 0c6a5bd, each stop with the build that got past the one before it:

1. INDEX_BUFFER_SIZE has not been set (151 s). fix(agc): resolve indexed indirect draws on a queue that never set INDEX_BUFFER_SIZE #9424 fixes it (spiff637's fix(agc): resolve indexed indirect draws on a queue that never set INDEX_BUFFER_SIZE #7679, closed by the open-PR limit).
2. The Recompiler: a T# reached through two loads after a dynamically indexed read (pointer → pointer → T#, pointer → V# → buffer → T#) stops Ratchet & Clank (PPSA01474) and Guardians of the Galaxy (PPSA01748) #6191 descriptor chain, ReadConstBuffer@pc=0x8560, a T# at a fixed offset of a V# loaded through the record pointer (142 s and 146 s). fix(shader): follow pointer hops and fixed-offset V# reads behind a record pointer #9457 fixes it.
3. ReadConstBuffer@pc=0x8fa0 over LoadAddressU32@pc=0x8f54, in the same shader family (131 s). fix(shader): plan several T#s read through one pointer-loaded V#, keeping the V# real for their other uses #9790 fixes it (run).
4. ReadConstBuffer@pc=0x9a50 over LoadAddressU32@pc=0x9a3c, later in the same shader (135 s): an array of T#s indexed by data in the V#'s buffer, through a pointer pair one of whose arms is a T#'s first two dwords. test/sm2-9790-child-key gets past it.
5. GetSamplerResource dword 0 is not a valid runtime value at ReadConstBuffer@pc=0x9a9c over LoadAddressU32@pc=0x9a20 (133 s): the S# read through the first load of that V#, whose buffer also gives the array's key word (run). No fix yet.

On current main (since #9137) it stops earlier, in its first 40 s, on sceSystemServiceParamGetInt: registry-backed parameter not implemented. Parameter 100 answers again since #7965. Parameters 208 and 210, which the title reads next, still throw; no PR or console value covers them.

spiff637 reported the first two stops on PPSA08338, the EU release (01.005.001), on Windows with an RTX 3080, in #7679 and #6191.

How it was run

1. relinker --module-dir . --registry, through a local script.
2. No input. APS5_TRACE_SUMMARY_EVERY=10, APS5_PROFILE_DRAW=1 and APS5_DUMP_SHADERS=1; a cold shader cache.

[hugodearaujo]

The next stop on Linux, past the INDEX_BUFFER_SIZE and descriptor-chain stops: the title runs out of VRAM about 4.5 minutes in, while one compute dispatch builds its image table.

Build: main 342ac2e with #9969 (7588a53) and #9424 (fed7f19 plus its new commit 3dbab57, the empty-indirect skip fix). RX 9070 XT (16 GB), RADV Mesa 26.2.5, Release, APS5_PROFILE_DRAW=1.

• The screen stays black the whole time. The title only gets this far if X is pressed; I press it every 30 s from 150 s. In a run without presses it stayed on the black screen for the full 7 minutes, with no table this size.
• Four runs with presses ended the same way, between 265 and 290 s.

What happens:

• A compute program of 421,827 SPIR-V words is built. That takes about 10 s, and its address changes between runs (0x11e2b31b00 in the last one).
• Its first dispatch has a sampled image table of 8,904 entries, with 8,903 distinct T# base addresses. Their surfaces add up to 26,945 MiB of guest memory, counting overlapping ranges separately. The device's table capacity is 262,144, so no entry is cut.
• ShaderResources::resolveImageTables() creates a host texture for every entry. More than 7,000 textures are created within about 20 s, mostly block-compressed at 1024×1024 and 2048×2048 (formats 169, 170 and 177).
• The device-local heap fills. The last budget line has 9,650 MiB of sampled textures, 4,787 MiB of them in the texture cache, with 15,901 of 16,304 MiB used. Allocations then spill into host memory, and a watchdog I run stopped the title with under 1 GiB of VRAM and about 2 GiB of GTT free. Without it, an earlier run took the desktop compositor down.

The backtrace, from a local diagnostic build that prints one at the 1,500th texture (all six I took are the same):

Texture::Texture(Context const&, TextureDetiler&, ...)
cachedTexture(...)
ShaderResources::resolveImageTables()
ShaderResources::buildComplete()
ShaderResources::Complete()
VulkanDevice::dispatch(...)
Driver::dispatch(...)
Driver::execute(...)
Driver::run(unsigned int)

@EagleBearerYS, this is the table your chain gets the title to. Is materializing every element expected here, or is there a way to materialize only the elements a dispatch selects? I don't know how many of the 8,904 this shader actually reads.

[EagleBearerYS]

@hugodearaujo thanks, that's a clear account. No, building all 8,904 isn't what this table should cost, but it is what the CPU path does today when it can't narrow the table:

• When a table's key isn't a value the planner can evaluate before the dispatch is recorded (a per-lane value, a loop-carried Phi, a read it can't follow), the table binds every record of its domain, and each record becomes a host texture. That's the documented fallback in docs/dev/debt/shader.md ("binds every record of the snapshot domain instead of the selected ones"). A key fix(shader): index a pointer-loaded V#'s T# array by a word read from the same buffer #9969 recognizes as a child key maps only the record it reads.
• Building only the entries a dispatch reads, when the key is known only on the GPU, is what feat(agc): look up table images at run time through a device image table on the GPU heap (APS5_GPU_PATH) #7642's device image table does: the shader looks up each T# at run time, and the CPU builds only the ones it misses. feat(agc): look up table images at run time through a device image table on the GPU heap (APS5_GPU_PATH) #7642 is still a draft with an open device-loss investigation, so it isn't ready to try on this yet.

To tell which case this is, could you run once more with APS5_TRACE_IMAGE_TABLE=1 and post the [image-table] shader 0x… table … lines for that dispatch? They give each table's base, size, stride, record count and key count, which shows whether the 8,904 come from one table's whole domain or from a key that should have been narrowed.

[hugodearaujo]

@EagleBearerYS here they are, from the same build with APS5_TRACE_IMAGE_TABLE=1. The program is the 421,827-word one again (0x11e2b3e600 in this run), and these are its table lines, printed just before its pipeline was created:

[image-table] shader 0x11e2b3e600 table 0 (image): base 0x1197030000 size 0xb0000 stride 0x20 addend 0x0 offset 0x0 dwords 8, 22528 records, 22528 keys, 0 structural poison
[image-table] shader 0x11e2b3e600 table 1 (image): base 0x119a753100 size 0x4b5540 stride 0x20 addend 0x0 offset 0x460 dwords 8, 308564 records, 308564 keys, 308557 structural poison
[image-table] shader 0x11e2b3e600 table 2 (image): base 0x119a753100 size 0x4b5540 stride 0x20 addend 0x0 offset 0x0 dwords 8, 308564 records, 215724 keys, 215717 structural poison
[image-table] shader 0x11e2b3e600 table 3 (image): base 0x119a753100 size 0x4b5540 stride 0x20 addend 0x0 offset 0x420 dwords 8, 308564 records, 0 keys, 0 structural poison
[image-table] shader 0x11e2b3e600 table 4 (image): base 0x119a753100 size 0x4b5540 stride 0x20 addend 0x0 offset 0x4c0 dwords 8, 308564 records, 0 keys, 0 structural poison
[image-table] shader 0x11e2b3e600 table 5 (sampler): base 0x119a753100 size 0x4b5540 stride 0x10 addend 0x0 offset 0x8 dwords 4, 308564 records, 65536 keys, 65529 structural poison
[image-table] shader 0x11e2b3e600 table 6 (sampler): base 0x119a753100 size 0x4b5540 stride 0x10 addend 0x0 offset 0x8 dwords 4, 308564 records, 65536 keys, 65529 structural poison

• Table 0's whole domain is keyed: 22,528 records, 22,528 keys, none poisoned. It's the only table here with more than a handful of unpoisoned keys.
• Tables 1 to 6 share one base, 0x119a753100: 308,564 records at stride 0x20 (0x10 for the two sampler tables). Almost all their keys are structural poison. That leaves 7 unpoisoned keys in each of tables 1, 2, 5 and 6, and tables 3 and 4 have no keys.
• My earlier local print in resolveImageTables showed this dispatch's sampled binding with count 8904 and elementBase 0. I don't know how the 22,528 keys of table 0 become that count, so I can't say from these lines alone whether the 8,904 are all from table 0.

The run was stopped by my watchdog at 285 s, before the next 10 s [image-table] summary.

[EagleBearerYS]

@hugodearaujo thanks, that pins down where the 8,904 come from: table 0.

• Table 0 binds its whole domain. 0xb0000 bytes at stride 0x20 is 22,528 records, every one keyed and none poisoned, and its line has no (narrowed). Each distinct T# among a table's records becomes one element, up to ImageElementBudget (65,536) and the device's capacity (ARCHITECTURE.md, "ResolveImageTables turns the snapshot into the map buffer"). The ~8,900 distinct T#s you counted are table 0's. Tables 1 to 6 have at most 7 unpoisoned keys each, and a poisoned record becomes no texture.
• Why it isn't narrowed. A column narrows to the records its keys select, plus record 0, only when every access to it has a key domain: a key buffer of at most 256 positions (APS5_IMAGE_TABLE_KEY_SCAN), or a value the SRT walker can evaluate (same section, "At every invocation"). The trace line doesn't say which case table 0 is:
  1. Its key comes from a buffer longer than 256 positions. The scan is then skipped and counted as key-scan in the 10 s summary, with the widest buffer's position count, and raising the limit narrows it.
  2. One of its accesses has a key the planner can't follow: loop-carried, lane-reduced, masked, or read from a buffer the shader writes. Then the CPU path keeps the whole table, and only a GPU-side lookup like feat(agc): look up table images at run time through a device image table on the GPU heap (APS5_GPU_PATH) #7642's would build just the entries that lanes read.

Could you run once more on the same build with APS5_IMAGE_TABLE_KEY_SCAN=262144 added to APS5_TRACE_IMAGE_TABLE=1, and post table 0's line and the first [image-table] (10 s): summary after it?

• If table 0's line then ends in (narrowed), it's the first case, and the texture count shows how much the narrowing saves.
• If it doesn't, the summary's narrowing ... skipped: reasons are the next clue. That summary covers every table in those 10 s, so it hints rather than proves.

The summary prints 10 s after the previous one, so the watchdog would need to allow a little longer than last time. If the table narrows, the run may also stay inside VRAM.

[hugodearaujo]

@EagleBearerYS both runs are on the same build.

• With APS5_IMAGE_TABLE_KEY_SCAN=262144, table 0's line is unchanged and has no (narrowed). The watchdog stopped the run again before the next 10 s summary.
• Narrow only runs when the column has key domains, so I added two local prints to see which case it is. One sits in ResourceTracker, where a table access without a key domain sets unkeyed. The other comes after traceTable, for tables with 1,000 keys or more. On a cold shader cache, the first print's lines came out together, just before the table lines of shader 0x11e2b3ab00 (the same 421,827-word program):

[diag-unkeyed] direct column stride 0x20 offset 0x0 words 8 sampler 0 masked 0 parentPointer 0 keyOpcode ReadFirstLane maxKey 0xffffffff   (2 lines)
[diag-unkeyed] direct column stride 0x20 offset 0x0 words 8 sampler 0 masked 0 parentPointer 1 keyOpcode ReadFirstLane maxKey 0xffffffff   (3 lines)
[diag-unkeyed] indirect column ... keyOpcode ReadFirstLane   (14 lines, images and samplers, 10 of them with merged 1)
[image-table] shader 0x11e2b3ab00 table 0 (image): base 0x1197030000 size 0xb0000 stride 0x20 addend 0x0 offset 0x0 dwords 8, 22528 records, 22528 keys, 0 structural poison
[diag-table] table 0 unkeyed 1 keyDomains 0 selected 0 indirect 0 pointerKeyed 0 maxKey 0xffffffff narrowed 0

So it's your second case. All five accesses to table 0's column (stride 0x20, offset 0, 8 dwords) take their key from a ReadFirstLane, unmasked. For the three with a parent pointer, neither MatchChildKey nor MatchKeyDomain gives a domain, and for the other two MatchKeyDomain doesn't. Every unkeyed access in that shader has a ReadFirstLane key.