This looks like exactly the same issue as #1623, no? It just crashes compiling some shader (due to invalid spirv generated by vkd3d-proton's dxbc compiler), which has also already been dumped: https://github.com/HansKristian-Work/vkd3d-proton/issues/1623#issuecomment-2329654192
It just crashes compiling some shader (due to invalid spirv generated by vkd3d-proton's dxbc compiler), which has also already been dumped: [#1623 (comment)](https://github.com/HansKristian-Work/vkd3d-proton/issues/1623#issuecomment-2329654192)
Probably. I remember SPIR-V errors on the same stage, but they disappeared since 2025, now the only message I see is an assertion hit.
Though, the question, why it works on Honeykrisp then but not on AMD (even with amdvlk). I tried spoofing the GPU and it still crashes at same place.
The assertion is just telling you that it crashed inside vkCreateGraphicsPipelines, most likely due to the invalid spirv passed to the driver. Something in wine/winevulkan changed at some point, so it now gives you this assertion message instead of just crashing or hanging silently, but that doesn't change anything about the root cause.
Though, the question, why it works on Honeykrisp then but not on AMD (even with amdvlk). I tried spoofing the GPU and it still crashes at same place.
Maybe it for some reason or another doesn't crash on the invalid spirv, doesn't really matter though. If there is invalid spirv generated by vkd3d-proton, the problem is already found.
but that doesn't change anything about the root cause
Seems like old Wine versions just ignored broken calls, at least on 7.22-staging the game loads.
the problem is already found
I did some more testing (incl. building latest mesa-git as I haven't updated for a while) and got 100% same issue as #1623 (hang instead of assert), so yes, RDR2 breaks DXBC compiler.
Using dxilconv instead of built-in compiler fixes everything (even #1506):
I'll still leave the issue open as the DXBC bug isn't fixed (hopefully yet).
New dxbc_spirv compiler resolves this issue - thus tessellation pipelines compile and work now as well. The snow renderer uses TS stage here
Sounds like legacy compiler has issues with handling DXBC tessellation modules, lol.
@whitebelyash nice.. how to test the new spirv compiler on vkd3d? Vía env variable or some config file..
@whitebelyash nice.. how to test the new spirv compiler on vkd3d? Vía env variable or some config file..
VKD3D_CONFIG=dxbc_spirv
Hey, I am having this same issue, how do I fix it? Where do I get dxbc_spirv from?
Just use a recent version of vkd3d-Proton. It has already been integrated and enabled for RDR2.
ge-proton10-4x1 2025-06VKD3D_CONFIG=dxbc_spirv`x1 2025-08
Software information
Red Dead Redemption 2 with DX12 renderer/API
System information
Log files
No debug - wine.log
vkd3d trace - wine_debug.log
(using wine-10.8-staging here)
Description
Setting RDR2 renderer API to DX12 crashes the game on pipeline cache warmup screen (grey progress bar screen before the R* logo) with vkCreateGraphicsPipelines assertion hit:
This occurs both on vanilla wine-staging and GE-Proton 10-4. Using AMDVLK makes no difference. Upstream vkd3d boots the game (used by CodeWeavers to run RDR2 on macOS).
Manually removing assertions from loader_thunks.c allows the game to load up to the gameplay without graphical artifacts even though it can eventually crash with another assertion:
(at least on GE-Proton10-4). Skipped assertions are probably the cause, because sometimes rendering breaks before hitting assert:
The interesting thing - if pipeline cache is already present (sga_win32_* files in the game settings dir) then RDR2 boots to the menu, but eventually crashes right before rendering the first frame with the same assertion hit (vkCreateGraphicsPipelines). Switching GPUs doesn't affect anything even though the game rebuilds warmup cache (judging by CPU load).
This issue isn't present on Honeykrisp driver (tested on Apple M1)
GTA V Enhanced also uses same renderer (SGA with DX12 driver) and works out-of-the-box since the release day.
Although RDR2 uses a fully-working Vulkan renderer by default, it has a memory leak on RDNA2+ hardware with ReBAR enabled. Using DX12 can workaround this issue if disabling ReBAR/SAM isn't an option.
FSR4 also requires DX12 renderer by obvious reasons.
This is probably different to https://github.com/HansKristian-Work/vkd3d-proton/issues/1623 (the game now simply crashes with assert hit)I got same problems (including hang) after more testing just as in #1623.Using dxilconv instead of builtin DXBC compiler fixes this issue and #1506 as well.