[DKB] v3.2.0 runs at 31 fps but drops 19 graphics programs (all stage 5) and 10 compute dispatches per session

This is the rendering side of the v3.2.0 container, split out from #350 as promised. The loader side there is closed: the wall was my old dump. This one is about what the emulator still drops while the title runs.

Session

container   [Game] Donkey Kong Bananza (v3.2.0 + DLC)[040074A01BF12000].nup, 9,285,682,019 bytes
machine     Windows 11, Xeon E5-2667 v4, RX 5700 8 GB, Vulkan, GPU accuracy Low
build       nx2 + my local build fixes
session     23,303 presents, 5.5 GB, no panic, no crash
frame time  31.6 to 33.4 ms (31 fps), steady
screen      intro renders with subtitles, then a blue/purple field

What gets dropped, counted over one session

 19  Native graphics shader rejected
 16  Native compute dispatch unsupported: method=0xb0, value=0x3
 16  Native QMD failed: native shader dispatch required
 14  Rejected program 0x... is bound to stage 5
 14  Unmapped Device ReadBlock

Every rejected graphics program is stage 5, and they cluster by header word:

header 000cd482   11 times
header 020d0481    5 times
header 000c5482    3 times
header 010d1081    1 time

A stage 5 program being bound at all is the part I find interesting, more than the rejection itself.

Diagnostics from the failing dispatch

I reran with EDEN_NATIVE_DRAW_DIAGNOSTICS=1, which dumps the first failing dispatch. The files are written to the working directory:

native-qmd.bin                       512 bytes   (128 u32 of the compute launch descriptor)
native-dispatch-mme.bin             49,152 bytes
native-dispatch-registers.bin       16,384 bytes
native-inline-compute-shader.bin    65,536 bytes
native-inline-compute-registers.bin 16,384 bytes
native-graphics-cbuf-1-1.bin        65,536 bytes
native-graphics-cbuf-5-1.bin        65,536 bytes

The QMD for the failing dispatch:

program address     0x00000021ec5f3000   (w48/w49)
w11                 0x04030000
w12..w14            1, 1, 1
w15                 0x210c3a4d
w44..w47            0x0080002160085000 twice
block dims          0x5f, 0, 0            (w4..w6)
grid dims           0, 0, 0               (w1..w3)

And the first words of the inline compute shader it cannot dispatch:

00047ab9 00c0a000 00000800 000fe200
00007919 00000000 00002500 000e2200

Two things I would flag there without pretending to understand them fully:

grid dims are zero while block dims are 0x5f. Either the grid is encoded elsewhere in this version or the dispatch really is degenerate, and the emulator would be right to refuse it. That is worth checking before anyone spends time on the macro.
The shader blob starts with 0x00047ab9, which does not look like the 0x59f FFMA family the graphics side was choking on, so the compute failure is likely a different gap.

What I am offering

I have all seven dumps saved. If it is useful I can attach them to a reply here (they are ~200 KB in total, well within an attachment) or describe a specific offset. Tell me which one you want parsed first and I will dump it as tables.

I would also like to know whether stage 5 is expected to be reachable at all in the current lowering, because if it is not, the honest fix is to reject it earlier with a clearer message rather than once per program per session.

Adding the visual evidence for what those counts look like on screen, because it changes what the bug is.

The emulator's own screenshot (Ctrl+P) during the intro shows only the subtitle, on a flat purple field:

visible     the subtitle "Far off the shores of DK Island..." and the UI layer
not visible no ocean, no terrain, no models, no sky, no lighting
presents    ~2,800 in that session, so frames are being submitted the whole time

So this is not a game that fails to start or a frame that never arrives. Frames are arriving, the UI and the text layer composite correctly, and the 3D scene is simply not drawn. The flat colour is the clear colour of the frame that the dropped passes were supposed to fill.

That fits the counts from the earlier session more tightly than anything else I had:

10  Native compute dispatch unsupported (method=0xb0, value=0x3) per session
10  Native QMD failed: native shader dispatch required
 4  Rejected program bound to stage 5

A title that renders its UI but not its world is what you get when the compute passes that set up the scene and the stage 5 programs that shade it are both dropped, while the 2D and text paths keep working.

