Infliction: Extended Cut (PPSA02688)

[JJenkx]

Existing thread

• I searched this category for PPSA02688 and Infliction; no existing thread was found.

Title

Infliction: Extended Cut (PPSA02688)

Content version tested

01.003.000

AnyPS5 commit

Unmodified main 9bf01db663445820687e85fdbff08959d5193a5a. No additional pull requests or local code changes.

System tested

Arch Linux 7.2.9-arch1-1, GCC 16.2.1 Release, Ryzen 9 7950X, Radeon RX 6650 XT / RADV Mesa 26.2.4. Default source-built dependencies.

Furthest point

Menu.

What is shown

Language selection, startup/legal splash, main menu and the New Game loading screen are verified. Normal virtual-controller input selected English, advanced the splash, selected New Game and confirmed it. The dedicated runtime's small save directory was backed up beforehand.

The main menu text is readable, but its 3D background is very dark; rendering correctness is unverified. At 451.95 seconds the reported run still shows the autosave/checkpoint loading screen. The window title reports about 1.4 FPS near its planned ordinary close at 480.69 seconds; this is a sparse observation, not a standardized performance capture. No gameplay or title completion is established. Audio was not assessed.

The run closes normally, exit 0, with native PID disappearance and restoration of the temporary kernel setting verified.

Current blocker

Level loading has not progressed to a verified playable scene within this run. There is no observed missing import or explicit unimplemented-API exception, and no prerequisite PR is identified yet. The log reports:

[gpu] queue 0x20 WAIT_REG_MEM_64 at 0x1021069b00 timed out after 1000ms (function 3 ref 0x1 mask 0xffffffffffffffff value 0x0)

At the warning, the recorder reports a label-table miss, no overlapping open-batch write and no pending completion label/writeback completion. This does not establish a persistent deadlock or the failing producer. Next: trace the producer/submission and large-range import/writeback activity. No wait is bypassed and no success value is fabricated.

How it was run

The executable and the title's bundled SDK modules were converted with the source-built relinker on the exact main above. All extracted asset sizes match the package listing; the extracted assets, caches and reports are on SAS storage. The public report includes the exact relinker command and all recorded input actions.

<build>/core/relinker/relinker --registry unused-filter=0 \
  --rpath <build>/core/libs/libs \
  <normalized-input>/eboot.elf <run>/app.elf

cd <run>
env LD_LIBRARY_PATH=<build>/core/libs/libs \
    ANYPS5_SHADER_CACHE_DIR=<cache> \
    APS5_PIPELINED_DRAWS=1 APS5_HOST_IMPORT_MIB=16384 \
    APS5_DRAW_CACHE_ENTRIES=4096 APS5_NO_PAD_INPUT=1 \
    APS5_PAD_INPUT_FILE=<run>/native-pad.txt ./app.elf

The supervisor selects the system RADV driver and X11, verifies the loaded driver/source revision, captures without forcing focus, and requests ordinary close. It temporarily sets udmabuf.size_limit_mb to 8192 and restores 64 after exit. These native runs do not enable profiling or Vulkan validation. APS5_NO_PAD_INPUT=1 excludes stray desktop keyboard/mouse input; the normal virtual-controller command file supplies the recorded buttons.

The first cold startup wrote 2,833 shader-cache entries and closed at 181.39 seconds. A warm follow-up reached language selection and the autosave notice, then closed normally at 300.10 seconds. Those are cache warm-up observations, not an isolated main/change speed comparison. The fields above describe the subsequent menu/New Game run.

Exact source, all three run results, controller actions and limits.

AI-assisted: yes.

2026-10-17: level-load render-thread timeout

Unmodified main bfcf02e3a81e, RX 6650 XT / RADV Mesa 26.2.4-arch1.1, same title content 01.003.000. Runtime libraries were rebuilt on this main; the executable remains the earlier conversion from 9bf01db66344. A populated shader cache was used. From the freshly verified menu, one 200 ms Cross press selected New Game at 36.35 s. The title entered Loading, then reported:

GameThread timed out waiting for RenderThread after 120.00 secs

The process exited 139 at 205.88 s. Gameplay was not reached. The process is gone and the temporary udmabuf limit is restored to 64 MiB.

This was a diagnostic run with queue/import tracing, redirected logging and two brief debugger attaches, so it supplies no speed measurement. Both samples found the queue worker in SPIR-V validation: one inside optimizer input validation during specialization, another in final validation during variant emission. Shader-cache writes continued during loading. This is evidence of shader-preparation work during the stall, not proof of its sole cause. Another queue worker was polling a memory wait in the first sample.

The log includes 638 completed waits of at least 0.5 ms, including a 4,455.7 ms wait that resolved, and no WAIT_REG_MEM timeout warning. It records 574 successful dma-buf settle operations totaling 1,611.84 ms. These observations do not establish a permanent GPU deadlock or rule out other bottlenecks.

Sanitized diagnostic metadata. Raw guest logs, shader data and game files remain local.

Next candidate: #6659 removes duplicate optimizer input validation while retaining explicit input and final output validation. It has been rebased to main 2083bc700f12, rebuilt and passes four focused optimizer/cache/graphics/mesh tests on this GPU with Khronos core validation, zero errors/VUIDs and zero skips. It has not been shown to fix this title's timeout and is not listed as a title prerequisite. Matched title/cache tests are still needed.

AI-assisted: yes.

Current-main follow-up — 2026-10-17

Plain upstream 16c607a9373654e1e87c1a809845b1257f6acfed runtime libraries, without #6659 or the AJM vibration branch, reach New Game, Loading, and the Autosave and checkpoints / Press any button to continue screen. The converted executable remains the earlier 9bf01db66344 conversion. Ordinary close exits 0 after 303.56 seconds; the native process is gone and the temporary kernel setting is restored to 64. No debugger, validation or profiling was enabled.

Reviewing the earlier opt2083-load3 screenshots also found that prompt by 120 seconds. Its controller had stopped observing after Loading, so that stationary screen is not evidence of a loading hang. The local controller now recognizes the prompt. On this current-main run it submitted one 200 ms Cross pulse, but the final screenshot still shows the prompt; actual scene advancement remains unverified. Next is a warm repeat with bounded fresh-screen input checks.

Previously populated shader/Mesa caches were used. This is not a matched performance comparison, proof that the earlier guest timeout is fixed, or confirmed gameplay. Pinned run summary and limits.

Warm-cache intro follow-up — 2026-10-17

A second finite run of unchanged main 16c607a9373654e1e87c1a809845b1257f6acfed advanced beyond the autosave prompt to the opening story quotation by the final 295-second screenshot. This establishes intro progression, not playable gameplay. Three fresh-prompt-gated Cross commands were submitted (500 ms each, at approximately 73, 88 and 104 seconds); command submission alone does not prove when the game processed input.

The completed-frame counter remained at 396 for an extended interval, then resumed around 250 seconds and reached 418 before close. A temporarily unchanged screen/counter therefore did not establish a permanent hang. Native exit was 0 after 303.05 seconds; the process was gone and the kernel import limit was restored to 64 MiB. No debugger, tracing or profiling was enabled. These were populated caches, so this is not a matched performance comparison. The converted executable remains the earlier 9bf01db66344 conversion with current-main runtime libraries. No claim that #6659 or #6721 is required follows from this run.

First-person scene follow-up — 2026-10-17 (main661a)

Built runtime libraries from clean upstream 661a1118cc7cdba41d2b11a8000aab2157a93af4, reusing the older main9bf converted executable and populated shader/Mesa caches from the earlier runs. This is a loading/bring-up diagnostic, not a controlled performance comparison or a claim that a particular PR fixes the title.

The finite 420-second run progressed beyond the opening quote into a first-person room. “New objective — Find the plane tickets” appeared at about 275 seconds. A three-second right-camera-stick input at about 337 seconds was followed by a changed room/flashlight view and the “New tutorial unlocked” notice. The scene remains extremely dark and slow; this does not establish correct rendering, sustained playability or an FPS gain.

Ordinary close was requested at 421.05 seconds; the process exited normally (0) at 423.05 seconds, the native PID was gone, and the kernel setting was restored to its original 64 MiB value.

Two brief, separately recorded GDB stack captures occurred at about 213 and 311 seconds. One sampled GuestMemory::Read / GuestBufferMemory::copyRegion; the other did not. These two samples do not identify a proven bottleneck. They perturb timings. Correction to the local controller metadata: its old purpose string said “no debugger”; these two timed captures did occur and were recorded separately. Full logs and screenshots are retained locally on SAS.

[JJenkx]

Clean main + PR #7044 validation (2026-10-17): first-person gameplay reached.

I rebuilt runtime libraries on main 47a266cf975f00f7fba94013467d03bfa5e355e9 plus only AlxcBTW’s three commits from #7044 (89d255c5f3, a58a709116, 350b8d2b88), tested head 3006301b5c784c80ae876a7a15e2e293640a2d5e. No other unmerged fixes or diagnostics from the earlier aggregate were carried over. The executable/title modules remain the earlier 9bf01db66344 relinker conversion. Content: PPSA02688 01.003.000; Ryzen 9 7950X, RX 6650 XT, RADV Mesa 26.2.4-arch1.1, Arch Linux 7.2.9-arch1-1.

The scripted run passed the opening sequence and reached the “Find the plane tickets” objective at 234.98 s. The final screenshot at 346.62 s shows the first-person room, crosshair and flashlight. The existing extreme darkness and rectangular lighting artifact remain. Audio and a broader playthrough were not assessed.

The libs build and all five focused graphics/dispatch-move tests passed with RADV core validation. The native run used draw profiling without Vulkan validation; it completed ordinary close with exit 0 at 352.79 s, verified PID disappearance and restoration of the temporary kernel setting. The 33 diagnostic intervals recorded 8,937 moved-buffer dispatch-template reuses.

No FPS or loading-time improvement is claimed. The clean-main 350 s run reached the opening car sequence but had not confirmed the gameplay objective. Different scenes, profiling and source-specific shader-cache misses prevent a controlled comparison or a claim that #7044 is required to reach gameplay.

Source/test details and limits

AI-assisted: yes.

[JJenkx]

Sparse direct-memory import experiment (2026-10-17): a controlled local pair shows substantially lower frame times in the stationary first-person scene. This uses Mouad-Scriptz-0’s #4449, locally adapted, alongside AlxcBTW’s #7044 and the CPU trace coverage from #6341.

The baseline is main 47a266cf975f00f7fba94013467d03bfa5e355e9 + #7044 + #6341, head 07e1d87136fb7e9c25b280cda49fb9d4c8d23040. The candidate adds the sparse-import adaptation and two fixture corrections, head 2ee2b30792aed7274e7d964376944c6435c2e87c. Original authorship is retained in the attached patch. This is not unmodified main against a standalone PR, and the aggregate is not proposed as a new PR.

Both runs used independent copies of the same populated AnyPS5/Mesa caches, the same autosave/controller sequence, no input after the objective, a 320–330 s trace window, and planned close at 350 s. Both reached gameplay and closed normally, exit 0, restoring the temporary kernel limit. Both final screenshots show the same dark room and reticle; the rectangular lighting artifact remains.

Machine: Ryzen 9 7950X, Radeon RX 6650 XT, RADV Mesa 26.2.4-arch1.1, Arch Linux 7.2.9-arch1-1; render resolution 3840×2160.

Trace summary	Baseline	With sparse import
Presents / captured ms	14 / 10094.481	37 / 10054.766
Median frame ms	736.965	262.822
p90 frame ms	769.850	325.823
p99 frame ms	773.770	343.022
GPU busy ms / present	219.346	195.637
Dropped trace events	no	no

Median frame time is 64.3% lower in this one paired experiment. It is still very slow; this is neither a cold-cache loading result nor a general title FPS claim. An earlier instrumented candidate run reported zero failed host imports and successful CPU/GPU coherence probes, which motivated this controlled pair. The run alone does not establish the cause of every timing difference.

Both full trace-digest summaries and protocol, baseline timing trace, candidate timing trace, authored adaptation patch.

Current-main integration repeat: the same seven commits apply cleanly on main 84b0d2f24863d1e88105ada295cc346f720c1a6a, tested head efe31761cfcb41427015f960d5866dda2eedb08f. Runtime libraries build; conventions pass; all nine focused checks pass under RADV with core validation, zero skips (6.68 s). The populated-cache native run reaches the objective at 195.95 s and closes normally at 353.78 s, exit 0, PID gone and kernel limit restored to 64 MiB. Native core validation was off. Its 320–330 s trace has 38 presents, median 267.772 ms and no dropped events. This repeat has no matching latest-main baseline, so it is an integration check rather than another isolated performance comparison. The lighting defect remains. Current-main validation summary.

Remaining work: get the prerequisite PRs reviewed/merged, establish an unmodified-current-main comparison when the integration permits it, and diagnose the lighting defect. #4449 is another author’s existing PR, currently conflicting; the attached adaptation is evidence for that work, not a duplicate submission.

API-validation follow-up on main f51724078f: the same local integration now also includes #6913, XairRrR’s #6782 and #6781, and lvmino97’s #862. With Khronos core validation enabled, Infliction reached the gameplay objective and closed normally after 354 seconds. The six prior error types for vertex/index usage, independent blending, sampled-sRGB view usage and host-stage access are absent. One existing vkDestroyDevice report remains for three leaked child objects; this is not a zero-error run.

The dark rendering and rectangular light artifact remain. A bounded capture selected the lighting shader by identity and confirmed populated material/albedo/normal/AO inputs across the active 2688×1512 viewport within 3840×2160 storage images. That rules out simply empty resident inputs, but does not establish correct depth, shadow-array data or shader math. No additional performance gain is claimed. Sanitized validation protocol and results; raw resource dumps remain local. Three focused import/graphics tests pass with core validation.

[JJenkx]

Further graphics investigation: the shadow-cube capture exposes a missing layered depth-rendering path.

The sampled 1024×1024 D16 cube has six faces. Its resident depth target reports view=0-5, swizzle=24, htile=0, but only face 0 has a tracked native owner. The run also logs:

[gpu] layer/viewport index vertex exports are ignored (PA_CL_VS_OUT_CNTL=0x01240000)

This agrees with two gaps in main 66702f1cffd3: DepthSurface creates one image layer, and depth-only state decoding leaves the rendering layer count and layer exports at their defaults. Layered color rendering already has a separate route.

The earlier readback shows coherent native depth on face 0, scrambled low depth on faces 1–4 and zero on face 5. A CPU replay of the current detiler matches every captured pixel of guest-backed faces 1–5. That checks agreement with the current upload/readback path; it does not independently validate the hardware swizzle equation, and the guest-memory read was later than the GPU capture.

Latest local diagnostic revision 518c8dfa38cf: driver build, graphics test with RADV/core validation, and conventions passed. The complete native run reached the gameplay objective, exited 0 and restored the kernel setting. Only the previously reported vkDestroyDevice-device-05137 shutdown warning remains. Bounded evidence.

Next work is to implement layered depth attachments, layer routing and slice ownership, then validate all six faces. No rendering fix or FPS gain is claimed here; this was an instrumented integration run containing multiple local/unmerged changes.

[JJenkx]

Depth-array import progress (2026-10-17): a separate storage-to-depth bug is now reproduced and fixed.

DepthSurface::TakeStorage used FindPending, which requires the storage image's base address. A depth plane pointing at a later array slice therefore missed its pending GPU data. The standalone fix uses FindPendingSlice, validates the slice offset, and copies the corresponding source image layer.

The patch is available on current main 922dc8999ea024c9d5bce46049aa22d6dd72f534: commit 5ff961792. It is independent of the local layered-depth rendering work. An upstream PR is pending an available author slot; existing PRs remain open.

On that main base, the expanded D32 two-layer and D16 six-layer GPU regression produces 12 assertion failures without the fix and passes with it. The build and convention checks pass. GPU: RX 6650 XT, RADV Mesa 26.2.4-arch1.1, Linux.

In the local layered-depth integration, a completed native before/after capture shows the effect: previously faces 1–5 started at zero and the first captured producers made no changes. With the import fix, all six faces start at the imported depth 1; captured producers write faces 4 and 3, and a later capture contains depth data on every face. All 19 related GPU tests pass in this integration. The game reached the objective and closed normally; only the previously recorded teardown VUID remains.

The final scene is still very dark. This confirms a depth import correction, not a complete lighting fix or a measured performance improvement. The native capture uses the local integration; the isolated main patch is covered by the GPU regression above.

[JJenkx]

Infliction validation update: fixed a Vulkan resource lifetime issue when the driver switches between live devices. The import-settle buffer, allocation and fence were held in one global slot; switching devices overwrote the old handles. The change retains settle resources per device and releases each device's resources during cleanup.

Main-based change: JJenkx@a3ed32e68 (rebased onto upstream 084bd39a085cf5a85a1dea19163184ba74ac1905). Submitted as #7269 after #6540 merged and opened a slot. The other 19 existing PRs remain open.

Evidence on Linux / RX 6650 XT / RADV:

• New device A -> B -> A regression fails without the fix and passes with it; both device cleanup orders are checked.
• Nine focused checks passed in 4.40 seconds on the integration build.
• Native Infliction PPSA02688 validation run at integration commit bfdd817a11abe21583643a695dc9093f72ffef02: gameplay objective observed at 239.97 seconds, normal exit after 324.55 seconds, process gone and kernel limit restored. Core validation enabled; zero VUID reports, including none of the previous leaked-buffer/memory/fence teardown reports.

The native result is for the existing combined integration stack plus this fix, not an isolated current-main A/B or a separately built standalone branch. The scene remains too dark; no lighting or FPS improvement is claimed. The full Recorder suite also retains the previously recorded pending-write assertion failure; the nine focused checks are not a full-suite pass.

AI-assisted: yes.