[Crash] OOT: AMD Vulkan pipeline crash with standalone reproducer (RX 6700 XT)

Before submitting

I searched existing issues and found no duplicate
I'm using the latest build
My game is legally dumped from my own console

Emulator build

nx2-aed5a8c8-e736dfde9e

Regression

This is a regression (it worked in an older build)

Last known working build

No response

Game

Other / not listed

Graphics card

AMD RX 6000 series or older

Operating system

Windows 11

Steps to reproduce

Game: The Legend of Zelda: Ocarina of Time, title ID 0400486024DEC000.

Hardware: Radeon RX 6700 XT, Ryzen 7 5700G, Windows 11.

In Eglantine:

Launch the game using the Vulkan backend.
The menu and opening cutscenes appear normally.
During the Deku Tree dialogue, the screen goes black while the audio continues.
The emulator eventually closes by itself.

Standalone reproduction:

The attached package contains a separate Vulkan reproducer, instructions and captured shaders. It reproduces the crash without launching Eglantine or submitting drawing commands.

Using the same configuration and vertex shader, both control fragment shaders successfully create their pipelines. The candidate fragment shader causes an access violation during vkCreateGraphicsPipelines.

README_EN.md contains the commands for reproducing the candidate and control cases.

Log / crash dump

I would like to contribute diagnostic information about this crash.

I don't know how to code myself, but I understand the basic concepts. I used ChatGPT and Antigravity to help me gather and analyze the logs and dumps, and to generate a standalone reproduction program. I want to be transparent about this AI assistance.

The standalone reproducer triggers the same crash signature observed in Eglantine:

Exception: 0xC0000005.
Module and offset: amdvlk64.dll+0xAFF2E7.
Failed operation: reading address 0x28 with R15=0.
Instruction: mov r8, qword ptr [r15+28h].
AMD DLL file version: 32.0.21045.16010.

In reproducer v3.1:

Control 803: vkCreateGraphicsPipelines returns VK_SUCCESS; process exits normally.
Control 805: vkCreateGraphicsPipelines returns VK_SUCCESS; process exits normally.
Candidate 804: the process crashes during vkCreateGraphicsPipelines with the signature above.

The Khronos validation layer was active, with a persistent debug messenger whose message channel was checked. No Vulkan-specification violations were recorded before the crash.

The attached approximately 161 KB ZIP contains the reproducer source, Windows executable, captured shaders, instructions and diagnostic logs. The precise internal root cause has not yet been identified.

Related report: #589. This submission provides a standalone reproduction of the pipeline-creation crash; the relationship to the black-screen rendering problems remains unconfirmed.

Eglantine_AMD_reproducer_v3_1_reviewed.zip

Independent reproduction on a second AMD generation, which confirms this is in the driver and not in the emulator.

Machine: Windows 11, Radeon RX 5700 (RDNA1, navi10), AMD driver 32.0.21045.16010, using your Eglantine_AMD_reproducer_v3_1_reviewed package exactly as shipped.

VS_ASOCIADO + FS_CONTROL_803     vkCreateGraphicsPipelines retorno 0 (VK_SUCCESS), pipeline 000000c005d06020
VS_ASOCIADO + FS_CONTROL_805     vkCreateGraphicsPipelines retorno 0 (VK_SUCCESS), pipeline 000000c005117c60
VS_ASOCIADO + FS_CULPABLE_d6ac22ca   processo morre com Segmentation fault, exit 139, sem retorno da chamada

So RDNA1 behaves like your RDNA2: both controls create the pipeline, the candidate crashes inside vkCreateGraphicsPipelines before returning anything. Same shader pair, same driver branch, different GPU generation. That rules out a card specific problem and points squarely at the driver's pipeline compiler.

A few things this changes for the people working on the emulator side:

On Windows with amdvlk, this is a hard crash, so no emulator-side rendering fix can help while this shader form is emitted. The only paths are avoiding the form in the lowering or reporting it to AMD.
On Linux with RADV the same game renders after video_core, shader: fix Ocarina of Time's black 3D scene in gameplay #614, according to the report in [GBug] Ocarina of Time (0400486024DEC000): black screen after the intro, main scene draws skipped, compute rejected at op 4a4 and matrix multiply 23c #589, so the divergence is between the two AMD drivers rather than between AMD and NVIDIA.
Both controls being fine and only this one failing gives a clean bisect target. If it helps, I can try reducing the candidate shader further (strip the per-tap gather offsets, or force constants) and report which modification makes the crash go away, so the bug report to AMD has a minimal trigger.

For reference, the emulator side of this shows up as 0xC0000409 in amdvlk64.dll in our logs, while your standalone run shows 0xC0000005 reading 0x28 with R15=0. Different exception codes, same call and same DLL, which is consistent with two entry paths into the same broken compiler state.

Bisect progress on the RDNA1 machine, using your package as the test target.

What is excluded, each by editing the shader and re-running the reproducer:

