Skip to content

AGC: MSAA DCC-clear resolve checks fail on AMD Radeon iGPU at 2x/4x/8x #7936

New issue
New issue
Closed
Closed
AGC: MSAA DCC-clear resolve checks fail on AMD Radeon iGPU at 2x/4x/8x#7936

Description

@Amoenus
Amoenus
opened on Oct 19, 2026

Resolved on the reported iGPU with current main/new drivers — 26 October2026

The requested post-update run on the original Ryzen9950X3D iGPU1002:13c0 is complete. On literal main5b5d24cb223ede690fe5eab1fe2f7a1736b801a5,the real agc_driver_msaa_dcc_clear_2, _4 and _8 each pass 3/3 on AMD and3/3 on RTX5080:18passes. The fixture reaches the original undrawn-sample/channel/scissor assertions and prints Multisampled DCC fast clear tests passed;no conditional omission or whole-test skip.

AMD32.0.21045.16010(26.10.1),NVIDIA621.01,Windows11Enterprise26200,WinLibsGCC15.2r7 Release,loaded Khronos1.4.363,required Vulkan/app cache and journal off,serial verbose CTest. Zero validation warnings/errors/VUIDs or timeouts;native/fixture hashes stable through the run. Driver caches/implicit layers not isolated.

Closing this current local reproduction. This agrees with the other newer-driver/RADV reports but does not isolate the driver as the fix:source and binary/cache identities also changed. The old executable survives,but its historical runtime-library hashes no longer match,so it was not presented as a matched driver-only rerun. Old source-pinned failures and external results remain below. Distinct native-owner recreation/publication cases remain separate. Exact pins and complete logs. No title/full-suite/performance claim. AI-assisted:yes(Codex).

Previous evidence and source-pinned history

Latest local verification, 2026-10-20 UTC

Unmodified pinned main e25333e39aac4ab537fdf8c143da0fc24634c714, matching rebuilt libraries/relinker and the real AlphaToCoverage.cpp fixture. Three fresh serial CTest processes per size/physical GPU:

DCC-clear size Radeon Graphics RTX 5080
2x 3/3 original resolve-assertion failures 3/3 pass
4x 3/3 original resolve-assertion failures 3/3 pass
8x 3/3 original resolve-assertion failures 3/3 pass

All nine AMD failures remain multisampled DCC clear did not preserve undrawn samples, channels or scissor pixels. Actual AMD Radeon(TM) Graphics iGPU 1002:13c0/gfx1036, driver 32.0.21036.18; NVIDIA RTX 5080 10de:2c02, 610.62/32.0.16.1062; Windows 11 Enterprise 26200, WinLibs GCC 15.2 r7/UCRT Release, SPIRV-Tools enabled. Required Vulkan, app shader cache/journal disabled, loaded Khronos 1.4.363; every process below 30 s, zero VUIDs/validation errors/warnings/skips/timeouts. Driver caches and implicit layers uncontrolled. This does not repeat the earlier implicit-layer-isolated setup or establish a driver-only cause. #8103's distinct NVIDIA 4x watch refusal did not occur in this slice; that issue is not closed from this observation.

Six other common GPU groups plus three CPU/mock groups pass in this main comparison: 54 positives total, separately from the nine failures. The earlier execution-not-built stub attempt is excluded; the CMake fixture list and compilation database were checked before these real executions.

The newer #6973/#6987 comparison reproduces the separate sampled-recreation resolve assertion on AMD before and after adding snapshots. That case remains distinct from this issue's assertion; no common cause or fix is established. No new title/performance claim. AI-assisted: yes (Codex).

Hardware clarification and external controls, updated 2026-10-24 UTC

Our failing device is the Ryzen 9 9950X3D's AMD Radeon(TM) Graphics iGPU, 1002:13c0 / gfx1036, AMD Windows driver 32.0.21036.18, Windows 11 Enterprise 26200. The external controls retain their reported pins; our fresh pinned-main matrix is recorded above.

  • thuanquang's RX 6700 XT/gfx1031 result: main dbac9fa15 (contains reported 7b18fa8d5), AMD Windows driver 32.0.21045.5002/Windows 11 26200, 2x/4x/8x each pass 3/3, without Khronos validation. The report therefore does not apply to every AMD Windows device.

  • simonbbby's gfx1036/1002:13c0 RADV comparison: reported main 7b18fa8d5d and later main 1e774a3b22, Mesa 25.2.8/Ubuntu 24.04, each size passes3/3 on the iGPU and RTX 3090 control (36 physical-GPU processes). No Khronos layer; host driver caches and implicit layers were not isolated. Lavapipe 4x passes; 2x/8x skip and are excluded.

  • LeandroLP23's Radeon 860M result: main 1381826358, device 1002:1114/RDNA 3.5, AMD Windows driver 32.0.13058.8001/Windows 11 26300; each 2x/4x/8x check and alpha-to-coverage passes 3/3, without validation. This is another passing AMD Windows iGPU, on different graphics IP.

  • CrimsonMac's newer-driver gfx1036 comparison: Ryzen 5 7600 iGPU 1002:164e, AMD Windows driver 32.0.21042.62/Windows 11 26100, both reported main e25333e39 and later a42f61d5b; each size passes 3/3 on the iGPU and RTX 4070 SUPER control. No validation layer; driver caches retained. This shares the gfx1036 graphics IP, not our exact PCI device or machine.

These reports narrow the observed failing configuration to our machine/driver combination; they do not isolate a driver bug, OS difference or hardware-specific cause. Our installed AMD driver was checked on 24 October and remains 32.0.21036.18. No new fixture runs or driver changes are claimed in this update. The next discriminating check is a same-machine comparison at a frozen source/fixture, before and after a supported AMD driver update, holding the validation configuration constant and retaining an NVIDIA control. Passing on another device does not by itself resolve this report. The distinct sampled-recreation AMD assertion in #6973 remains separate. AI-assisted: yes (Codex).

Earlier literal-main controls and observations at their original pins

Current verification — 2026-10-19 UTC

Rebuilt libraries/relinker and the unchanged fixture on literal main bf2c63f853. Three fresh processes per size and physical GPU, serially:

Test size Radeon Graphics RTX 5080
2x 3/3 fail: original resolve assertion 3/3 pass
4x 3/3 fail: original resolve assertion 3/3 fail: distinct resident-color watch refusal
8x 3/3 fail: original resolve assertion 3/3 pass

This control explicitly disables implicit Vulkan layers in each child process with VK_LOADER_LAYERS_DISABLE=~implicit~, retaining the verified loaded Khronos validation layer. Actual adapter identities are verified; all18 logs have zero VUID/errors/warnings, skips or timeouts. Other host/build/cache settings are as below. The Khronos loader documents this isolation control; it does not establish a layer-related cause.

The distinct NVIDIA 4x stop is tracked in #8103. Its message is multisampled DCC target reuse requires watched guest memory (color range 0x2002b0000+0x100000, 4 samples). A separate test-only diagnostic locates that stop during refill resolve after the second draw, with an aligned host import spanning the resident source (trace and scope); this is not the AMD resolve mismatch. AMD still stops in the earlier fast-clear phase, so refill coverage on AMD remains unverified. The exact same fixture blob previously passed all nine NVIDIA processes at main1e774; that historical result remains scoped to its original pin, not a current all-NVIDIA-pass claim. No root cause, driver attribution, fix or game/performance result is established.

AI-assisted: yes (Codex).

Original observed result

On main 7b18fa8d5d7ca3cedbdb77a10042ace64ec9fd31, these existing tests fail on AMD Radeon(TM) Graphics and pass on NVIDIA GeForce RTX5080:

Test AMD, fresh processes NVIDIA, fresh processes
agc_driver_msaa_dcc_clear_2 3/3 fail 3/3 pass
agc_driver_msaa_dcc_clear_4 3/3 fail 3/3 pass
agc_driver_msaa_dcc_clear_8 3/3 fail 3/3 pass

Every run uses the requested physical GPU and loaded VK_LAYER_KHRONOS_validation;0 VUID/errors/warnings in all18 logs. Failure:

AGC graphics: multisampled DCC clear did not preserve undrawn samples, channels or scissor pixels

The assertion is in AlphaToCoverage.cpp:516–518, after the metadata resolve/readback. The test expects one sample's partial-channel/scissored draw to resolve against the imported initial clear, with undrawn pixels retained. The precise first mismatching pixel/value is not printed by the current test. Root cause is unconfirmed; no driver-versus-AnyPS5 attribution or proposed fix yet.

Reproduce

Build the runtime and existing fixture from this main:

cmake --build build --target libs relinker agc_driver_alpha_to_coverage_tests

PowerShell environment used (SDK location points to the installed validation layer):

$env:ANYPS5_GPU = 'AMD Radeon(TM) Graphics'
$env:ANYPS5_REQUIRE_VULKAN = '1'
$env:ANYPS5_NO_SHADER_CACHE = '1'
$env:APS5_NO_PIPELINE_JOURNAL = '1'
$env:VK_INSTANCE_LAYERS = 'VK_LAYER_KHRONOS_validation'
$env:VK_LAYER_PATH = 'C:\Users\Amoenus\Tools\VulkanSDK\1.4.363.0\Bin'
$env:VK_LOADER_DEBUG = 'error,warn,info,layer,driver'
ctest --test-dir build -V -j1 --timeout 30 --no-tests=error -R '^agc_driver_msaa_dcc_clear_(2|4|8)$'

I invoked each selected test in3 separate processes, serially. CTest exits8 on AMD; the fixture prints the assertion above. Substitute NVIDIA GeForce RTX 5080 for the comparison. All unrelated APS5_*, ANYPS5_* and VK_* variables were removed from each child environment.

Source/build and host

  • Test source and all production code are exact main7b18. Working head 6013d0ac7b1f12bd356652880d8148a8ab7c5c41 adds only an independent native-FMASK fixture and its CTest registration; neither AlphaToCoverage.cpp nor production is changed. The exact fixture-only control is on the fork.
  • At7b18: targeted full libraries/relinker/two-fixture build passed. Full default and runtime builds also passed at preceding main bcdee66d10, where the same AMD assertion failed3/3 per sample count. No full-default7b18 build claim.
  • Windows11 Enterprise26200, WinLibs GCC15.2.0r7/UCRT, Release, bundled SPIRV-Tools, Khronos SDK/layer1.4.363.0.
  • AMD Radeon(TM) Graphics,1002:13c0, driver32.0.21036.18.
  • NVIDIA GeForce RTX5080,10de:2c02, driver610.62 /32.0.16.1062.
  • Application shader cache and pipeline journal disabled; host driver caches and implicit host layers not isolated.

Controls and limits

On mainbcde, agc_driver_fmask_image_reads and agc_driver_sample_multisample_target pass3/3 on both GPUs. Graphics/shader-memory/request-serializer CPU groups also pass3/3 each. The new native-FMASK fixture reaches its expected unsupported-compression refusal3/3 on each GPU at both bcde and7b18, with0 VUID/errors/warnings; it is a separate test.

For the earlier bcde AMD failure, the documented APS5_NO_PIPELINE_LTO=1 control still gives the same assertion at2/4/8, one process each. With both APS5_NO_GPL=1 and APS5_NO_PIPELINE_LTO=1, all three controls instead stop at vkQueueSubmit recorder: Vulkan result -4; they do not reach the mismatch check. These are diagnostic controls, not a workaround/fix. The older LTO/cache report #2755 was reviewed; a common cause is not established.

Related context: initial DCC import #5939/#5336; resident DCC refill #7250. This report concerns a current existing-test result, not an assertion that either PR caused it. No game/performance or console comparison is claimed. Found while preparing the native-FMASK contribution; baseline failures will be compared explicitly with the candidate.

AI-assisted: yes, Codex.

Native-FMASK candidate cross-check — 2026-10-19

The independently focused native-owner FMASK candidate on main88a6 retains this baseline: AMD fails three fresh processes per 2x/4x/8x size at the same undrawn-samples/channels/scissor assertion, NVIDIA passes all nine matching processes. Both actual devices and the loaded Khronos layer were verified; zero VUID/errors/warnings. The new native-FMASK fixture separately passes three processes per GPU; it does not fix this DCC resolve assertion. No root cause or first failing pixel/value is established. Maintained qualification and scope. AI-assisted: yes (Codex).

Activity

  1. thuanquang commented on Oct 19, 2026

    @thuanquang
    thuanquang
    on Oct 19, 2026
    Contributor

    A discrete AMD data point: on main dbac9fa15 (which contains 7b18fa8d5), agc_driver_msaa_dcc_clear_2, _4 and _8 pass 3 of 3 each under ctest on an RX 6700 XT (gfx1031, RDNA 2), AMD's Windows driver 32.0.21045.5002, Windows 11 26200 (ANYPS5_REQUIRE_VULKAN=1, ANYPS5_NO_SHADER_CACHE=1, no validation layer). They also passed in my full suite on 54e4adde5.

    So the failure isn't on every AMD GPU under AMD's Windows driver. Which iGPU and driver version is yours? It could be the driver version or the iGPU's DCC path.

  2. simonbbby commented on Oct 19, 2026

    @simonbbby
    simonbbby
    on Oct 19, 2026
    Contributor

    Linux data point for the integrated device ID in the report: I cannot reproduce the mismatch on gfx1036 / 1002:13c0 with RADV, including on your exact reported main revision.

    Ubuntu 24.04, kernel 7.0.0-38-generic, Ryzen 9 9950X iGPU (RADV RAPHAEL_MENDOCINO, PCI 1002:13c0, revision c1), Mesa 25.2.8-0ubuntu0.24.04.2, GCC 13.3, Release. NVIDIA control: RTX 3090 (10de:2204), driver 595.99.02.

    Both the runtime dependencies and agc_driver_alpha_to_coverage_tests were rebuilt from each clean source tree. Three fresh processes per sample count and device, serially:

    Revision gfx1036 RADV, 2× / 4× / 8× RTX 3090, 2× / 4× / 8×
    reported main 7b18fa8d5d7ca3cedbdb77a10042ace64ec9fd31 3/3 pass each 3/3 pass each
    main snapshot 1e774a3b22da59e368f4de062c5d2c4e08409fe1 3/3 pass each 3/3 pass each

    All 36 physical-GPU processes exit 0 and print Multisampled DCC fast clear tests passed. In particular, the reported revision reaches the original sample/channel/scissor assertions successfully; this result does not depend on a later fix. The newer file adds DccRefillTests after the original DccFastClearTests; that selected mode also completes here.

    The command per process was:

    VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json \
ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1 \
APS5_NO_PIPELINE_JOURNAL=1 VK_LOADER_DEBUG=driver \
build/tests/agc_driver_alpha_to_coverage_tests --dcc-fast-clear 2

    Repeated with 4 and 8, then with the NVIDIA ICD. Other inherited APS5_*, ANYPS5_* and VK_* overrides were cleared. Loader logs confirm the actual RADV iGPU or RTX 3090 in every physical-GPU run; these are executed tests, not skips. The two installed RTX 3090s were not individually UUID-pinned.

    lavapipe is a limited control: 4× passes 3/3 on each revision, but 2× and 8× each return 77 with the device lacks the requested multisample color attachments. Those skips are not passes.

    No Khronos validation layer is installed on this host, so I make no VUID/validation-clean comparison. Host driver caches and implicit layers were not isolated. This provides a passing Linux/RADV result for the same PCI device ID, not a Windows-only diagnosis or a driver/hardware attribution; the hardware revision and feature/driver paths may differ. No title was run and no source was changed. Logs and both revision matrices retained.

  3. Amoenus
    changed the title [-]AGC: MSAA DCC-clear resolve checks fail on AMD Radeon iGPU at 2x/4x/8x; NVIDIA passes[/-] [+]AGC: MSAA DCC-clear resolve checks fail on AMD Radeon iGPU at 2x/4x/8x[/+] on Oct 19, 2026

  4. LeandroLP23 commented on Oct 21, 2026

    @LeandroLP23
    LeandroLP23
    on Oct 21, 2026
    Contributor

    A second AMD iGPU under AMD's Windows driver, and it doesn't reproduce here: Radeon 860M (RDNA 3.5, 1002:1114), driver 32.0.13058.8001, Windows 11 26300, WinLibs GCC 15.2.0, Release. main 1381826358, full rebuild, ANYPS5_REQUIRE_VULKAN=1, ANYPS5_NO_SHADER_CACHE=1, no validation layer, AMD driver cache not cleared:

    Test Result
    agc_driver_msaa_dcc_clear_2 3/3 pass
    agc_driver_msaa_dcc_clear_4 3/3 pass
    agc_driver_msaa_dcc_clear_8 3/3 pass
    agc_driver_alpha_to_coverage 3/3 pass

    With thuanquang's RX 6700 XT (32.0.21045) and simonbbby's RADV gfx1036 runs, the failure is now seen only on gfx1036 (1002:13c0) with driver 32.0.21036.18. Not on every AMD iGPU, not on AMD's Windows driver in general (this one is an older branch), and not on gfx1036 under RADV. A rerun on that gfx1036 with a current Adrenalin driver would tell a driver bug apart from something specific to the gfx1036 DCC path.

  5. CrimsonMac commented on Oct 23, 2026

    @CrimsonMac
    CrimsonMac
    on Oct 23, 2026
    Contributor

    The gfx1036 run on a newer AMD Windows driver that @LeandroLP23 asked for: it doesn't reproduce, on the reported revision or on current main.

    AMD Radeon(TM) Graphics, Ryzen 5 7600 iGPU (1002:164e, gfx1036), AMD Windows driver 32.0.21042.62 (newer than the failing 32.0.21036.18). Control: RTX 4070 SUPER (10de:2783, 32.0.16.2101). Windows 11 IoT Enterprise LTSC 2024 (26100), WinLibs GCC 15.2.0 r7, Release, ANYPS5_REQUIRE_VULKAN=1, no validation layer, driver caches not cleared. The adapter was selected with ANYPS5_GPU and confirmed in the log (Selected GPU name=AMD Radeon(TM) Graphics vendor=0x1002 device=0x164e).

    ctest -R '^agc_driver_msaa_dcc_clear_[248]$', three separate ctest runs per GPU:

    Revision gfx1036, 2x / 4x / 8x RTX 4070 SUPER, 2x / 4x / 8x
    reported e25333e39 3/3 pass each 3/3 pass each
    main a42f61d5b 3/3 pass each 3/3 pass each

    The original resolve assertion is reached and passes (Multisampled DCC fast clear tests passed). So the failure isn't specific to gfx1036's DCC path: the same graphics IP passes under RADV and under a newer AMD Windows driver. That leaves the 32.0.21036.18 driver branch or something specific to that machine. @Amoenus, a rerun on that 9950X3D iGPU with a current Adrenalin driver would show which.

    AI-assisted: yes (Claude Code).

  6. tablefrogpillow commented on Oct 24, 2026

    @tablefrogpillow
    tablefrogpillow
    on Oct 24, 2026
    Contributor

    Doesn't reproduce under RADV/Linux on any AMD arch, including the reported gfx1036 iGPU class.

    ctest -V -R '^agc_driver_msaa_dcc_clear_[248]$' with ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1 VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation, Mesa 25.2.8 / Linux, all on main 5d251e6:

    GPU 2x / 4x / 8x
    7800X3D iGPU (RADV RAPHAEL, 1002:164e, gfx1036, RDNA2) 3/3 pass each
    RX 7900 GRE (RADV NAVI31, 1002:744c, RDNA3) 3/3 pass each
    RX Vega 56 (RADV VEGA10, 1002:687f, GCN5) 3/3 pass each

    No multisampled DCC clear did not preserve ... resolve-assertion failures on any of them, including the same gfx1036 class that failed on the old Windows driver. With the newer AMD Windows driver (32.0.21042.62) also passing on gfx1036 (per the run above), this points to the old AMD Windows driver (32.0.21036.18) as the cause rather than AnyPS5 or the silicon -- the RADV stack is clean on the same gfx1036 hardware.

    AI-assisted: yes.

  7. Amoenus
    closed this as completedon Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions