Repository navigation
AGC: normal rendering to an 8x MSAA DCC color target is refused (PPSA99902) #5336
Description
Current status, 2026-10-20 UTC
Keep open for the remaining resident-DCC refusal. #7250 merged and removed the earlier full-range-clear stop in the reported Sonic integration. Those menu/cinematic observations below retain their original integration pins; they are not a main-only or gameplay claim.
milescoviello's follow-up trace now identifies the separate Ruffle filters__displacement_map refusal on main 390ec58e20 + #7897 4a5ce8a094 + #8429 4660cdd42b, Linux/RTX 4070 Ti (595.99.02). Repeated 8-byte writes immediately after the DCC span fill the same 64 KiB tracking block's retained-piece list; its newer dropped history causes a coarse overlap refusal. The reported trace finds no CPU/page-walk/retained-piece store into the DCC range itself. Adding #6868 aa8f734907 reaches the 32 s bound in 2/2 runs, with reported final-image mean differences of 3.8 and 4.3/255 over 32x24 cells. This resolves the writer-classification question for that reproduction; Marc acknowledges it.
#6868 remains open and currently conflicts with main; aa8f734907 was added to a local composition, not merged upstream. Marc's status correction makes that distinction explicit. This is the contributor's Linux evidence, not our local reproduction or a plain-main pass. The other three Ruffle visual tests, Windows and AMD remain unverified. It does not classify or establish a fix for our older Sonic driver-overlap stop; the full-range clear is separate.
AI-assisted report maintenance: yes (Codex). Historical experiments and source pins follow.
Historical Sonic observations and controls at their original pins
User-data scope correction (2026-10-15 UTC): the earlier manifest restored tracked legacy /app0 files; the game uses /data/UnleashedRecomp, which was outside that audit. Protected original/runtime/guest-libc hashes remain verified, but full active-user-data restoration and identical active-save state were not established. The first “None” configuration trial edited the legacy file and is invalid as a no-AA test. Maintained correction and verified two-root snapshot/restore scope. Numeric fixture evidence remains valid.
Independent manual launch, 2026-10-17 17:08:52–17:09:18 UTC
The user double-clicked the prepared launcher for the same c784 integration, with the standard retained conversion. The saved log independently confirms the selected NVIDIA GeForce RTX 5080 (10de:2c02) and the identical final exception: writes to a resident multisampled DCC target or its metadata are not implemented (DCC range 0x40819f4000+0x87000, 8 samples). The console reported exit -1073740791 (0xC0000409). This confirms the current automatic-run stop during an ordinary user launch; it is not an unchanged-main run, menu/gameplay result, or new capability fix. No screenshot or FPS measurement was taken for this manual run.
Preserved local log: sonic-nvidia-31791-5827.log, SHA-256 7126c36cfac8d60ee656991d07cad678cac3a5afb6e13015a9bc924a0b573b4c. AI-assisted log analysis; user-operated launch.
Latest current-integration title replay, 2026-10-17 UTC
Integrationc784faf893, main667 plus retained fixes, #7187cf84 and #7196 head28ea, reaches this resident8x DCC refusal on verified RTX5080 after28.656s from a long physical root (metadata filename274 characters). Range remains 0x40819f4000+0x87000;7 captures, last initial NOW LOADING. AMD Radeon Graphics stops after70.750s at vkQueueSubmit recorder: Vulkan result -4,3 captures, last NOW LOADING. Both exit0xC0000409, no timeout/input, protected inputs/configs unchanged; Khronos1.4.363 loaded with zero observed validation errors/warnings.
All127 built libraries match each respective runtime and between GPUs; a515 executable/guest conversion retained. Full Windows/Linux relinker/library builds and51/33 focused filesystem/stream/archive passes. Current pins, hardware and complete scope are maintained there. This is a combined-integration observation, not isolated proof for either path correction or a common AMD/NVIDIA cause. Source audit correction: e040cb7 is already an ancestor of integrationc784 and earlier observers567/3c4. The active checkDccCurrent expression includes UnchangedSince(...) || !StoredOver(...). Our earlier statement that this candidate was outside the current integration was wrong. The current Sonic refusal therefore occurs with that proof enabled; it does not show that enabling it would unblock this stop. Next observe the existing rejection reason without changing its decision. The #7195 metadata capability is now independently validated through #7196.
Earlier c97 resident DCC refusal, 2026-10-17 UTC
#5939 merged initial uniform-DCC import. Fresh Sonic PPSA99902 validation at integration c97d127064, containing main e09dbc2b42 and the retained #7085/#6280/#6934 composition, reproduces the resident refusal on NVIDIA after27.608s:
AGC graphics: writes to a resident multisampled DCC target or its metadata are not implemented (DCC range 0x40819f4000+0x87000, 8 samples)
Verified RTX5080 (10de:2c02), driver32.0.16.1062, Windows11 Enterprise26200;7 captures, last initial NOW LOADING. This matches the earlier confirmed8398 range/sample count. The DCC plane is known; its first writer, value, ordering and required transition are not. No guard was relaxed.
The matching-runtime AMD run (1002:13c0, driver32.0.21036.18) reaches initial NOW LOADING (3 captures), then stops at71.108s with vkQueueSubmit recorder: Vulkan result -4; a common cause is unestablished. Both exit0xC0000409 without timeout/input, have zero observed Khronos1.4.363 errors/warnings and preserve protected original executable/module/configuration hashes. Fresh ordinary conversion, all127 matching PRXs, isolated fresh assets/user data and unchanged configuration. Exact executable, guest-module, library and dependency hashes match across GPUs. These are integration results, not plain-main startup or gameplay. #3036/#4443 maintain the full current table; #7066/#7085 retain focused extra-mip evidence. AI-assisted: yes (Codex); author responsible.
Earlier bounded replay variation, 2026-10-17 UTC
Earlier5045 with existing tracing was deliberately stopped at300.640s, byte-identical5045 without tracing at316.723s, and exact archived8398 reached its300s harness limit (300.782s total). All last captures show initial NOW LOADING with zero observed core validation errors/warnings and unchanged protected original/configuration hashes. Those non-reproducing results remain valid alongside the new c97 reproduction above; no cause for the variation is established.
The trace/plain pair shares executable/module/all127 library/dependency hashes; archived8398 matches the earlier failed runtime hashes. Existing capture buffer notes did not record overlap with the earlier reported DCC range, but its live allocation was not established, raw CPU stores are not covered and forced termination may lose buffered tail records. This does not identify or exclude a writer. Tracing and #6934 are not established causes. The first writer and required transition remain unknown.
Rejection reason confirmed, 2026-10-17 UTC
Public-source observer7b5b036a9f preserves the existing decision and reports which StoredOver predicate rejects. NVIDIA RTX5080 stops after28.644s at the same DCC range, with this intact record:
plane=DCC address=0x40819f4000 bytes=0x87000 generation=18598 samples=8
unchanged=0 stored=1 reason=driver-overlap
This identifies a retained driver-store piece intersecting the range after its saved generation. It rules out a coarse-only rejection, CPU-page branch, unknown/evicted-history branch and Windows host-region uncertainty as the branch taken in this query. It does not yet identify the producing AnyPS5 call or establish the exact underlying GPU store. The e040 adjacent-store proof is already active in this integration.
AMD Radeon Graphics still stops at Vulkan device loss-4 after73.150s, without a stored=1 rejection record. Both runs exit0xC0000409 without timeout/input;7/3 captures, last initial NOW LOADING, original inputs/configs unchanged. Windows11 Enterprise26200; drivers32.0.16.1062 /32.0.21036.18; Khronos1.4.363 loaded, zero observed validation errors/warnings. Compared with integrationc784, runtime roots have equal lengths, executable/guest module/dependencies and123 of127 PRXs match;4 changed modules are Agc, AgcDriver, SystemService and VideoOut. These are diagnostic integration observations with the a515 conversion retained, not unchanged-main or isolated AGC-DLL results.
The observer's full Windows/Linux relinker/library builds pass. Existing2x/4x/8x DCC controls pass3 times per physical GPU (18 passes); Linux4x plus write-watch controls pass3 each (6). Adjacent writes still pass and same-value overlapping stores still refuse. Clang-tidy completes without selected diagnostics on both changed TUs; Cppcheck retains the pre-existing conditional-unique_ptr advisory, without parser failures. Next trace the source call that records the overlapping driver store. No new capability fix or common AMD/NVIDIA cause is claimed.
The recording call is identified
Observer78db9b00c9 adds source-location records for writes overlapping registered resident metadata ranges. NVIDIA reproduces the same refusal after28.624s. The rejected piece is 0x40819f4000+0xc000, generation19101, newer than saved18564. It exactly matches a record from BdaResources::markWrittenPages, line322.
That call records five ranges whose union is the DCC plane0x40819f4000+0x87000, plus CMASK0x40819e0000+0x14000. This identifies the AnyPS5 recording path, not the exact GPU instruction or written value. BdaAbi::ForEachWrittenRange emits4KiB page ranges, so full page-range coverage does not prove every byte was overwritten or establish a uniform clear. The overlap refusal remains unchanged.
Full Windows/Linux relinker/library builds pass at78db; the existing positive/refusal fixture gives18 physical-GPU passes and6 Linux controls again. Static analysis retains the same unchanged-code Cppcheck advisory and no selected clang-tidy diagnostics; no parser failures. The NVIDIA run retains the matched root length, executable/guest module/dependencies and123 libraries; the same4 modules change as in7b. No timeout/input or original-file changes,7 captures with last NOW LOADING, zero observed Vulkan validation errors/warnings. No AMD title rerun at78db is claimed; its7b result remains separate.
The e040 candidate is already carried upstream by MarcZX100 as #7132, preserving our three original commits unchanged. It is active in these integrations; no duplicate PR is needed. Next establish the metadata-write semantics with public-source/generated fixtures before proposing a capability change. In particular, page coverage alone is insufficient justification for accepting a full metadata reset.
Confirmed neighboring-store gap; title causality under validation
Main c9e6c45de9 has a separately reproduced false refusal: after importing/drawing a DCC target, a driver store outside its4KiB metadata range but inside the same64KiB tracker block makes the next resolve throw the resident-DCC exception. The supplemental regression fails3/3 on verified RTX5080 and AMD Radeon Graphics with unchanged production code (test-only975c3ee6b3). This does not identify Sonic's writer.
Retained focused candidatee040cb7f75 preserves the existing unchanged-generation proof and additionally accepts the existing finer StoredOver proof after the same uncached collect. Actual overlapping writes still refuse; unknown/evicted fine history stays conservative. Keeping the original proof matters because StoredOver deliberately treats Windows host regions as uncertain. This supersedes the query-only6eeb draft; the draft's title observation was deliberately stopped at63.195s after source review, not an application failure or completed test.
At exact e040, the full fixture passes2x/4x/8x three times each on both physical GPUs (18 passes) and4x three times on llvmpipe (2x/8x unsupported/skipped). Adjacent driver/CPU stores preserve rendered samples; same-value writes inside DCC and the existing CPU color/DCC/CMASK, unwatch and unmap controls still refuse. Windows Khronos1.4.363 runs have zero observed errors/warnings. Both OS relinker/library builds and CPU graphics groups pass3/3. Clang-tidy is clean on both changed TUs; Cppcheck has only the unchanged conditional-unique_ptr warning at line48, manually triaged. No globally-clean-analysis claim.
Latest title check: observer3c4 on refreshed integration15f/main21 completes300s on each physical GPU at initial NOW LOADING. The Pad layer consumes all six scheduled command records in each process, while neither log emits a DCC proof-entry or coarse-change decision. This does not exercise or validate the finer proof for Sonic. The no-candidate a515 control and earlier5b5 observations also lacked the refusal; c97 remains a confirmed earlier reproduction. #3036 maintains exact durations, hashes, captured screens and limitations. The focused candidate remains synthetic-tested; no title-fix or common-cause claim.
Earlier initial-import, diagnostic and geometry validation at its original pins
Current fork evidence: retained integration e86150f84 includes main82, the merged #6784 journal correction and the validated #6789 CPU-fixture correction. The shared status/coverage distinguishes its tested pins and the earlier CPU graphics failure #6792 and its now-validated #6789 correction. GPU clear evidence below remains at its original source pin; the current main82 selection covers shader preparation, folding and signed image stores plus one sampled-publication control per device. It does not repeat the unrelated native-clear matrix.
At its pre-journal-fix pin 2a476ed69, the selected --native-clears-only mode passes 3/3 fresh processes on each physical NVIDIA/AMD GPU in each default/opt-in dispatch mode. Each process checks RGBA8/RGBA16F at2x/4x/8x, four known DCC clears reaching every sample, plain-buffer bounds and the existing same-value CPU metadata-store refusal. These are public fixture assertions in the broader retained implementation. Commit-item eligibility for each clear is not asserted. The other legacy neighbor/import experiments are outside this mode's coverage.
#5939 remains the focused initial-DCC-import proposal; the retained resident-clear work is broader. The historical title frontier and scalar geometry evidence below keep their original pins. No fresh title run or console-equivalence result follows from these checks. AI-assisted: Codex.
Earlier DCC geometry and title evidence at its original pins
Proposed capability: PR #5939 (2026-10-15 UTC)
PR #5939 is pushed at 3851b712c, tested on main1db. The rebase fixes the newly introduced createFilled guard call to forward metadataValid. Its capability remains uniform initial DCC00/40/80/c0 clears in supported watched2x/4x/8x native targets. Other metadata and later-write paths still refuse.
Full Windows app/libs/conventions/registration pass;16 groups once+5 per selector pass with no failures/skips, maximum8.01s. Eight runtime groups have per-run NVIDIA/AMD identity; two legacy recorder groups are NVIDIA-only. Ubuntu24/GCC13.3 builds four fixtures; five supported lavapipe groups pass once+5, while unsupported2x/8x attachment cases skip. The PR description maintains exact hardware, coverage, limitations and historical red/geometry-control pins. The earlier main8f51 controls and225-case x5 PAL geometry results are not relabeled as new-base controls.
Independent title evidence: milescoviello's retest builds3851 on maina08/Linux/RTX4070Ti. Rush2 and the MGS4 manual pass the original check2/2 each, then reach unsupported CMASK/register-clear state; Rush2 also encounters resident metadata writes. Their main0afa controls reproduce the original refusal. The main pins differ, and the combined diagnostic does not identify one specific unsupported metadata mode. These are external observations; remaining paths stay within this issue's scope.
Owned Sonic validation: the historical focused8d375/main324 replay passes the initial decode check and stops at watched-memory requirements after29.343s. The latest measured broader replay remains5aa: loading after706.328s at the resident-MSAA write guard. Current fork integration, fresh synthetic checks and restored-user-data scope are maintained separately. No new title replay, gameplay or FPS result follows from this rebase. Earlier runtime/user-state claims remain subject to the correction above. AI-assisted: Codex.
Preserved scalar replay evidence
Previous scalar geometry replay (2026-10-13)
Integration 3e1ddb0f1 is rebased on main 8cf6a0bc3a17782e8f1063d1127f72419260230b and pushed to the fork. Fresh original-ELF/guest conversion and 127 rebuilt libraries (130 runtime files) pass five loader checks. Full native Windows/NVIDIA validation: 1094 passed / 0 failed / 8 skipped of 1102, max24.2365s; 21 relevant groups x5 under each requested GPL setting. The added diagnostic reports optional registers explicitly, including absent; eight synthetic cases cover sample/mode combinations, missing fields and present zero. The new assertion fails on the preceding diagnostic.
Fresh game replay stops after 32.440s, 0xC0000409, no timeout, with:
[videoout] presentation failed: AGC graphics: DCC over a multisampled color target is unsupported (slot 0, samples 8, CB_COLOR_INFO 0x18066730, CB_COLOR_CONTROL 0x00cc0010, CB_COLOR_ATTRIB2 0x03bfc86f, CB_COLOR_ATTRIB3 0x4dc6c000, CB_COLOR_VIEW 0x00000000, CB_DCC_CONTROL 0x00100038)
ATTRIB2 decodes to 3840x2160; mode1/8samples/DCC remain confirmed, VIEW0. This establishes current command-state fields, not DCC metadata contents or a completed capability fix. Original dump, baseline runtime and user data are restored and verified with no cleanup errors.
The preserved native-MSAA integration contains earlier DCC/initial-content/coherence support. It has not all been carried into this narrower refreshed integration. #4443 now explicitly inventories the uncovered work and submission boundaries; the older farther startup frontier is not obsolete or an unchanged-main result. Only diagnostic scalar fields were added here; no shader/assets attached. AI-assisted: Codex.
Fork 99a159a16, on main5d + #5939, preserves the resident-DCC refusals and adds the affected color/DCC/CMASK plane, range and sample count. The maintained PR comment records full Windows build/testing on both physical GPUs, old-diagnostic control/restoration, selected Linux checks and static-analysis scope. This is a separate fork proposal, not a new clear capability or title result. A repeated-fill fixture attempt lost its watched-memory prerequisite and was excluded as transition evidence. The game's first writer/plane remains unidentified; no new issue or duplicate capability PR is justified by that attempt.
Confirmed startup stop
Sonic Unleashed Recompiled PPSA99902 01.003.000, Windows 11 Enterprise 26200, NVIDIA RTX 5080 (10de:2c02), driver 610.62 / 32.0.16.1062.
Fresh original-ELF conversion with integration a3536c9 based on main 0214069e33ccfab4bd97ec973637299895f786d0 stops after 32.560 s with DCC over a multisampled color target is unsupported. Merged #4588 resolves the earlier missing SoC sensor import binding.
An otherwise identical replay with diagnostic a7a0bf3 stops after 31.577 s with:
[videoout] presentation failed: AGC graphics: DCC over a multisampled color target is unsupported (slot 0, samples 8, CB_COLOR_INFO 0x18066730, CB_COLOR_CONTROL 0x00cc0010)
(0x00cc0010 >> 4) & 7 == 1: this is normal rendering, not Mode 5 FMASK decompression. DCC_ENABLE (CB_COLOR_INFO bit 28) is set, slot 0 has 8 samples. Both runs exit 0xC0000409, without timeout. The diagnostic changes only AGC; the other 129 runtime files and converted executable/guest module are unchanged. Originals, baseline runtime and user data are restored and verified after both runs.
Existing work and scope
- Current main
8cf6a0bc3a17782e8f1063d1127f72419260230bstill has the same unconditional multisample-DCC refusal; this is source inspection, not an unchanged-main game run. - fix(agc): handle FMASK decompress on MSAA targets #4767 at
02b40581a00f1eb5aa63c74d738d4e8417ab77b5admits DCC only for Mode 5 FMASK decompression. Its normal-render path retains this refusal. This is a distinct state from AGC: FMASK decompress over a 4x MSAA target with CMASK, FMASK and DCC stops Ruffle's player (PPSA68091) #4685. - feat(agc): sample a multisampled color target through its 2D MSAA texture #4820 covers sampling an existing host-rendered MSAA target; fix(agc): read direct FMASK images from metadata snapshot #4790 covers direct FMASK reads; fix(agc): retire fully unmapped multisample targets #4474 covers retirement. AGC: sampled 2D MSAA image has no descriptor shape (PPSA99902 conditional startup) #3036 and Shader: compressed FMASK/CMASK image reads remain unsupported (PPSA99902) #3219 retain earlier sampled-image and FMASK findings. None of these is an established fix for this normal-render decode stop. Bounded searches covered open DCC/MSAA reports and the exact exception.
Validation and next fix
The linked fork change enriches the exception; it does not remove the guard or implement DCC support. Seven synthetic rejection cases cover 2/4/8 samples in modes 1/5 plus missing control. They fail against the old diagnostic and pass with the change; 20 CPU repetitions pass. Full native build/libs/conventions/registration pass; seven relevant groups x5 under each requested NVIDIA GPL mode and five frozen-library load checks pass. Parent integration full suite: 1092 passed / 0 failed / 8 skipped of 1100; no new full-suite claim for the diagnostic.
A proposed capability fix must model supported DCC/CMASK initial state and metadata/coherence transitions, preserve every sample, and throw on unresolved states. The current scalar diagnostic does not establish metadata contents, dimensions or console geometry. Earlier fork implementations in #3036 are investigation material, not a validated current-main patch. No shader/dump assets attached; no console/AMD/Linux validation or rendering-accuracy claim.
Bring-up tracking: #4443. AI-assisted investigation, diagnostic and reporting: Codex.
Separate tracker-proof finding
The written-page source identified above led to #7220: on unchanged main production code, sparse BDA stores can falsely satisfy complete 4 KiB overwrite coverage. Independent wave32/wave64 tests reproduce 3/3 on both physical NVIDIA and AMD GPUs. The issue links the failing test branch and an experimental proposal. Its 54 earlier controls passed, but a new real-GPU producer control shows that proposal rejects legitimate full BDA-written native HTILE clears on both GPUs; it is not ready for promotion. The unchanged-main positive control and proposal regression are preserved on the fork and documented in #7220. This does not identify the actual bytes/values written in this title's metadata, prove that its resident-DCC refusal is wrong, or provide a DCC capability fix. Follow #7220 for the tracker semantics; this issue remains the title's current NVIDIA stop.
BDA producer narrowed, 2026-10-17 UTC
Observer a221350909, on the same mainf219 composition, connects each BDA page report with its resource's BDA shader-stage/variant candidates and the compute driver program mapping. It retains multiple program candidates rather than overwriting a shared variant with a guessed last shader; it does not change write classification or any clear/refusal decision.
The completed RTX5080 run reports six overlapping ranges, all compute (stage=0x20), variant32, with the single recorded program candidate 0x20b8b6900. One covers the whole CMASK range; five page-report intervals together cover the DCC range. Generations19217–19222 follow saved generation18683. This narrows the producer from generic BDA reporting to that compute resource/variant. These remain page-granular reports, not proof that every byte was stored, nor an instruction-level program attribution. The program candidate differs from the accepted HTILE kernel at 0x20b8b6700; its exact operation/required native-image transition is not yet established.
The guard still refuses with driver-overlap, DCC and CMASK snapshots remain identical to the table below, and the final inspected frame is NOW LOADING. Exit0xC0000409 after28.610s, seven frames, no timeout/input, verified 10de:2c02, zero observed Vulkan validation errors/warnings. The a515 conversion is retained. This replay reused the completed013 runtime's assets/user state rather than making a fresh-state A/B claim. Prior code, frames, active data and config were archived and 142 prior files were hash-verified restored afterwards; new code and captures are preserved separately, and protected originals/configs remain unchanged.
Full Windows/Linux relinker/library builds pass. Five relevant groups repeated3 times give 15 confirmed-device passes each on NVIDIA and AMD; the standalone BDA-device fixture also passes3 times in each selector run, but does not report its selected device and is not counted as dual-vendor evidence. Linux gives9 passes across three groups and3 explicit skips; its standalone fixture also states that CPU-Vulkan BDA execution was not tested. Static analysis parses all four changed TUs, with advisories in unchanged timer/capture-trace code and an unchanged ShaderResources null-reference path; these are untriaged, not a clean-analysis claim. No AMD title replay or new capability fix is claimed.
Earlier accepted-kernel observation, 2026-10-17 UTC
Diagnostic 013d65ff34 is based on refreshed integration5f7a/mainf219. It preserves the existing refusal and metadata matching/notification decisions. It adds bounded records at the existing accepted HTILE-mask dispatch recognizer and snapshots both metadata planes at the refusal.
A fresh isolated NVIDIA RTX5080 (10de:2c02) run exited 0xC0000409 after 29.102s, without timeout or input. Seven captures were saved; the inspected final frame remains NOW LOADING. The same DCC range is rejected with unchanged=0 stored=1 reason=driver-overlap.
| Plane | Range | Initial and current bytes | Changed bytes / pending overlap |
|---|---|---|---|
| DCC | 0x40819f4000+0x87000 |
all552,960 bytes 00 |
0 / 0 |
| CMASK | 0x40819e0000+0x14000 |
all81,920 bytes cc |
0 / 0 |
The recognizer logged six dispatches, all at program address 0x20b8b6700: twice each to 0x402ea00000+0x400000, 0x404f600000+0x400000, and 0x4091b00000+0xa0000. None overlaps either plane above; the512-record cap was not reached. This excludes those six accepted cases as attribution for this range. It does not exclude other kernels, rejected recognizer variants, or other draw/dispatch consumers. The actual producer is still unknown.
Snapshot equality does not prove that no store occurred, a complete clear happened, or host-image reuse is safe. Same-value/partial stores and conservative page overlap can leave identical bytes. No guard was relaxed and no capability fix is claimed.
Validation of013d: full Windows/Linux relinker/library builds; native-depth BDA positive control plus2/4/8-sample DCC controls repeated3 times on each verified physical GPU (12 NVIDIA +12 AMD passes, no skips). Linux/lavapipe4-sample DCC passes3 times; native-depth and2/8-sample cases explicitly skip, accepted by the CI skip classifier. Both changed TUs parse in static analysis. Cppcheck reports the unchanged conditional-command-batch advisory; clang-tidy also reports a possible null call in unchanged PerformanceTimer.hpp:74, not yet classified against a baseline. Static analysis is therefore not claimed clean.
All127 built PRXs were copied from013d; the standard a515 executable/guest conversion was retained. Fresh original assets/user data/configs were copied into an isolated runtime; protected original inputs/configs remain unchanged. Khronos validation1.4.363 loaded, with zero observed validation errors/warnings. This is a diagnostic integration run, not an unchanged-main result. No new AMD title run, menu/gameplay or FPS result is claimed.
Previous snapshot46d7fb06ee, on main667/integrationc784, already found unchanged all-zero DCC bytes after28.644s. Its18 physical-GPU DCC passes and3 Linux passes retain that original pin; the current replay extends observation to CMASK and the accepted dispatch recognizer.
Next: attribute the retained driver-store overlap to its actual producer before implementing a metadata/coherence transition. #7220 tracks the separate coverage-proof mismatch; test-only #7228 protects valid full native-depth GPU clears and does not unblock this color-DCC stop. AI-assisted diagnostics, validation and reporting: Codex.
Historical handoff recovered with #7250, 2026-10-17 UTC
The old08891d938 menu/cinematic branch preserved constant-fill recognition plus a resident DCC clear transition. #6543 restored recognition to6146, but its no-observer Sonic replay still stopped at the same8x DCC guard after28.101s. The new existing #7250 implements the corresponding transition through today's NoteColorMetadataFill/resident-image backend.
Canonical fork6d76fb2098 now tracks main922 and composes #7250 head257a4707, preserving original authorship and all previous6146 fixes. Detailed validation: full Windows/Linux builds,21 repeated passes per verified NVIDIA/AMD GPU without skips; supported Linux/lavapipe groups pass,2/8-sample cases explicitly skip. The new refill tests fail before the change on both physical GPUs.
Sonic on RTX5080 now reaches PRESS START (120s no-input observation), then the CONTINUE menu and opening cinematic in a second240s observation (240.899s recorded,61 frames,four ordinary controller-file pulses). Both runs were deliberately terminated at their bounds with no fatal line; no gameplay/FPS or natural-exit claim. All127 libraries came from6d76; standarda515 conversion and prior isolated assets/user state were reused. This is not a fresh-state or isolated-main comparison. Protected originals/configs remain unchanged;142 prior files hash-restored after each run, new code/captures archived.
The historical insight has now recovered a concrete milestone on the current backend. Continue beyond the movie and use preserved historical calls/behavior to investigate the next refusal. No separate duplicate PR is needed for this handoff; validation is on #7250. Earlier producer/page-granularity limitations and the held fe08 proposal retain their original scope. AI-assisted: Codex.
Extended frontier: the same6d76 build now reaches the post-movie level-loading/tutorial screen, then exits after758.222s (no timeout) on a different refusal, mipmapped 3D color targets are unsupported.96 frames/four normal input pulses;142 prior files restored and originals unchanged. The earlier resident-DCC stop did not recur. Issue7260 owns this distinct missing path; gameplay remains unverified.
Activity
milescoviello commentedon Oct 15, 2026
Another title that stops here: Rush 2 Recompiled (PPSA69423, catalog release, no ROM installed) on Linux (Ubuntu 24.04, GCC 13.3, Release, RTX 4070 Ti).
maina077a88: stops 1 s after start-up withAGC graphics: DCC over a multisampled color target is unsupported.multisampled DCC CMASK compression or register clear is not implemented. So this title needs more than the uniform initial-clear subset.(#5939 does not build merged onto current
maina077a88:MultisampleTarget.cpp:396, too few arguments toguard.)AI-assisted: yes
milescoviello commentedon Oct 15, 2026
Another title that stops here: Metal Gear Solid 4 (PPSA18194, 01.004.003). Its Master Collection launcher aborts when Online Manual is opened from its Start Menu, as it loads the manual's
bookassets_*bundles, 2 of 2 runs onmaind92a8da (Linux, RTX 4070 Ti, NVIDIA 595.99, GCC 13.3, Release):#5939 doesn't compile merged onto that
main; details on #5939.AI-assisted: yes
screamm commentedon Oct 17, 2026
Another title now stops on this path on
main, and it is a regression from #5939: Ruffle (PPSA68091), Windows 11 Pro 26220, NVIDIA RTX 4070 (driver 596.21), WinLibs MinGW-w64 GCC 15.2, Release, Cross pressed to start the demo, 120 s limit.main5d9dcc4 (before feat(agc): import uniform multisampled DCC fast clears #5939, 2026-10-16): 3 of 3 runs alive at the limit (125 s; 897, 604, 627 frames), no driver failure.main3b10c7e (after feat(agc): import uniform multisampled DCC fast clears #5939a0c51d577, 2026-10-17): 2 of 2 runs stop at 13.9 s and 17.9 s (545 and 386 frames), exit0xC0000409, right afterRuffle PS5: stage: game loop:2fc4fe5e0) merged on top, the CMASK line is gone and the run reaches the stop this issue tracks, 2 of 2 (76.6 s and 59.4 s):AGC graphics: writes to a resident multisampled DCC target or its metadata are not implemented. Adding or removing fix(agc): read a multisampled target's CMASK by its MSAA codes #6669 (8455a5cce) changes nothing here: Ruffle's target has DCC, so thedccAddress == 0CMASK seed that fix(agc): read a multisampled target's CMASK by its MSAA codes #6669 changes is not reached any more.the CMASK ... of a multisampled color target reads as mixed, which is not modeled) did not appear in any of 8 runs on currentmain.Logs and frame dumps are kept locally if someone wants a specific one. Not checked: AMD/Intel, Linux,
APS5_NO_RESIDENT_TARGETS=1.Written with Claude Code assistance (validation by a subagent, reviewed in this session).
Amoenus commentedon Oct 17, 2026
@screamm @milescoviello Your two Ruffle runs identify the DCC metadata plane:
0x4004606000+0x14000, 4 samples on main e09 + #6543 + #6869. I have not independently run Ruffle.We have now confirmed a separate possible source of false refusals. In the supplemental synthetic test, a store outside the DCC metadata range but inside its 64 KiB tracking block makes the existing coarse generation check fail. Test-only control975c3ee6b3 fails3/3 on each physical NVIDIA/AMD GPU with unchanged mainc9 production code.
Focused proposed change, mainc9...e040cb7f75: retain the original unchanged-generation proof and additionally accept the existing finer
StoredOverrange proof. Actual overlapping/same-value stores still refuse; unknown history stays conservative. The original proof is retained because the fine query deliberately treats Windows host regions as uncertain. This is one production expression plus fixture coverage; the intermediate query-only draft is superseded.The exact focused candidate and refreshed integration15f pass2x/4x/8x three times per physical GPU; available4x llvmpipe also passes. The issue body maintains the full controls and limits. This is not an established fix for either title: Sonic c97 reproduced its refusal, but the later no-candidate a515 control and candidate5b5 both remain in loading without that refusal. A matched Ruffle before/after run, retaining your other dependencies, would help distinguish a neighboring-store false refusal from an actual overlapping write. No common writer or metadata transition is established.
The completed public-source observer3c4 stays in initial loading for300s on each GPU: the Pad layer consumes all six records, but neither log emits a DCC proof-entry record. This supplies no Sonic title evidence for the finer proof; the matched Ruffle check remains useful. Current title evidence stays in #3036. AI-assisted: yes, Codex; author responsible.
Source audit correction: e040cb7 is already an ancestor of integrationc784 and earlier observers567/3c4. The active
checkDccCurrentexpression includesUnchangedSince(...) || !StoredOver(...). Our earlier statement that this candidate was outside the current integration was wrong. The current Sonic refusal therefore occurs with that proof enabled; it does not show that enabling it would unblock this stop. Next observe the existing rejection reason without changing its decision.Current Sonic source-only observation now reaches the check: 7b5 details in the issue body report a retained
driver-overlappiece at DCC0x40819f4000+0x87000 (8 samples), with the e040 proof active. Its producer remains to be traced. This does not attribute Ruffle or AMD device loss to that same cause.milescoviello commentedon Oct 17, 2026
@Amoenus Here is #6869's diagnostic line from Ruffle (PPSA68091). Linux, RTX 4070 Ti (NVIDIA 595.99.02),
maine09dbc2 + #6543 (2fc4fe5) + #6869 (58ba8a9), 60 s with scripted pad input, 2 runs:Both runs stop at 10 s on this line, with the same range, when the demo starts. So for Ruffle it is the DCC plane too, like your Sonic line. On plain
mainthe title stops earlier, onmultisampled DCC CMASK compression or register clear is not implemented, as screamm reported above; #6543 orders the fills first and moves it to this line.AI-assisted: yes (Claude Code)
screamm commentedon Oct 18, 2026
@Amoenus, here is the matched Ruffle (PPSA68091) run you asked for. Windows 11 Pro 26220, RTX 4070 (driver 596.21), WinLibs GCC 15.2.0 r7, Release,
ANYPS5_NO_SHADER_CACHE=1, Cross pressed to start the demo, 120 s limit. Basemain0d078f75d, which already has #7132 (theStoredOverneighbouring-store proof). Both arms have #65437bfb645ff; "after" adds #7250c92d72cc1(its only conflict was the debt entry).main(3e3e8b905, same DCC code)multisampled DCC CMASK compression or register clear is not implementedmain+ #6543 (before)writes to a resident multisampled DCC target or its metadata are not implemented... are not implemented (DCC range 0x4004606000+0x14000, 4 samples)main+ #6543 + #7250 (after)All stops come as the demo starts. With #7132 active on
main, the refusal is still on the plane you identified,0x4004606000+0x14000at 4 samples. That is exactly the DCC fill #7250 lists for Ruffle (0x4004606000+0x14000<-0xc0c0c0c0), and taking that fill as the target's fast clear removes the stop. So on this machine this is not a neighbouring-store false refusal. It is the title's own whole-range DCC fast-clear fill, which #7250 handles. I did not trace the writer itself; the evidence is the range plus the A/B.One caveat: with #7250, every presented frame from the demo start to the limit is uniform white (only the cursor shows). White is the
0xc0(1111) clear colour, so I can't tell yet whether that is what the demo really shows.Not checked: AMD, Intel, Linux, Sonic.
Written with Claude Code assistance (validation by a subagent, reviewed in this session).
MarcZX10 commentedon Oct 20, 2026
Status update: PR #7250 is merged. Its reported Windows run of Sonic Unleashed Recompiled with #6543 passed the previous NOW LOADING stop, reached PRESS START, the CONTINUE menu, the opening cinematic and level loading, then stopped at the separate mipmapped 3D target issue #7260. This is integration evidence for that run, not a main-only or gameplay result. The original #5336 failure therefore appears cleared in the tested composition; #7260 is the next reported blocker.
milescoviello commentedon Oct 20, 2026
@MarcZX10 Here is where Ruffle (PPSA68091, 1.2.0) stands on current
mainfor this issue. Linux, RTX 4070 Ti (NVIDIA 595.99.02), Cross pressed to start the demo:maina9c93a0 alone aborts at start-up before the first frame. The guest's own RADV printsxmlconfig.c: 389: out of memory.Since fix(libc): share the guest SDK application allocator #6610, HLE adopts the allocator of thelibc.prxRuffle bundles, and that allocator isn't initialized here, so its first 32-bytestrdupgets NULL. fix(libc): adopt the guest SDK allocator only when the title replaces the heap #7897 (babyhuey) restores the default heap for a title whose replacement table is empty, which is Ruffle's case.FMASK format is not implemented. Its resolve reads a 4-sampleFmask8_S4_F4, which fix(agc): read uncompressed FMASK images from guest memory #6674 doesn't accept. fix(agc): read FMASK of up to 8 samples in every storage width #8429 reads it.It still appears in one of Ruffle's own visual tests.
filters__displacement_map(ruffle-rs/ruffletests/tests/swfs/visual, injected as the only library game) stops at 12 s on the same build:That is the same plane the demo used to stop on. So for Ruffle, #5336 is cleared for the demo but not for this SWF. Of the 36 frame-1 visual tests, 32 run to the limit, and 29 of those match their expected images. The other three stops are a compute storage view of a multisampled target (
gradient_issue_9892,color_transform_issue_9698) and an initial multisampled DCC key (opaque_background). All four stops are the same as on 10-18.AI-assisted: yes (Claude Code)
MarcZX10 commentedon Oct 20, 2026
Thanks, this narrows the current evidence: the Ruffle demo reaches the 120 s limit only in the composition with #7897 and the still-open #8429, while
filters__displacement_mapstill reaches the resident-DCC write refusal on that integration. I would keep the issue open for the latter case. Do you have the rejection reason or writer classification for that exact visual test run (for example, whether the DCC range is reported as a driver-overlap piece or as a direct write into the metadata plane)? That would help distinguish the remaining store path from the now-handled full-range clear.milescoviello commentedon Oct 20, 2026
@MarcZX10 it's a driver-overlap reading, not a direct write into the metadata plane. Same build as before:
main390ec58 + #7897 (4a5ce8a) + #8429 (4660cdd), Linux, RTX 4070 Ti (NVIDIA 595.99.02),filters__displacement_mapwith Cross pressed.I added a temporary print where the check refuses the range. It shows each 64 KiB tracking block the DCC range
0x4004606000+0x14000covers, against the import generation 9904:0x400461a000every frame. That is the first byte after the DCC range, in the same block.dropped. A block withdroppednewer than the import reads as stored over for any range, so the refusal fires.This is the same pattern I reported on #7233 on 10-18 for this SWF and the bevel/glow filters, on an older base.
With #6868 (aa8f734) merged on top,
filters__displacement_mapruns to the 32 s limit 2 of 2, with no driver failure. Its last frame matches the test'soutput.expected.png, a mean difference of 3.8 and 4.3 of 255 over 32x24 cells. #6868 reuses a retained piece when the new store falls inside it, so the repeated 8-byte word stops filling the list. Its debt-file conflict with this stack was the only one; I resolved it by keeping the stack's text.So the remaining Ruffle case under this issue looks like a false refusal from the coarse
droppedstate, not a new store path into the DCC. The full-range clear isn't involved. Not checked: Windows, AMD, the other three stopping visual tests.AI-assisted: yes (Claude Code)
MarcZX10 commentedon Oct 20, 2026
Thanks; that trace answers my question. The refusal was caused by
droppedhistory from repeated 8-byte writes elsewhere in the same 64 KiB tracking block, not a write into the DCC range. With #6868 merged, thefilters__displacement_mappath reached its 32 s limit in 2/2 runs, so that specific reproduction is improved. The other three visual tests, Windows, and AMD remain unverified per your report.MarcZX10 commentedon Oct 21, 2026
Small status correction: #6868 is still open on GitHub, so the
aa8f73490results described above are from that PR head / a local composition, not a merge intomain. The PR currently reportsDIRTYagainstmain, so the issue remains unresolved on the published branch. The test results are still useful evidence for the proposed fix.