I am not claiming that is the whole story, but it narrows the report usefully: the question to answer is no longer "why is the screen blue", it is "why is method=0xb0, value=0x3 refused", and the QMD I posted above is the input to that refusal.

One more diagnostic detail that may save someone an hour: the dumps are rewritten on every failing dispatch, so native-qmd.bin is often truncated to 0 bytes while you are looking at it. Copy the set out of the working directory at the first moment it appears, which is what I ended up doing.

Progress on this, with the exact reasons the world programs were being dropped on 040074A01BF12000 with the 3.2.0 dump (.nup, 5.1 GB resident, the game does present, only the clear colour and the subtitle layer reach the screen).

Eight graphics programs were rejected per session, and the reasons were:

6 x native indexed constant load mode   op b82, e.g. [op b82 ff139b82 03c00800 00000000 000e6200]
1 x native float-to-integer conversion mode   op 305 00157305 00000003 0021e100 0001e400
1 x Unsupported native graphics shader stage 4

The six b82 ones are LDC.IS with a size field of 0, which is U8. The Ampere lowering only accepted 4 and 5 (B32 and B64):

if ((width != 4 && width != 5) || (mode != 0 && mode != 2) || ...)

The Maxwell frontend LDC already implements all six sizes, so the narrow forms only needed to pass the check. That is what PR #306 by ymatrix1 does, and I applied that one line on top of nx2 here (keeping the .IS mode support that landed after that PR), then rebuilt.

With that, the six rejections are gone. The same shaders then went one step further and failed inside the SPIR-V backend:

Phi node type F32x4 is not implemented

TypeId in emit_spirv.cpp only knew U1 and U32, so any phi carrying a float or a vector threw and the pipeline was dropped again. The context already holds every scalar and vector id, so I extended the mapping to all of them. Second rebuild.

After both, the picture is:

Phi node type ...            0   (was 4)
native indexed constant ...  0   (was 6)
Undefined result in BitwiseAnd32(0, 4294967231, 0)   3
PackHalf2x16 is not a pseudo-instruction             1
Failed to read title for ROM!                        1  <- the boot ends here

So the b82 and the phi are cleared and there are two more shader-side errors behind them, then the boot stops on a title read failure that may or may not be related.

I am not posting this as a fix yet. Neither change is in a PR of mine, the second one has not been tested against other titles, and the boot does not complete. But the chain is now short and each step is a named error instead of a blank screen, so I think it is worth recording before someone else starts from the same place.

If anyone can test the two changes on their side I will open a PR with both, with the LDC part credited to #306.

Update: the title now reaches gameplay, and the missing part is narrower than before.

On a tree with #413 plus two local shader changes (LDC sizes from #306, and the phi mapping in #492), with the 3.2.0 dump:

shader rejections      0        (was 8: 6 x b82, 1 x F2I, 1 x stage 4)
Phi node type errors   0        (was 4)
RAM                    5.6 GB, stable
frames                 557 present at 225 s

And the screen is no longer an empty clear colour with a subtitle. It is in-game:

three hearts, a balloon counter at 0, a bag counter at 0
objective text "Explore the mining tunnel"
the "Punch" action prompt
a timer at 4.04

So the game logic, the HUD and the 2D layer all run. The 3D scene does not draw: the background is the clear colour, flat and uniform, with nothing in it.

That reclassifies this issue. It is not "the title does not boot". It is "gameplay runs and the geometry passes do not write colour". The remaining suspects are the graphics passes themselves, not the shader translation that was dropping pipelines, and the drop count is now zero.

For whoever picks this up, the useful next question is which passes those are: on this session the frame reaches the HUD but no world, which usually means the main scene pass is either skipped, or drawing into an attachment that is never composited.

I have no fix for that yet, and I am not going to guess one. I am posting the state so the next person starts from gameplay instead of from a lavender screen.

Correction to my previous comment, with the reason.

I said zero rejections. That was true at the menu and false once the world loads. Playing to the first level, the same session reports:

graphics shaders rejected            57
Draw skipped (no pipeline)           64
compute dispatch unsupported         52   (method=0xb0, value=0x3)
Unsupported native graphics stage 4   1

And the reason for almost all 57 is one instruction form that neither the current code nor PR #306 accepts:

op b82 ff099b82 03c00800 00000000 000e6200
  width = 1   (S8)
  mode  = 1   (bits 78-79)

The check today is:

if (width > 5 || (mode != 0 && mode != 2) || insn.Bits(91, 1) || bank() >= 18 || ...)

so width is fine after #306, but mode == 1 falls through and the program is dropped. The old version of this check only allowed mode 0, so mode 1 was never supported by either side. That explains the shape of the whole thing: the menu has no such shaders, the world has dozens.

So the concrete next step for this title is one more case in that condition, and then the 52 method=0xb0, value=0x3 compute dispatches, which are still refused and are likely the terrain.

I do not have a fix for mode 1 yet: I do not know what the field selects in that form, and the dist of mode = 2 (.IS, indexed segmented addressing) suggests 1 is a different addressing form rather than a variation of it. Recording it here so the next person starts from the field and the value instead of from a lavender screen.

Correction first, because my previous comment got the instruction wrong.

I decoded the rejected b82 words with the same Instruction::Bits(offset, count) the lowering uses (words[0..3], little endian), and the forms in my logs are:

[op b82 ff139b82 03c00800 00000000 000ee200]   width=0 (U8)   mode=0 (Default)  bit91=0  bank=0
[op b82 ff099b82 03c00800 00000000 000e6200]   width=0 (U8)   mode=0            bit91=0  bank=0
[op b82 ff007b82 01c03f80 00000400 000e2200]   width=2 (U16)  mode=0            bit91=0  bank=8

So the Bananza world programs are mode=0, not mode=1. What dropped them was the width gate (width != 4 && width != 5), which nx2 already widened to width > 5. My "width = 1, mode = 1" reading was wrong, and I have not seen a single mode=1 program in this title so far.

Measured today on nx2 8615d8d plus a local patch that accepts and lowers mode 1 (commit f43ea70800, two files, Maxwell Slot() treats IL like Default), built clean in a fresh build dir, MSVC 14.38, host Qt 6.8.3, exe md5 aea9d47bfc14c2f17c787c1ddcde647a:

Native graphics shader rejected       0     (was 57 per session, 8 before the world)
Native compute shader rejected        0
Unsupported native graphics stage     0
Draw skipped (no pipeline)           49     31 of them at 1920x1080
CB bind stage 3 / stage 4         17 / 17
Geometry shader passthrough           1     "used with no support"
presents                          15539     at t=508 s

The shader side is clean on this tree and the stages 3 and 4 are no longer refused. The world still does not arrive, and the failure moved to the load path: the process disappears at t=508 s, right after the first 1920x1080 passes start building pipelines. Working set goes 2476 MB at 495 s, 1231 MB at 510 s, then the process is gone, with the log ending on a complete line, no WER dump and no Application event, which looks like the guest tearing itself down rather than an access violation on the host.

The mode 1 patch is inert for this title as measured, so I am not sending it as a PR. If someone has a Bananza log that prints mode=1 in that message I would like the line, because only then it changes anything.

Measured the official CI build for this, not a local tree: build-202, 8615d8d53e, windows-x86_64-pgo zip, same 3.2.0 dump, RX 5700 on Windows 11, gpu_accuracy Low, 1x, BC3. Two things are different from my last comment here and the second one is the interesting one.

Shader side, native counts for the session that reaches the level load:

Native graphics shader rejected        0
Native compute shader rejected         0
Unsupported native graphics stage      0
Native compute dispatch unsupported    0
Draw skipped (no pipeline)            46   in 0.26 s, t=153.7 to 154.0
Graphics pipeline built (GPU thread)   30   5.8 to 16.2 ms each
presents                            4263

So the 57 b82 rejections are gone with no local patch at all. That confirms the correction I posted above: it was the width gate, and nx2 already widened it. There is nothing left for me to lower in this title on this build. The 46 skipped draws are the 1920x1080 passes waiting for their pipelines, not rejected programs.

Then the process dies at t=154.1 s with 0xC0000409, right at the end of that pipeline burst, and this time WER wrote a dump. The dump does not point at us:

ExceptionCode        0xC0000409
ExceptionInformation 0x2   (FAST_FAIL_STACK_COOKIE_CHECK_FAILURE)
ExceptionAddress     ...\DriverStore\FileRepositoryȂ642.inf_amd64_870f6b155aa057ce\B026261�mdvlk64.dll +0x2ECD41D
driver file version  9.2.10.353
crashing thread       stack is amdvlk64.dll and ntdll only, first 8 KB
                      (+0x834A27, +0x834441, +0x6052DC, +0x61F329, +0x5E2890)

This is the same exit code I saw twice before at t=357 s and t=508 s and could not attribute without a dump. It is a stack cookie check failing inside the Vulkan driver while it compiles the level's pipelines. I am not calling it a driver bug: we could be handing it something malformed and the driver is the one that notices. But it does mean the remaining wall in this title, on this machine, is not in the recompiler, and bisecting src/ for it will not find anything.

Two things I would want before opening a separate report: the same dump from someone on the proprietary/other ICD (if the offsets differ, it is the driver; if it moves into eglantine.exe, it is us), and whether clearing cache/shader/040074A01BF12000/vulkan.bin moves the death. I will do the second one next boot and post the number either way.

Second boot, this time with cache/shader/040074A01BF12000/vulkan.bin moved out so the level rebuilds its pipelines from scratch. Same outcome, same address:

vulkan.bin cleared     EXIT_CODE C0000409 at t=179.4 s
                       53 Draw skipped, 49 pipelines built, 0 rejections
                       WER dump eglantine.exe.5524.dmp
                       ExceptionInformation 0x2
                       faulting module amdvlk64.dll +0x2ECD41D
                       RIP 0x7FFB9ECAD41D, identical to the previous dump

So the pipeline cache is not involved and the driver fault is deterministic: two boots, different cache state, same instruction in amdvlk64.dll. Presents at death were 4263 and 5069, so both runs get through the menus and die in the same pipeline burst when the 1920x1080 passes start.

That rules out the cache as a variable. What I cannot answer from here is whether the emulator hands the driver something malformed, because I only have this one GPU. A dump from an NVIDIA or Intel machine that dies at the same point would settle whether the offsets move.

Tested the newest release on the same setup: build-204 (01dda0f47d, windows-x86_64-pgo), RX 5700 on Windows 11, gpu_accuracy Low, 1x, BC3, same 3.2.0 dump. Same signature as build-202, so the texture cache revert in 179b5afb50 does not change it.

build-204  01dda0f47d
Native graphics shader rejected      0
Native compute shader rejected       0
Draw skipped (no pipeline)          54     all in one burst, t=699.4 to 710.4
Graphics pipeline built             43     3.2 to 16.2 ms each
presents                         21966
WS                               2344 MB at the burst
EXIT_CODE                     C0000409    at t=710.0 s
ExceptionInformation                 0x2    (stack cookie check)
faulting module      amdvlk64.dll +0x2ECD41D   (file version 32.0.21045.1000)

Third build, third dump, same RVA 0x2ECD41D. One detail that may help whoever looks at this: the trigger is the level load burst, not uptime. This session sat at the title screen for nine minutes at 32 FPS, WS between 427 and 549 MB, with nothing rejected, and only died 11 seconds after the first 1920x1080 passes started, while 43 pipelines were being built and 54 draws were skipped in that window.

I cannot tell from outside whether the driver is choking on pipeline creation from the GPU thread. That is a guess, not a measurement. If anyone can run the same dump on a different GPU, the presence or absence of this RVA settles whether it belongs to the AMD driver or to our submission pattern.

Correction to the attribution in my 05:54Z comment, because it changes the shape of the bug.

I wrote that the death is triggered by the level load. The screen at that point is not the world. I fixed the OCR on the same machine and the frame reads "Hold both Joy-Con 2 controllers, then turn your dominant hand inward", which is the Joy-Con 2 mouse-mode tutorial. So what triggers the driver fault is the 1920x1080 pipeline burst that starts right after Continue, before the game reaches any 3D scene.

Same build-204, same env (TC 4200/4800, GEOMETRY=1, RESETFIX=1), shader cache cleared for the second run:

run                       pipelines  draws skipped  rejections  frame    fence blocked  result
build-204, 01:49 (cold)       43          54            0       31.3 ms      19 ms      C0000409 amdvlk64.dll+0x2ECD41D, 11 s after the burst
build-204, cold cache         28           7            0       31.3 ms      19 ms      no fault, 245 s at the tutorial
build-204, warm cache          7           7            0       31.4 ms      20 ms      no fault, 586 s at the tutorial

So the fault follows how many pipelines the driver compiles in that burst, not the game reaching the world. That is also why the warm cache run of the same binary sits on the tutorial for 586 s without a fault.

I also tried EDEN_NX2_FRAMES_AHEAD=0 on the theory in #506 (DKB runs a frame ahead and overwrites memory the GPU thread has not read). It changes nothing at this screen: the fence wait is 19 to 22 ms of a 31.3 ms frame in both arms, because the tutorial does not suspend the channels on a semaphore every frame. I will only post that comparison once I can get past the tutorial into the world.

AMD RX 5700, amdvlk 32.0.21045.1000, Windows 11.

build-205 is the first release with #506 in it (5cad158), so I ran the same Bananza 3.2.0 dump on it: Windows 11, RX 5700, gpu_accuracy Low, 1x, BC3, TC 4200/4800, GEOMETRY=1, RESETFIX=1, boot by argument on exefs/main, exe md5 fb84f5000da1e77b46171e15c4fbfb98, log line Eglantine Development Build | nx2-5cad158835-nx2.

The per-title frame wait shows up in the numbers. Across 41 stats windows, ran a frame ahead is 0 every single time, session total 23085 presents at 31.3 ms average (32 FPS), 0 frames over 100 ms in the last windows. So the DKB side of #506 does hold the present to the current frame.

What did not change is where the game gets to. The world still does not load, so the tensor emulation in the same PR never runs here:

Graphics pipeline built            7
Native graphics shader rejected    0
Native compute shader rejected     0
Draw skipped (no pipeline)         7
Native QMD failed                  0
tensor / HMMA lines in the log     0
WS                                 396 MB steady, 1913 MB peak at load
session                            735 s, no crash (I killed it)

Seven pipelines means the only thing drawing is the title and attract screen: 204k distinct colours, mean RGB 105/88/68, 1.4% of pixels at or below 16. The Joy-Con 2 mouse mode tutorial is still nearly black, mean RGB 11/12/17 with 73.8% of pixels at or below 16, against 60.3% pure black on build-204. No compute program is dispatched at that stage, so EmulatesNativeTensorPrograms() has nothing to act on and I cannot say from here whether the purple screen is fixed. Driving the tutorial with synthetic mouse movement changed the frame but never reached gameplay.

One caution on that 735 s: the amdvlk fault I reported at 0x2ECD41D came from the pipeline burst that follows Continue, 43 pipelines deep. This build never reached that burst, so the clean session is not evidence that the driver crash is gone.

Ran the newest release on the same Bananza 3.2.0 nup. build-206 is c54bc2289b, the same commit as build-205, so it is a CI rebuild and the numbers are the same:

boot to title            133 s, 245 presents, WS 394 MB
Enter (Normal Mode)      WS peak 1873 MB, 7 pipelines, back to about 400 MB
session                  601 presents at 31.3 ms (32 FPS), 0 frames over 100 ms
Graphics pipeline built  7
Native graphics rejected 0
Native compute rejected  0
Draw skipped             7
Native QMD failed        0
WS                       394 to 462 MB
screen                   mean RGB 11/12/16, 74.6% of pixels <= 16

Still the Joy-Con 2 mouse-mode tutorial, world not drawn.

Two harness details that cost me two boots tonight, in case someone else runs this dump:

Booting the loose dump (base/exefs/main) no longer reaches the title for this title id. Two runs died in the guest at t=61 s and t=7 s with Cannot execute instruction at unmapped address 0x0, after Unmapped Read64 @ 0x220 and Accessing an unallocated region of a SparseLargeVector at 0x8708040000, WS frozen at 202 MB and 0 presents. Booting the .nup container instead (AppLoader_NUP, 1 add-on package) reaches the title in 133 s.
With mouse_enabled=false in qt-config.ini the tutorial stays on its first page no matter which keys you send. With mouse_enabled=true plus real host mouse motion over the window, the pages advance and the Skip prompt appears. In one session I got four distinct tutorial texts: "Move the Joy-Con 2 over a flat surface like a computer mouse" and "Hold both Joy-Con 2 controllers, then turn your dominant hand inward", with WS peaking at 1769 MB and 8 pipelines as the scene enters.

I still have not passed that tutorial. X and Plus leave it back to the DK Artist attract screen, and Y, L, R, A do nothing there, so I do not know yet which button is Skip.

Related: #511 reports the AMD side from a machine that gets to a save load and crashes. Here on RX 5700 the world never starts, so the amdvlk fault I measured earlier in this issue (amdvlk64.dll+0x2ECD41D, during a 1920x1080 pipeline burst) happens in a stage this build reaches only on hardware where loading gets that far.

Testing build-206 (c54bc228) with the 3.2.0 dump. With #506 in, the purple screen is gone from my measurements, but the session now ends in a crash at about 78 seconds, and the log stops in the middle of the pipeline recovery path.

t=45 s   523 MB   75 presents
t=78 s   log stops
t=90 s   process gone, 142 presents

Last lines, repeated right before the exit:

HW.GPU <Warning> vk_rasterizer.cpp:357: Draw skipped (no pipeline)
Render.Vulkan <Info> vk_pipeline_cache.cpp:1260: ReportRuntimePipeline: Graphics ...
HW.GPU <Warning> vk_rasterizer.cpp:357: Draw skipped (no pipeline)

Nothing after that: no PANIC, no <Critical>, no shader rejection in the session (shader rejected = 0, stage 5 = 0). The process simply disappears while it is skipping draws for pipelines it could not create.

Two details that may matter to whoever wrote #506:

It reproduces with and without EDEN_NX2_EXPERIMENTAL_GEOMETRY=1 EDEN_NX2_RESETFIX=1, so it is not the experimental path being half-enabled.
The failure is a null pipeline, not a rejected shader. CurrentGraphicsPipelineSlowPath returns nullptr and the rasterizer reports Draw skipped (no pipeline) and returns. If the same key is queried again and something downstream assumes the pipeline exists, that is where a process vanishes without a WER-visible access violation in the log.

I am not posting this as a fix, because I have not found the dereference and I am not going to guess one after guessing wrong three times in this thread. But the state is: build-206 gets further than anything before it and dies in the pipeline-null path, which is a narrower thing to chase than a lavender screen.

One more correction, and this one moves the crash off the tutorial for good. It is the prologue 3D load, not the mouse tutorial and not the burst after Continue.

I remapped the keys from qt-config.ini before this run (host C is Switch A, host X is Switch B, host V is X, and so on, my earlier notes had them swapped), so I can actually drive the menus now. build-206, same Bananza 3.2.0 nup, RX 5700, gpu_accuracy Low, 1x, TC 4200/4800, RESETFIX=1, mouse_enabled=true:

boot to the load screen     138 s, 249 presents, WS 469 MB
screen                      "Adventure Hints / You can hit distant targets by throwing chunks
                            of terrain / O Next / Loading...", mean rgb 25/25/25, 74.5% <= 16
Enter                       swaps the hint text, nothing else
A (Switch A, host C)        advances the page, no visible change
26 graphics pipelines       t=170.5 to 171.8 s, 6.6 to 7.4 ms each, all 1920x1080 and 960x540
Draw skipped                45, same 1920x1080/960x540 burst
EXIT_CODE C0000409          t=175.9 s, 3.7 s after the key, 50 MB WER dump
faulting module             amdvlk64.dll 32.0.21045.1000 +0x2ECD41D
Native graphics rejected    0
presents at death           317

Same fault instruction as my three earlier boots. What changed is where it is reached from: the prologue load, before a single frame of the world is drawn.

I also had EDEN_NX2_EXPERIMENTAL_GEOMETRY=1 in every run tonight, so I flipped it as the one variable:

GEOMETRY=1    died at 175.9 s, 29 pipelines, WS ~470 MB, 45 draws skipped, needed a keypress to start the burst
GEOMETRY off  died at  84.0 s, 27 pipelines, WS 2598 MB peak, 46 draws skipped, no input at all

So the experimental geometry path is not the trigger, it only changes when the load runs: without it the game gets further into memory (2.6 GB resident, the deepest I have seen on this title) and hits the same instruction by itself.

Two consequences for whoever tests this next. First, the 40 minute sessions sitting at 7 pipelines that I reported earlier were sessions where nothing pressed A on the hint screen; the load was waiting for input, it was not stuck in the tutorial. Second, Native graphics rejected stays at 0 in both runs because no world frame survives: the b82 mode=1 counter cannot be measured on Windows/AMD until this driver fault is out of the way. Next I am going after the exact Vulkan call with the crash diagnostic layer, since the CI zip ships no pdb and I cannot symbolize eglantine frames from the dump.

Correction to my last comment, with better evidence collected overnight: the process does not die on a null pipeline, it dies inside the AMD driver, and it dies at the first 3D scene burst.

Five boots of build-206, RX 5700, Windows, Vulkan, 3.2.0 dump:

exit code        C0000409 (fast-fail / stack buffer overrun)
faulting module  amdvlk64.dll 32.0.21045.1000 +0x2ECD41D   (same offset in all five)
WER dump         50 MB written each time
right before     26 to 27 graphics pipelines created in one burst (1920x1080 and 960x540)
                 45 to 46 Draw skipped (no pipeline) in the same burst
shader rejected  0 in every session

With EDEN_NX2_EXPERIMENTAL_GEOMETRY=1 the session parks on the adventure-hint screen until input (someone presses A) and then dies on the following burst at t=175.9 s. Without it the load runs on its own and dies at t=84 s. Same module, same offset. So that variable changes when the title dies, not whether it does.

The sequence that matters is the burst: a couple of dozen pipelines get created in about 1.3 seconds, two dozen draws are skipped for having no pipeline, and then the driver takes the process down with a fast-fail. That is not a normal access violation the emulator could catch, it is the driver aborting.

What I would do next, and what I have not done because the CI zip ships without a PDB: enable the VkLayer_crash_diagnostic layer from the Vulkan SDK and rerun the same burst. It prints the last Vulkan call before the abort, which turns "somewhere in pipeline creation" into a specific structure with specific values. VkLayer_api_dump would give the full call sequence and the same answer more slowly.

I should also say plainly what earlier comments in this thread got wrong. I reported "Phi node type" and later "LDC mode 1" as the reason the world does not draw, and both were real code gaps, but neither is why this session ends: on these builds the shader rejections are zero and the process is still killed by the driver before a single world frame completes. The gap in the LDC lowering is still worth fixing for other builds, and #492 covers the phi, but they will not by themselves make this title playable on my hardware.

Follow-up with the API call pinned down. I ran build-206 with the api_dump layer (VK_LAYER_LUNARG_api_dump, text, detailed off) and the driver fast-fail dies inside vkCreateGraphicsPipelines, not in a draw or a present:

session                     319 s, 35 graphics pipelines, 206 presents, WS 5067 MB peak
vkCreateGraphicsPipelines   191 calls, all returned VK_SUCCESS except the last
vkCreateShaderModule        402 calls
vkCmdDrawIndexed            163895 calls, none after the last create
last line in the dump       "vkCreateGraphicsPipelines(...) returns VkResult" and nothing after it
crash                       C0000409, amdvlk64.dll 32.0.21045.1000 +0x2ECD41D

The layer flushes after every call, so an entry without a return value means the abort happened inside that call. Same instruction as every other boot tonight, now with the entry point named: it is pipeline creation for one of the 1920x1080 passes of the prologue load, not the command stream.

One caveat, the layer slows pipeline creation enough that the session lived longer (WS 5067 MB, 319 s) than without it (2598 MB, 84 s), so treat the resident numbers from this run as a different shape of the same load, not as an improvement.

vulkan: import the easy AMD fixes from the CheezerWheezer fork survey…

Navigation Menu

Repository navigation

[DKB] v3.2.0 runs at 31 fps but drops 19 graphics programs (all stage 5) and 10 compute dispatches per session #437

Session

What gets dropped, counted over one session

Diagnostics from the failing dispatch

What I am offering

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[DKB] v3.2.0 runs at 31 fps but drops 19 graphics programs (all stage 5) and 10 compute dispatches per session #437

Description

Session

What gets dropped, counted over one session

Diagnostics from the failing dispatch

What I am offering

Activity

CloudP4bbs commented on Nov 3, 2026

CloudP4bbs commented on Nov 3, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions