Ghost of Tsushima Director's Cut (PPSA02225) — bring-up progress

[sktharunbalaji13-cmd]

Ghost of Tsushima Director's Cut (PPSA02225) — bring-up progress

Tested

• Title: Ghost of Tsushima Director's Cut
• Title ID: PPSA02225
• Game version: 02.024 (inferred from the dump's retail build marker ++ build-r-retail 0711.0902 retail5-patch ship p224rc2 ++; the dump contains no param.sfo, so the version is not console-verified)
• Host: Windows 11 Home Single Language, build 10.0.26200
• CPU: AMD Ryzen 7 7840HS
• GPU: NVIDIA GeForce RTX 4060 Laptop GPU (driver 32.0.16.1742); AMD Radeon 780M integrated graphics also present
• AnyPS5 revision: 961b25fe24582361833a90b912eff5793550afdf
• Working tree: Contains uncommitted graphics-driver and diagnostic changes. The October 11 runtime used an earlier build of those changes (staged libSceAgcDriver.prx, 11,458,826 bytes, SHA-256 856D90ED96C14AFBCB9DC3283DC9057918ECF7CEFE83C01953BE937E55E87DB7), not the current rebuilt driver (SHA-256 502855F6227BF03F91FA8892DE449D99A7EB8F1B3A468BC91725208221167265).
• Relinked executable: 65,096,704 bytes, SHA-256 A13603833F7450795BDC0D718B704E188574A8D658313CCF5061C6C3C76BBCDE
• Last verified gameplay run: October 11, 2026

Status

Launches, but renders a completely black screen. Not playable yet.

A preserved run (October 11, approximately 15:49) initialized Vulkan, created a window and swapchain (1152x648), loaded the pipeline and shader caches (672 disk-cache hits / 0 misses / 0 failures), and ran at approximately 59 FPS. The window title reported Ghost of Tsushima | FPS: 59.20 (2532). All five captured frames from a separate 16:25 run were byte-identical, with every pixel (0,0,0).

The draw trace (16:36 run) recorded 6,791 draws, all completed, with no varied-geometry scene draws observed—only 3-vertex non-indexed fullscreen-triangle passes against three 3840x2160 display surfaces. Capture-trace analysis (16:55 run) recorded 2,493 presents in strict double-buffer alternation, with each surface redrawn between its presents: fresh content every flip, yet black. The cause of the missing scene rendering remains unknown.

Progress log

Update 2026-10-12 — evidence verification

Reviewed the preserved October 11 runs and verified game attribution using the package directory, retail build marker, ELF executable header (7F 45 4C 46), and title-consistent resource paths such as /app0/cache_ps5/t02225.dat, /app0/ui/vshell/content_ps5/save_icon.png, and /app0/cache_ps5/playgo.pgm.

• Best run: October 11, approximately 15:49 — approximately 59 FPS with swapchain and caches live.
• Furthest point: Loading screen; display buffers presented at full rate.
• Observed result: Every captured frame black; no scene geometry observed in the draw trace.
• Earlier blocker, fixed in the staged driver: An abort on a non-sRGB guest-format-56 texture sampled through a sampler forcing sRGB decoding (seen in the 11:51 run, 0xc0000409).
• Current leads: Repeated shader-preparation failures (GetImageResource dword 0 is not a valid runtime value, approximately 26 occurrences, non-fatal). Their relationship to the missing scene rendering is not established.
• October 12 attempt: Did not launch. The host commit-space gate failed with 4,713 MiB available against the 8,192 MiB safety threshold. The game's direct-memory allocation request was approximately 4,696 MiB, leaving only about 17 MiB of nominal headroom, so the gate correctly refused a near-certain abort. No new gameplay evidence was produced.

Known blockers

Blocker	Evidence	Status
Black screen	All five captured frames fully black	Confirmed
Scene geometry not observed	Draw traces show fullscreen-triangle passes only	Confirmed observation; cause unknown
Shader-preparation failures	Repeated GetImageResource runtime-value errors (approximately 26 occurrences)	Investigating; causal relationship unconfirmed
Current diagnostic build not tested against the game	Rebuilt driver postdates the preserved runs	Needs a controlled rerun
Host commit-space pressure	Approximately 7.3 GB reportedly held by seven leaked, unkillable test-harness processes	Rerun after host recovery

Next steps

1. Recover host commit headroom safely while preserving unrelated work.
2. Rerun with the current diagnostic build, stage the rebuilt libs/, and record exact binary hashes. Expect cold shader-cache recompilation.
3. Correlate shader-preparation failures with the draw and capture traces.
4. Identify why scene geometry is not submitted or rendered.
5. Update this Discussion only when a new result is reproduced and verified.

Evidence

Preserved logs, state summaries, and hashes are stored locally under C:\games\ghost\anyps5-pps02225-probe\startup-upstream-* (eight dated runs, each with summary.txt, stdout.log, stderr.log, state.json, and SNAPSHOT-HASHES.txt). Frame captures are under startup-upstream-framedump-retry-20261011-162543\frames\. The large capture trace (~661 MB) is retained locally.

These paths are local to the test host and are not public links. If no evidence has been uploaded to a public, appropriate repository location, the detailed artifacts remain local.

This is an ongoing compatibility investigation. Successful launch and high reported FPS do not imply that gameplay is working.

[sktharunbalaji13-cmd]

Update 2026-10-12 (evening) — October 12 diagnostic runs and shader-resource rejection analysis

Correction to the progress log above: Four instrumented diagnostic runs from October 12 are confirmed to have launched: 00:09, 11:31, 12:04, and 14:48. The earlier “October 12 attempt: did not launch” note should not be read as describing all October 12 activity. The exact relationship between that note and a separate failed preflight remains unconfirmed; the failed preflight's identity and timing are not established here. Commit headroom at the confirmed launches was 13.9 GiB (00:09 preflight) and 13.2 GiB (14:48, with all four readings above the 8 GiB gate).

Build identity: Deployed diagnostic builds are identified by hash for two of the four confirmed runs: 00:09 deployed 891C6739… (11,490,252 bytes), and 14:48 deployed EA701D18… (11,561,180 bytes). The builds deployed at 11:31 and 12:04 were not identified by hash in this audit, and their restoration records were not re-verified. Restoration of the staged driver (856D90ED…) is documented in the preserved 00:09 and 14:48 reports.

What the October 12 runs added (all instrumented; none captured pixels, so their visible output remains unverified):

• Shader-resource rejection records: The preserved logs contain approximately 20–22 [srt-image-reject] records per run, interleaved with shader-preparation failures. Two rejection categories were observed:

  • runtime_value_validation_failure: a LoadAddressU32 address load with observed fields badDword=0, isRawReadResult=1, and rejectReason=runtime_value_validation_failure. Resource kind, memory index, and handle opcode check out, but a dependency operand in the address computation (the offset argument, three levels deeper than the handle operands) fails runtime-value validation. These fields describe the raw read result and validation outcome; they do not establish that the computed address was zero or that a resource was unmapped.
  • resolved_read_const_buffer: the descriptor resolves to an explicit constant-buffer read rather than a runtime resource handle.

• Shader-hash correlation: Multiple exact matches have been verified between rejection-record shaderHash values and shader-preparation failure addresses. For example, a rejection record with shaderHash=0x0000002000165d00 matches a failure for shader 0x2000165d00. The exhaustive per-hash join across all records and failure lines remains pending. The current evidence does not establish that every failure has a matching rejection record.

• No established link to recorded draws: Each October 12 run emitted three unique [draw-programs] records, all with verdict Drawn and the same four program codes: 0x20001e6000, 0x20001f2700, 0x20001f2b00, and 0x20001f3a00. The logger deduplicates by program/target/sampled-binding configuration, with a cap of 256 that was not reached in any of these logs. These are the unique configurations the logger emitted, not a three-draw sample. The diagnostic also catches and suppresses its own per-draw exceptions, so the records are not guaranteed to account for every submission. None of the rejected/failing shader codes appears in these records. The 14:48 records carry submission serials 49, 51, and 69; its capture trace independently counted 282 draw submissions. There is no identifier linking the failing shader preparations to a specific draw submission, and whether the affected shaders executed remains unknown.

• 14:48 capture-trace run: 282 draw submissions, 1,060 submit batches, 141 flips and 141 presents (frames 1–141), zero unsignaled flips, zero failed flips, and zero draw-error records, alongside 28 shader-preparation failure lines. These failures did not halt presentation during the observed window. This does not establish what appeared in the presented frames.

• Static analysis of a sample of failing shaders (12:04 analysis): Nine of ten prioritized failing shaders share a loop-carried induction-variable shape, p = Phi(0, IAdd32(p, 1)); conservative rejection appears appropriate for that shape, but this is static analysis, not proof of runtime behavior or causation. The tenth is a ReadLane case that correctly reports no Phi data. The self-reference identification is inferred from the renderer's <shared> marker plus pointer comparison; independently confirming it requires another printed field, not another game run.

• Host-import budget pressure: All four October 12 runs reached 6,142 MiB live against the 6,144 MiB APS5_HOST_IMPORT_MIB budget. Recorded refusal counts differ by run/window: up to 242,445 (00:09), 224,847 (11:31, over the observed window), 399,690 (12:04, over the observed window), and 59,313 (14:48, late-window sample). No evidence currently links a refused import to the black output; any causal relationship remains a hypothesis.

• Run outcomes varied: The 00:09 game process exited on its own after the observation window; the 11:31 log ends mid-write, with the missing tail attributed to a self-exit (inferred, not independently confirmed); the 14:48 process was still running at the end of its observation window. No pixel captures were taken in these runs.

Version note: The extracted image's param.json records contentVersion 02.024.000, corroborated by pfs-version.dat. param.sfo is absent, so the exact title version executed remains unverified.

Upstream overlap

• PR #4487 — open and mergeable as of this update. It implements sampling non-sRGB textures through FORCE_DEGAMMA samplers as sRGB views. The local forced-degamma/sRGB-view change substantially overlaps this PR and is not original, upstream-ready work. The local change differs by refusing the pairing when the device lacks the optional sRGB sampled format, using the existing srgbDecodeFormats probe. A fresh comparison is required before considering submission.
• The October 11 sRGB-decoding abort did not recur once the staged driver's forced-sRGB path was live, but the staged driver contained multiple uncommitted changes. The specific fix is therefore not isolated to the sRGB-view change.
• PR #757 and PR #758 — both open and needing rebase as of this update. Their runtime-indexed descriptor work is relevant prior art, not a proven fix for this title.
• PR #862 — open draft concerning sampled storage-texture view usage.
• Recently merged relevant work includes feat(agc): accept samplers that force sRGB decoding of sRGB textures #1487, fix(agc): keep FORCE_DEGAMMA paired when ANISO_OVERRIDE rebuilds a sampler #3843, perf(agc): baseline shader recompilation on registration #639, and feat(agc): implement deferred faults for reads through null SRT pointers #759.

Next steps (offline first)

1. Complete the per-hash join. Join every preserved [srt-image-reject] record against the shader-preparation failure lines across all four October 12 runs. Extracted artifacts exist in the corresponding diagnostic evidence directories. This can establish which failures have matching rejected-read records and classify the observed rejection branches and reasons. It cannot establish which submissions used those shaders, whether they executed, or any causal link to the black screen.

2. Instrument only the context that actually exists. The failure is logged at ShaderRegistry.cpp:632 inside a background preparation task in RegistrationPreparePool. The call path is the guest export AgcDriverRegisterShader_nid_postfix(const Shader*) → Driver::RegisterShader → background preparation. The export receives only the shader header pointer, and the background task captures the shader snapshot and registered-preparation plan. No command-buffer, draw, dispatch, or submission identifier exists at registration time or at the current failure site. Instrumentation should record genuinely available context, such as the snapshot header address/type, preparation-plan identity, and deferred-resource list. Caller or operation identifiers should only be recorded if they are actually available. Direct correlation with a particular submission requires a separate propagation or instrumentation path; no such identifier exists in the current registration path.

3. If a new run is authorized, test the build identified in the original post. The 502855F6… build named there has not been verified in the four preserved October 12 runs. The two runs with verified deployment hashes used 891C6739… and EA701D18…; the 11:31 and 12:04 builds were not identified by hash. A controlled run of 502855F6… with a pixel capture would determine its visible output, which remains unverified.

Boundaries and current status

• The five October 11 frames previously captured were entirely black, but this does not prove every presented frame was black.
• No pixel evidence exists for the October 12 diagnostic runs; their visible output is unverified.
• No causal link between shader-preparation failures, rejected reads, host-import refusals, and the black screen has been established.
• Gameplay and correct rendering have not been verified. Successful presents and reported FPS do not demonstrate playability.

The investigation remains open. Contributions are welcome, especially on the exhaustive shader-hash join, AGC shader-resource planning, and methods for correlating registration-time shader failures with work that actually executes.

[sktharunbalaji13-cmd]

Update 2026-10-12 (late evening) — exhaustive shader-rejection correlation completed

The offline join between shader-preparation failures and [srt-image-reject] records is complete for the four October 12 diagnostic runs. This resolves the previously pending correlation task; it does not establish the cause of Ghost of Tsushima's black screen.

Run	Preparation-failure lines	Unique failing shaders	Rejection records	Unique failing IDs matched to rejection records	Reject-only IDs
00:09	26	20	20	20	0
11:31	27	21	22	21	1
12:04	28	22	22	22	0
14:48	28	22	22	22	0

Failure-line counts include repeated failures for the same shader, so they are not unique-shader counts. They are after-registration failure lines; each run also logs two deferral notices for shader 0x20001d0300 (prepared on use), which are not preparation failures and are excluded from the counts.

The one discrepancy is explained by a truncated log. The 11:31 rejection record for shader 0x2000028b00 has no corresponding failure line in that run's truncated log tail; the failure appears in the later 12:04 and 14:48 logs. All unique failing shader identifiers in the four runs otherwise have corresponding rejection records. The join also identifies a stable 20-shader core across the four runs and an earlier October 11 diagnostic run; the older run predates the rejection instrumentation, so it provides no rejection-record coverage.

The raw-log join corrects earlier analysis-summary counts that overstated unique shader populations. Repeated failure lines, unique shader identifiers, rejection records, and rejection-record sequence counters are distinct quantities.

Rejection categories: Ten shaders with runtime_value_validation_failure records correspond to the ten recorded [srt-validation-fail] cases: nine invariant-Phi resolution failures and one ReadLane validation failure. The remaining records are resolved_read_const_buffer cases (10 at 00:09; 12 in each of the later three runs). A raw field such as badDword=0 is not proof of a zero computed address or an unmapped resource.

Comparison with recorded graphics draws: The diagnostic logs emit three unique [draw-programs] records per run, covering program codes 0x20001e6000, 0x20001f2700, 0x20001f2b00, and 0x20001f3a00. None intersects the failing/rejected shader identifiers. These records are deduplicated by program/target/sampled-binding configuration, and per-draw exceptions are swallowed by the diagnostic logger; they are not a complete census of submissions. Their contents therefore do not prove that the affected shaders never executed.

In the 14:48 run, 282 draw submissions and 141 flips/presents were recorded alongside the preparation failures. The October 12 diagnostic runs have no pixel captures, so their visible output remains unverified.

What this changes

The exhaustive hash join is complete; it should no longer be listed as pending. The black-screen cause remains unknown, and no causal relationship between these shader-preparation failures and the black pixels has been established.

The next technical investigation should move to the draw-submission/decision path: determine which registered shader snapshots are selected into submitted command buffers. The registration-time failure site has no submission identifier, so direct correlation would require a separate, evidence-driven instrumentation or context-propagation path.

The five October 11 frames previously captured were completely black, but that does not establish that every presented frame was black. Gameplay and correct rendering remain unverified.

[sktharunbalaji13-cmd]

Community progress update: black output remains under investigation

The black frames reported for this title remain under investigation. Previous observations show continuing draw and present activity alongside shader-preparation failures, but those observations do not prove causation. The cause has not been established.

Recent local work, still uncommitted, adds draw-to-submission correlation. It tracks draw attempts, shader-selection and preparation outcomes, recorded draw commands, and deduplicated draw-token sets tied to recorder batches. It also separates submission attempts from submit-confirmed records made after successful queue submission and recorder finalization. The goal is to tell which shaders were actually selected into submitted work, rather than only which preparations failed earlier.

This work remains uncommitted and Windows runtime validation is blocked, so there are no new game-runtime results to report yet.

Feedback is welcome on PR 5238, which adds complementary per-draw shader stage, role, address and submission tracing for direct comparison.

[sktharunbalaji13-cmd]

Investigation milestone: draw-to-submission tracing PR

We have opened a focused PR to improve diagnostic tracing in AnyPS5. It connects draw attempts and shader-preparation failures with actual recorded draw commands and the recorder batches submitted to Vulkan.

The change also distinguishes submission attempts from successful queue-submission calls, with optional tracing designed not to change normal drawing behavior when disabled.

Highlights of the PR clean-branch validation:

• configured successfully on Windows;
• built the instrumented libSceAgcDriver.prx and completed NID patching;
• passed 8/8 CaptureTrace tests.

This does not yet identify the cause of the black screen. A game-runtime trace is still needed to determine whether failed shader preparation is related to the draws associated with the black output.

Technical review and feedback are welcome:

#5431

[sktharunbalaji13-cmd]

End-of-day milestone: first isolated Windows correlation run completed

Today we reached an important milestone in the Ghost of Tsushima Director's Cut black-screen investigation.

We prepared a focused diagnostic PR, #5431, that adds correlation between draw attempts, shader selection/preparation failures, actual recorded draw commands, and recorder-batch submission. It complements the per-draw shader-address tracing in PR #5238.

The instrumented driver built successfully in an isolated Windows Release environment, including NID patching. The focused CaptureTrace test suite passed 8/8 tests.

We also staged a separate runtime copy and completed one controlled run with the instrumented driver, without replacing the original driver or overwriting the previous trace evidence.

The completed trace recorded:

• 797 draw attempts and 1,594 shader-selection records.
• 600 actual draw-command recording records.
• 2,807 submission attempts and 2,807 successful queue-submission confirmations.
• 398 flips and 202 presentation/blit events.
• No shader-request/preparation, materialization, or draw-submission failure events in this run.

The 197 attempts without draw-recorded appear, from source inspection, to follow a documented no-draw/recipe path. Their absence from draw-recorded is not by itself proof of a rendering failure.

The black rendering window was shown in a screenshot during the run, but the trace does not provide validated pixel data. Continued drawing and presentation activity does not prove that correct pixels reached the screen.

The cause of the black screen remains unknown. Earlier runs showed shader-preparation failures, but this new trace did not capture such failures, and we have not established that the earlier failures caused the black output.

The new trace, reports, and staging manifest are preserved. We intend to use these results to choose the next targeted experiment rather than assume a cause prematurely.

Technical review and feedback are welcome on PR #5431.