capabilities          control and culprit declare the same set, control passes
descriptor count      control shader + one extra sampled image (39 -> 40 bindings) returns VK_SUCCESS
image samples         all 10 OpImageSampleImplicitLod replaced by OpUndef, still crashes
bitfield extract      75 OpBitFieldUExtract rewritten as OpShiftRightLogical + OpBitwiseAnd, still crashes
spirv-opt -O          optimized module still crashes

What actually changes the outcome

I ran spirv-reduce (Vulkan SDK 1.4.363.0) against your candidate with a test script that only asks whether vkCreateGraphicsPipelines still kills the process. After 2293 successful reduction steps the shader went from 6270 instructions and 103 KB to 1618 instructions and 34 KB, still crashing the driver. On that reduced shader:

original reduced module                         crashes
3 x OpGroupNonUniformBallot  -> OpUndef         does NOT crash
1 x OpGroupNonUniformShuffle -> OpUndef         does NOT crash
all 4 subgroup ops           -> OpUndef         does NOT crash

So in the reduced module the crash needs both the ballots and the shuffle. But here is the part that keeps me from calling it "subgroup ops are broken": your control shader 805 declares exactly the same subgroup usage (7 Ballot + 1 Shuffle) and does not crash. I checked the disassembly of both. So the opcode is not sufficient on its own, the crash depends on how the surrounding code feeds those operations.

Practical consequence for a report to AMD: sending the reduced 34 KB module is much better than the original, but a report that says "ballot plus shuffle crashes" would be wrong, because the same pair works in the control. The useful statement is "this specific module, of N instructions, crashes amdvlk 32.0.21045.16010 on RDNA1 and RDNA2, while a module with the same descriptor layout and the same subgroup operations does not".

I have a second reduction pass running to shrink the module further. When it settles I will attach it here plus the exact command lines, so anyone can reproduce it on their own machine in one shot.

The reduction finished, and the crash is now reproducible with a 363 instruction module.

Numbers

original candidate (FS_CULPABLE_d6ac22ca.spv)   6270 instructions   103 KB
after pass 1 (spirv-reduce)                     1618 instructions    34 KB
after pass 2 (spirv-reduce)                      363 instructions   8.2 KB   still crashes

How to reproduce it, from the package in this issue

set PATH=%PATH%;C:\VulkanSDK\<ver>\Bin
set REPRO=<package>\bin\reproduce_crash_v3_1.exe
set VS=<package>\shaders\VS_ASOCIADO_c47ca2c2.spv

%REPRO% %VS% <candidate>.spv          -> process dies inside vkCreateGraphicsPipelines

How the reduction was driven, for anyone who wants to go further: a one line script that returns 0 when the reproducer dies and 1 when the pipeline is created, handed to spirv-reduce as the interestingness test.

spirv-reduce candidate.spv -o reduced.spv -- teste.cmd

spirv-reduce stopped on its step limit both times, not because it ran out of opportunities, so another pass on the 8 KB module will likely shrink it further.

What the reduced module says about the trigger

Of the 363 remaining instructions, exactly one subgroup operation survives: OpGroupNonUniformShuffle %uint %uint_3 %1468 %1503, where %1468 = OpBitcast %uint of a loaded value and %1503 = OpIAdd of a loaded value and a constant. Replacing that single instruction with OpUndef makes the module create its pipeline successfully, every time.

The caveat I flagged before still holds and matters: control shader 805 has a structurally similar shuffle, OpGroupNonUniformShuffle %u32 %u32_3 %1457 %1492, and does not crash. So "shuffle crashes the driver" is not a correct statement. The honest statement is narrower: in this module, the shuffle is necessary for the crash, and something about how its operands are produced differs from the control.

What this is worth

For the driver vendor, this is now a small, deterministic test case with a binary and a documented command line, and it reproduces on both RDNA1 (RX 5700, driver 32.0.21045.16010) and RDNA2 (RX 6700 XT), with a control that passes. I can attach the 8 KB module and the 363 line disassembly to whoever needs them, and I can keep reducing if a smaller case is wanted before it is filed.

A third pass on the reduced module, for the record.

original            6270 instructions   103 KB
pass 1              1618 instructions    34 KB
pass 2               363 instructions   8.2 KB
pass 3               304 instructions   7.1 KB   still crashes, 1 OpGroupNonUniformShuffle

The reducer is plateauing: the third pass found only one more opportunity before the step limit, against 2293 in the first. So 7 KB with 304 instructions is close to the practical floor for the default pass set, and what remains is mostly constants and control flow rather than removable code.

Same property as before: replacing that single OpGroupNonUniformShuffle with OpUndef makes the module create its pipeline, so the shuffle is still the necessary ingredient, and the control shader with a similar shuffle still passes.

I can attach cand_r3.spv (7.1 KB) plus the 304 line disassembly to anyone filing this with the driver vendor, or keep going with a reduced pass set if a smaller case is preferred.

I dont know if this helps, but I get this same error too on my RX 9070XT machine, so RDNA4 behaves the same way. To be more precise, I can confirm up to point 3. During the Deku Tree dialogue, the screen goes black while the audio continues.

Adding a third hardware report to the reproductions here, because it now covers three AMD generations with the same isolated shader.

RDNA1   RX 5700     amdvlk 32.0.21045.16010   crash in vkCreateGraphicsPipelines (my run of your package)
RDNA2   RX 6700 XT  your report               same crash, same controls passing
RDNA4   RX 9070 XT  report above              same, and the black screen at the same point in the game

So this is not one card or one generation. The candidate shader from the package kills the pipeline compiler on RDNA1, 2 and 4, while both control shaders build their pipelines everywhere.

The reduced module I mentioned earlier is now at 304 instructions and 7.1 KB, still crashing, and the reproduction command is the same:

reproduce_crash_v3_1.exe shaders/VS_ASOCIADO_c47ca2c2.spv cand_r3.spv

One property worth knowing before anyone files this upstream: in the reduced module, replacing the single remaining OpGroupNonUniformShuffle with OpUndef makes the pipeline build, while your control shader 805 also contains a shuffle and does not crash. So the useful statement is "this module crashes on these drivers", not "shuffle crashes", and the minimal case is the thing to send.

If it helps, I can attach cand_r3.spv and its disassembly, and run the same reduction against a module captured on RDNA4 or RDNA2 to see whether the minimal trigger comes out the same on other generations.

@CloudP4bbs

@CloudP4bbs Thank you for testing the reproducer and continuing the investigation!

Could you please attach "cand_r3.spv", its disassembly, and the validation/reproduction commands you used?

I'd like to test your reduced module on my RX 6700 XT with our v3.1 reproducer and validation enabled, then check whether it produces the same crash signature as the original candidate.

It would also be helpful to have the modified version where the remaining shuffle is replaced with OpUndef, so we can compare both cases.

I'm still using AI assistance for the technical analysis, and I'll share the results here. Thanks again for your help!

All four files are here, plus the disassembly of each. I put them on a branch of my fork because a binary cannot be pasted into a comment.

file	instructions	size	what it is
cand_r3.spv	304	7,136 bytes	the reduced module that crashes
cand_r3.spvasm.txt	468 lines		its disassembly
cand_r3_noshuffle.spv	304	7,124 bytes	identical, except the one `OpGroupNonUniformShuffle` is `OpUndef`
cand_r3_noshuffle.spvasm.txt	468 lines		its disassembly
README.md			reduction history and what was ruled out

Reproduction command, exactly as I ran it against the v3.1 package:

reproduce_crash_v3_1.exe shaders/VS_ASOCIADO_c47ca2c2.spv cand_r3.spv

The first argument is the control module, the second is the one under test, matching the package usage. On this machine the process dies inside vkCreateGraphicsPipelines with 0xC0000409, fault reported in amdvlk64.dll (driver 32.0.21045.16010). Swapping cand_r3.spv for cand_r3_noshuffle.spv builds the pipeline and exits normally, which is the differential to look at.

Validation: I did not run with the validation layers on for this pass. If you enable them on the RX 6700 XT, the thing worth comparing is whether the message names a specific instruction or just reports the pipeline creation failing, because that distinguishes "the module is malformed in a way the driver tolerates until it does not" from "the module is valid and the compiler breaks on it".

Two details that matter for reproducing, since they cost me time:

cand_r3.spv is 304 instructions and 7,136 bytes, not the 34 KB intermediate. The file sizes above are exact, so a mismatch means the wrong file.
The two modules differ in exactly one instruction. If your run of cand_r3_noshuffle.spv also crashes, then the shuffle is not the ingredient and the differential is somewhere else in the module, which would be worth knowing before filing anything upstream.

If it helps, I can also produce variants that keep the shuffle but change its operands, to narrow what property of it matters. I did not do that yet because the control module on your side already has a similar shuffle and passes, so the useful next step is your run with validation on the RX 6700 XT rather than more reduction here.

@CloudP4bbs

@CloudP4bbs Thank you for sharing the files and for all the time you've put into reproducing and reducing this! I really appreciate your help.

I'll test both modules on my RX 6700 XT with validation enabled and compare the results and crash signatures. I'll share what we find here. Your work gives us a much smaller case to investigate!

logggg.xml
eden_log.txt

I can reproduce this crash on another AMD GPU.

System Configuration:
CPU: AMD Ryzen 7 5700X
GPU: AMD Radeon RX 6650 XT
RAM: 32 GB
OS: Windows 10 22H2
AMD driver DLL version: 32.0.21045.20006
Vulkan version: 1.4.315

Emulator:
Build: Eglantine Development Build
Build ID: daily-20261105-e736dfde9e-daily-20261105
Commit: e736dfd
Graphics API: Vulkan

Game:
The Legend of Zelda: Ocarina of Time
Title ID: 0400486024DEC000
Format: NUP

Steps to reproduce:

Launch the game using Vulkan.
The menu and opening scenes load.
When entering gameplay, the screen turns black.
Audio may continue, but eventually Eglantine crashes and closes.

Windows Event Viewer crash report:
Event ID: 1000 (Application Error)
Faulting application: eglantine.exe
Faulting module: amdvlk64.dll
AMD driver DLL version: 32.0.21045.20006
Exception code: 0xC0000005
Fault offset: 0x0000000000AFF2D7

This crash signature is very close to the one already reported in this issue: amdvlk64.dll + 0xAFF2E7.

My GPU is an RX 6650 XT (RDNA2), and the crash occurs with the same Eglantine commit.

I have attached my Eglantine log and Windows Event Viewer report.

Please let me know if any additional diagnostic information is needed.

@arsenartemovich25-lang

@arsenartemovich25-lang Thank you for sharing your logs! Would you be willing to try a small additional test on your RX 6650 XT?

What the test does

It is a small diagnostic program that asks the AMD driver to prepare three supplied shader samples. Two are comparison samples that worked on my PC, and the third triggered the crash.

It runs separately from Eglantine, so you do not need to launch the game or replay the introduction. It requires no installation or administrator permissions. The source code is included in src so you or an AI assistant can inspect it.

The test program may close unexpectedly on the third sample—that is one of the results we are checking.

Download

Here is the exact package attached to this issue:

[Download Eglantine_AMD_reproducer_v3_1_reviewed.zip](https://github.com/user-attachments/files/34418848/Eglantine_AMD_reproducer_v3_1_reviewed.zip)

How to run it on Windows

Extract the ZIP.
Open the extracted folder containing README_EN.md and the bin, shaders, and src folders.
Click File Explorer’s address bar, type powershell, and press Enter.
Copy and paste this entire block into that PowerShell window:

$repro = '.\bin\reproduce_crash_v3_1.exe'
$vs = '.\shaders\VS_ASOCIADO_c47ca2c2.spv'

New-Item -ItemType Directory -Force -Path '.\results' | Out-Null

& $repro $vs '.\shaders\FS_CONTROL_803_715d258d.spv' --log '.\results\control803.txt'
"Process exit code: $LASTEXITCODE" | Add-Content '.\results\control803.txt'

& $repro $vs '.\shaders\FS_CONTROL_805_bffbbb93.spv' --log '.\results\control805.txt'
"Process exit code: $LASTEXITCODE" | Add-Content '.\results\control805.txt'

& $repro $vs '.\shaders\FS_CULPABLE_d6ac22ca.spv' --log '.\results\candidate804.txt'
"Process exit code: $LASTEXITCODE" | Add-Content '.\results\candidate804.txt'

When it finishes, attach the three .txt files from the new results folder to a comment here. Please also mention whether you noticed anything unusual.

Those files should tell us whether both comparison samples return VK_SUCCESS and whether the original candidate crashes on your driver too.

Technical note for you or an AI assistant

Use the original shaders included in this ZIP. We are still checking the validity of the separately reduced cand_r3 modules.

The reproducer calls vkCreateGraphicsPipelines without submitting drawing commands. It prefers the RX 6700 XT’s device ID and otherwise selects the first enumerated GPU, so please verify that the output identifies your RX 6650 XT.

The commands above run without explicitly enabling validation layers. If Khronos Validation Layers are already installed, additional runs with --validate would be useful; please keep those logs separate.

Your reported DLL version is 32.0.21045.20006, with exception 0xC0000005 at +0xAFF2D7. Mine is 32.0.21045.16010, at +0xAFF2E7. If you already have debugger output, the exception record, faulting instruction, registers and call stack would help establish whether these are the same underlying failure. Full memory dumps are not needed in the public thread.

Thanks again for helping investigate this!

I completed the standalone Vulkan reproducer test on my AMD Radeon RX 6650 XT.

Results:

FS_CONTROL_803: Passed. vkCreateGraphicsPipelines returned VK_SUCCESS. Process exit code: 0.
FS_CONTROL_805: Passed. vkCreateGraphicsPipelines returned VK_SUCCESS. Process exit code: 0.
FS_CULPABLE: Crashed during vkCreateGraphicsPipelines. Process exit code: -1073741819 (0xC0000005).

The reproducer correctly detected my AMD Radeon RX 6650 XT (Device ID: 0x73EF).

Both control shaders work, while the candidate shader crashes the standalone reproducer.

This reproduces the crash outside Eglantine, without launching the game.

I have attached all three output logs.

I will also provide the Windows Event Viewer details for the reproducer crash.

candidate804.txt
control803.txt
control805.txt

@jonmakegames

Thanks for publishing the branch, @jonmakegames!

In the meantime, I also tried applying your fragment-shuffle fallback to my existing Eglantine PR #614 build (b536a97, including nx2 e736dfde9e). I rebuilt it locally with MSYS2 MinGW-w64 GCC 16.2 on Windows 11, using my RX 6750 XT and AMD driver 32.0.21045.16010.

eden_log.txt

I modified src/shader_recompiler/backend/spirv/emit_spirv_warp.cpp to route both absolute and relative fragment shuffles through the existing broadcast fallback, enabled with EDEN_NX2_FRAGMENT_SHUFFLE_FALLBACK=1.

This actually got me into gameplay! The graphics were still corrupted, but I could finally see the in-game HUD/UI and move around. Unfortunately, it eventually crashed again.

I'm also attaching the log from this hybrid Eglantine build (PR #614 + your shuffle fallback), in case it helps with further investigation.

The log records over 14,400 presented frames, but there are still quite a few errors: 36 texture format=0 assertions, 17 index <= tic_limit assertions, unmapped GPU memory reads and rejected native matrix-multiply compute operations. The latter still cause the upscaler to fall back to a plain copy. Interestingly, the log itself doesn't contain a clear crash signature, so I couldn't identify what caused the final crash.

I've now forked your amd-fragment-shuffle-fallback branch and started a Windows build through GitHub Actions. I'll test that build on the same RX 6750 XT and report back with the results.

@NicoCancedda

AMD coordination update: driver crash vs remaining rendering failures

I published an AMD-focused hardware/progress map in #589: who owns each card, what failed, what now works, and which work overlaps. Windows proprietary Vulkan and Linux RADV are separate sections; NVIDIA performance results are not counted as AMD validation.

For this thread specifically:

RX 6700 XT (mine), RX 5700 (CloudP4bbs), RX 6650 XT (arsenartemovich25-lang) and RX 6750 XT (NicoCancedda) provide independent standalone-candidate crash evidence. The RX 6650 XT uses a different DLL version/offset; those details remain in its row.
Our broadcast/select candidate builds, and Nico completed the alternative comparison. That is pipeline-creation evidence, not a rendered-frame test.
Jon's RX 6600 XT identifies the two fragment pipelines and has a published fallback. persluffy-cl's RX 6600 XT is a separate tester/machine and uses selected no-optimization in Lichii Fix/sw blit covered rows #210; it covers one common fragment hash plus two compute hashes, not automatically Jon's first bb5c case.
Nico's latest hybrid video_core, shader: fix Ocarina of Time's black 3D scene in gameplay #614 + fallback reaches HUD/movement, with corrupted graphics and a later unidentified crash. Thanks, @NicoCancedda, for doing both the controlled tests and the emulator test. The log does not establish that this later exit is the original AFF2E7 failure. Nico has already started building Jon's actual branch, so we can coordinate that existing effort rather than request duplicate builds.
Vmarcelo49's RX 9070 XT/RADV has a different depth-image typing failure with zero subgroup ops; keep its SPIR-V correction separate from the Windows shuffle investigation.

The next comparison is an identified Jon-branch build on additional AMD cards, recording driver crash, correct 3D output and sustained session as separate outcomes. Its base already includes Lichii #127 for the e405 demote/composite problem; another demote change should be compared against that existing fix.

The map invites corrections and links to work already underway. Completed control tests remain useful evidence; nobody needs to repeat them just to fill a table.

AI assistance: ChatGPT helped research and organize this update; Antigravity assisted our local experiments.

@jonmakegames

Connecting the AMD pipeline-crash participants

@jonmakegames @NicoCancedda @arsenartemovich25-lang @ne1i @resadent @Vmarcelo49

Here is the shared AMD hardware/progress map, including your reported GPU, results and remaining limits, with links so you can find one another's work.

For coordination:

Jon and Nico already have a fragment-fallback implementation/build effort underway.
The standalone controls/candidate tests are recorded; completed tests do not need repeating.
The RX 6650 XT's different DLL version/offset remains identified separately.
Vmarcelo49's RADV depth-image typing failure is a distinct case with no subgroup operations.
A black-screen report alone is not counted as a confirmed driver exception.

Please check your entry and link what you are currently investigating or the specific help you need. Replies about pipeline evidence can stay here; corrections to the overall hardware/status table can go under the linked map in #589.

The aim is to share work across AMD cards while keeping pipeline creation, correct 3D output and session stability as separate results. Thank you for all the independent testing and source changes.

AI assistance: ChatGPT helped organize and draft this coordination notice.

@NicoCancedda

@NicoCancedda Thank you again for the tests and the Windows build effort. One small package clarification for whenever you pick this up again — no rush.

I downloaded both Windows ZIPs from LichiiTest build-2, MSVC and PGO. Their SHA-256 hashes match the published assets, and both GUI/CLI pairs contain commit 5a50f50e0b7ea0cb0e71c4ae8e8e7425c8a3069c. I could not find EDEN_NX2_FRAGMENT_SHUFFLE_FALLBACK in either package. The matching source also retains the original shuffle path, so these appear to be the baseline nx2 packages.

In simple terms, I would like to make sure we download the experimental version you intend us to compare on the RX 6700 XT.

Were those ZIPs a baseline/CI check, or will the build containing Jon's fallback be shared separately? When available, the existing download link and exact commit are enough; no need to repeat any tests for this question.

For reference, the published candidate is Jon's commit c179a360, with the fragment-only absolute/relative fallback. Your local #614 + fallback run remains a separate result from these released ZIPs.

AI assistance: ChatGPT helped inspect the packages and draft this clarification.

@IORITHEGOD-create

@IORITHEGOD-create I completed the REV3 comparison tests on my AMD Radeon RX 6650 XT.

Both tests passed successfully:

FS_CONTROL_805_alt_broadcast: VK_SUCCESS, process exit code: 0.
FS_CULPABLE_alt_broadcast: VK_SUCCESS, process exit code: 0.

The reproducer correctly detected my RX 6650 XT (Device ID: 0x73EF).

For comparison, the original FS_CULPABLE shader crashed on my GPU with exit code -1073741819 (0xC0000005), while the alternative broadcast version successfully created the graphics pipeline.

I have attached both REV3 test logs.

I'm not a programmer, so unfortunately I can't suggest any technical solutions. However, I'd be happy to help with further testing if needed. Feel free to ask me to test anything on my RX 6650 XT.

Thank you for your work on this issue!

candidate804_alt.txt
control805_alt.txt
UPDATE: I downloaded and tested the latest version of Eglantine.

After the intro video, the game shows a black screen. The UI appears for a couple of seconds, and then the emulator crashes.

Unfortunately, I didn't save the Eglantine logs, but I have the Windows Event Viewer crash report.

Faulting module: amdvlk64.dll
Driver version: 32.0.21045.20006
Exception code: 0xC0000005
Fault offset: 0x0000000000AFF2D7

I'm using an AMD Radeon RX 6650 XT.

I'm not a programmer, but I'm happy to help with additional testing if needed.

Error 2.xml

@IORITHEGOD-create

@IORITHEGOD-create Here's the Windows build:

https://github.com/jonmakegames/Lichii/releases/tag/amd-shuffle-fallback-c179a360

Commit: c179a360364acd3e6e7ceea8c706118184aa7ee2, the same commit you checked. It's built from that commit alone, not from a local tree. The version string in the log reads amd-fragment-shuffle-fallback-c179a36036.
File: Lichii-amd-fragment-shuffle-fallback-c179a360-windows-x86_64.zip, a portable folder with Qt, plugins, vc_redist.x64.exe, LICENSE.txt and a README.
SHA-256: a462b19732ffac835bd0395f6ff9375841c4c373b1a40460151f2d047c74dd86. A .sha256 file is attached too.
Toolchain: MSVC 14.44, Release, Qt 6.8.3, with the same CMake options as the Windows CI job.

The fix is off by default. For your 0/1 comparison:

set EDEN_NX2_REJECT_HASH=eff3ccbe1438679d,f9ea14a22394f5b1
set EDEN_NX2_FRAGMENT_SHUFFLE_FALLBACK=1
set EDEN_NX2_CRASH_DUMP=C:\path\to\a\folder
start "" "%~dp0lichii.exe"

About the first REJECT_HASH line: on AMD proprietary, a first boot with no cached pipelines freezes at the intro movie for about 25 minutes. The driver compiles two compute shaders, eff3ccbe1438679d (~6 min) and f9ea14a22394f5b1 (~18 min); see zortos293/Lichii#200. It happens with or without the fallback, so you have two options:

A. Keep the line (recommended for this test). You reach Kokiri Forest in minutes. The intro, title and castle scenes lose their upper area. Those are compute shaders used only there, so they don't affect the fragment pipelines that crash.
B. Remove it. Wait once at the frozen intro. After that the driver has them cached and you get the full picture.

Please use the same option for both the 0 and 1 runs, so the fallback is the only difference.

With EDEN_NX2_CRASH_DUMP set, a driver crash writes lichii-crash-<pid>.txt. Its Driver build on this thread: line names the pipeline the crashing thread was building, so if the 0 run crashes, it should name bb5c27d79d59c88f or 3c2193d0166610b3 directly.

I tested this exact package with option A on my RX 6600 XT, driver 2.0.353. Both pipelines that used to crash built: 00e4eb4772d5076b+bb5c27d79d59c88f in 191 ms and 385df28c8d9acebf+3c2193d0166610b3 in 435 ms. All 917 graphics pipelines finished, the game got past the Deku guardian scene, there was no crash file, and the session closed normally.

@NicoCancedda This package should cover what @IORITHEGOD-create asked about the build-2 ZIPs, which have the baseline 5a50f50e0b and no fallback.

@arsenartemovich25-lang Your RX 6650 XT crash is at 0xAFF2D7 with driver 32.0.21045.20006, 0x10 bytes from the 0xAFF2E7 we see on .16010. It may be the same code in a slightly different driver build. If you try this package, EDEN_NX2_CRASH_DUMP would show whether it's the same pipelines.

AI assistance: Claude Code helped me build, package and verify this.

@IORITHEGOD-create

@IORITHEGOD-create thanks for checking the packages, and sorry for the confusion. Yes, the LichiiTest build-2 ZIPs were baseline builds: I forked the wrong branch, so they did not contain the fallback (baseline commit 5a50f50, as you found). They should not be used for the 0/1 comparison.

@jonmakegames thank you for the Windows package and the explanation of the first-boot compile. I am now testing amd-shuffle-fallback-c179a360 on my RX 6750 XT and will report the 0 and 1 runs with the same settings, plus the crash file if there is one.

@arsenartemovich25-lang Your RX 6650 XT crash is at 0xAFF2D7 with driver 32.0.21045.20006, 0x10 bytes from the 0xAFF2E7 we see on .16010. It may be the same code in a slightly different driver build. If you try this package, EDEN_NX2_CRASH_DUMP would show whether it's the same pipelines.

AI assistance: Claude Code helped me build, package and verify this.

Test results on my RX 6650 XT:

Test 0 — fallback disabled (EDEN_NX2_FRAGMENT_SHUFFLE_FALLBACK=0):

The game starts and renders the scene, but has visual/audio/video artifacts.
Eventually crashes with 0xc0000005 in amdvlk64.dll+0xaff2d7.
Crash dump identifies the pipeline:
s1:00e4eb4772d5076b
s5:bb5c27d79d59c88f

Test 1 — fallback enabled (EDEN_NX2_FRAGMENT_SHUFFLE_FALLBACK=1):

The game reaches gameplay.
I can control the character.
No crash so far.
Performance is extremely low, approximately 7 FPS.

This looks like the fallback successfully avoids the pipeline crash on my RX 6650 XT, but the performance impact is severe.

Hardware: RX 6650 XT
Driver: 32.0.21045.20006
Windows 10 22H2
t
lichii-crash-27400.txt

First, regarding my own Eglantine build: I took PR #614 (b536a97, based on nx2 e736dfd) and applied a local implementation of Jon's fragment-shuffle fallback. I modified src/shader_recompiler/backend/spirv/emit_spirv_warp.cpp, routing both absolute and relative fragment shuffles through the existing broadcast fallback, enabled with EDEN_NX2_FRAGMENT_SHUFFLE_FALLBACK=1.

I compiled it on Windows 11 using MSYS2 MinGW-w64 GCC 16.2. With this hybrid build, I managed to reach actual gameplay: the graphics were still heavily corrupted, but I could finally see the game's HUD/UI and move around. Unfortunately, it eventually crashed.

I've uploaded the portable Windows x64 build here:
https://github.com/NicoCancedda/EglantineHybrid/releases/tag/pr614-jon-shuffle-hybrid-test

The release now includes the ZIP, the complete modified emit_spirv_warp.cpp file and the corresponding patch against the original PR #614 commit.

Windows ZIP SHA-256:
d3c7fa982403e931db108b3aabe24ee58e31dc8caae498bae2ef34ad517993fe

Patch SHA-256:
0dc84e43dcb1e22df193fb6891197e75121eee7449c04598eae9e1db62ba68e3

I haven't had time to upload the complete Eglantine source tree or retrieve the exact CMake configuration command, but I can provide those details when I get back home. The modified source file and patch are already available in the release. The log from this hybrid build is also attached to my earlier comment.

Separately, I tested Jon's actual published Windows build from his experimental release:
https://github.com/jonmakegames/Lichii/releases/tag/amd-shuffle-fallback-c179a360

I downloaded the release corresponding to commit c179a360364acd3e6e7ceea8c706118184aa7ee2 and created a fix.bat using the launch instructions he provided.

This result was much better: on my RX 6750 XT, the game rendered almost normally, with only occasional white flashes on some textures. Performance was around 20 FPS at 1080p in Docked mode, but I was able to play for approximately 40 minutes without a crash.

Just to make the distinction clear: the corrupted graphics and eventual crash were from my hybrid Eglantine build. The approximately 40-minute stable gameplay session was from Jon's actual published Lichii build.

Here are the full logs and the SPIR-V I offered: one run without the fallback and one with it, on the same scene.

Attachment: eglantine-618-captures.zip. It has a MANIFEST.txt explaining each file.

Build and setup

Code: amd-fragment-shuffle-fallback now has one more diagnostic commit on top of c179a360: 816bb15e5. With EDEN_NX2_SPIRV_DUMP=<dir> and EDEN_NX2_SPIRV_DUMP_HASHES=<hash>,... it writes the listed graphics stages right after EmitSPIRV, before the driver sees them.
Version in the logs: they show 53d6dcf3c, my local copy of the same commit. The tree is identical.
Released package: unchanged. It's still c179a360, without this dump.
GPU: RX 6600 XT, driver 2.0.353 (amdvlk64.dll 32.0.21045.16010), Windows 11.
Both runs: shader cache cleared before run 1, and EDEN_NX2_REJECT_HASH=eff3ccbe1438679d,f9ea14a22394f5b1 set (intro compute shaders only), so the fallback is the only difference between the two runs.

Results

Run	`EDEN_NX2_FRAGMENT_SHUFFLE_FALLBACK`	Result
1	unset	Driver crash when Navi flies past the Deku guardian, at `amdvlk64.dll+0xaff2e7` with a null read at `0x28`. The crash filter names `s1:00e4eb4772d5076b s5:bb5c27d79d59c88f`.
2	`1`	Same scene. `bb5c27…` pair built in 251 ms, `3c2193…` pair in 146 ms. About 19 minutes of play, normal exit, no crash.

SPIR-V

Module	Without fallback (run 1)	With fallback (run 2)
`00e4eb4772d5076b` vertex	11,504 bytes	11,504 bytes, byte-identical
`bb5c27d79d59c88f` fragment	118,804 bytes	123,644 bytes
`385df28c8d9acebf` vertex	20,736 bytes	20,736 bytes, byte-identical
`3c2193d0166610b3` fragment	not captured	138,056 bytes

As expected, only the fragment modules change.

3c2193d0166610b3 has no original module because run 1 crashed on bb5c27… before that pipeline was emitted. If you need it, I can do a run with bb5c27d79d59c88f rejected so the driver reaches it.

The local paths in the logs are replaced by <src> and <work>.

AI assistance: Claude Code helped me build the dump, run the captures.

eglantine-618-captures.zip

@jonmakegames

@jonmakegames Thank you for packaging the exact commit, publishing its checksum and following through with the full logs and SPIR-V. I downloaded the release: the ZIP hash matches, and both executables identify c179a360 and contain the fallback/crash-filter variables. In your captures, I also checked that the vertex pairs are identical and the bb5c fragment replaces its one shuffle with the broadcast loop. We now have an identified package and concrete evidence for the RX 6700 XT comparison. We will keep the same intro-compute option in both runs and record its image limitation separately.

@NicoCancedda Thank you for the extra testing and for clearly separating the packages. Your explanation of the baseline build resolves our question, and distinguishing the corrupted/crashing hybrid from the approximately 40-minute session with Jon's actual build prevents us from blaming the wrong change. Publishing the hybrid patch/source also makes that result much easier to investigate later.

@arsenartemovich25-lang Thank you for completing the REV3 pair and the in-game 0/1 comparison. I checked both alternative logs and your crash file: it identifies the same VS 00e4eb4772d5076b + FS bb5c27d79d59c88f pair, with the offset from your different driver version. That gives us independent evidence on another card. The approximately 7 FPS result remains a performance question to track separately; it does not undo the value of identifying the crash.

I updated the AMD map with these deliveries and results. Our next step is the local RX 6700 XT test; we have not run it yet. We have enough material to start that step, so no additional capture or repeat test is needed for our outstanding requests.

AI assistance: ChatGPT helped inspect the delivered files, update the map and draft this reply; Antigravity assists our local experiments.

shader/spirv: avoid OpGroupNonUniformShuffle in fragment shaders on A…

vulkan: opt-in unoptimized graphics pipelines on AMD's proprietary dr…

vulkan: build four Ocarina fragment shaders unoptimized on old AMD dr…

shader: experiment switch for the shuffle fallback in fragment shaders

Navigation Menu

Repository navigation

[Crash] OOT: AMD Vulkan pipeline crash with standalone reproducer (RX 6700 XT) #618

Before submitting

Emulator build

Regression

Last known working build

Game

Graphics card

Operating system

Steps to reproduce

Log / crash dump

11 remaining items

AMD coordination update: driver crash vs remaining rendering failures

Connecting the AMD pipeline-crash participants

Build and setup

Results

SPIR-V

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Crash] OOT: AMD Vulkan pipeline crash with standalone reproducer (RX 6700 XT) #618

Description

Before submitting

Emulator build

Regression

Last known working build

Game

Graphics card

Operating system

Steps to reproduce

Log / crash dump

Activity

CloudP4bbs commented on Nov 5, 2026

CloudP4bbs commented on Nov 5, 2026

CloudP4bbs commented on Nov 5, 2026

CloudP4bbs commented on Nov 5, 2026

resadent commented on Nov 5, 2026

CloudP4bbs commented on Nov 5, 2026

IORITHEGOD-create commented on Nov 5, 2026

CloudP4bbs commented on Nov 5, 2026

IORITHEGOD-create commented on Nov 5, 2026

arsenartemovich25-lang commented on Nov 5, 2026

IORITHEGOD-create commented on Nov 5, 2026

arsenartemovich25-lang commented on Nov 5, 2026

11 remaining items

NicoCancedda commented on Nov 6, 2026

IORITHEGOD-create commented on Nov 6, 2026

AMD coordination update: driver crash vs remaining rendering failures

IORITHEGOD-create commented on Nov 6, 2026

Connecting the AMD pipeline-crash participants

IORITHEGOD-create commented on Nov 6, 2026

arsenartemovich25-lang commented on Nov 6, 2026

jonmakegames commented on Nov 6, 2026

NicoCancedda commented on Nov 6, 2026

arsenartemovich25-lang commented on Nov 6, 2026

NicoCancedda commented on Nov 6, 2026

jonmakegames commented on Nov 6, 2026

Build and setup

Results

SPIR-V

IORITHEGOD-create commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions