Dxvk: Hellblade: Senua's Sacrifice crashes without DXVK_SHADER_OPTIMIZE=1

[thegamingrestoration]

Hellblade: Senua's Sacrifice

The game can only be played using the (recently removed) SPIR-V shader optimization tool [DXVK_SHADER_OPTIMIZE=1]. Without it, and using the latest commit, the game crashes right after the first logo.

System information

• GPU: Nvidia Geforce GT 1030
• Driver: Nvidia proprietary driver 390.42
• Wine version: wine-vulkan-git r123139.4e181f459b-1 (Based on Wine 3.3)
• DXVK version: 1bfd37a

Apitrace file(s)

• HellbladeGame-Win64-Shipping.trace

Log files

• HellbladeGame-Win64-Shipping_d3d11.log
• HellbladeGame-Win64-Shipping_dxgi.log

[xpander69]

i can confirm that. can provide logs also if needed but seem to be pretty much the same as on the first post anyway.

[pchome]

@60fpshacks @xpander69
It would be good if you isolate "bad" shader(s) and attach it (them) to be analysed here or to #64

steps (example) :

• run game with DXVK_SHADER_DUMP_PATH=/tmp/hb-dump
• check /tmp/hb-dump for *.spv files after game crashed
• create /tmp/hb-read directory
• use spirv-opt --legalize-hlsl /tmp/hb-dump/<spv file name> -o /tmp/hb-read/<same spv file name> command (from SPIRV-Tools)
• run game with DXVK_SHADER_READ_PATH=/tmp/hb-read and check for changes

[thegamingrestoration]

Yes, I already tried validating the shaders but the results were the same.

Here's the original (untouched) shaders folder:
hb-dump.tar.gz

[doitsujin]

You can set DXVK_LOG_LEVEL=debug to figure out which shaders are being compiled right before the game crashes.

FYI, you're very fortunate that the game runs at all, there are a bunch of issues in DXVK that need to be fixed in order for this game to be playable on AMD hardware.

[roothorick]

If this is consistent with shader issues we've seen in the past, the crash may not happen until the pipeline is actually used, which means it will usually not be the last shader/pipeline logged.

Perhaps there should be logging added to trace that notes each pipeline transition?

[doitsujin]

@roothorick

Perhaps there should be logging added to trace that notes each pipeline transition?

This is actually exactly what DXVK has been doing for the past couple of weeks. The "compiling graphics pipeline" messages list all the shaders that are part of the pipeline right before callingvkCreateGraphicsPipelines, which crashes the driver.

[thegamingrestoration]

Ok, I can confirm that the game crashes after these three compute pipleines are compiled:

CS_40f374610c43ee3d068fa2b7d5111ea1dd067ccb
CS_238a5ce580cd482e0d253ce2da0f0212afb0073f
CS_b07abdecfaa160f91838a0a7f7ed04529f2caede

CS.tar.gz

(...)
warn:  DxgiPresenter: Unknown format: 24
warn:  DxgiPresenter: Unknown format: 24
warn:  DxgiPresenter: Unknown format: 24
debug: Compiling shader VS_d9393f980842f55916b24ba81ce1df4b83015754
debug: Compiling shader VS_d2f850ced7bf140a3c3c7029a2adf270dc7a1363
warn:  DxbcCompiler: Unhandled VS SV output: DxbcSystemValue::ClipDistance
debug: Compiling shader PS_b0eafa93cec7d517ac50e95f362c6f48c1bfadd4
debug: Compiling shader VS_3f143100d255aeeb20b05913f59e5637e2d2a853
warn:  DxbcCompiler: Unhandled VS SV output: DxbcSystemValue::ClipDistance
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE5
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE4
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE6
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE7
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE14
debug: Compiling shader CS_40f374610c43ee3d068fa2b7d5111ea1dd067ccb
debug: Compiling shader CS_238a5ce580cd482e0d253ce2da0f0212afb0073f
err:   D3D11: ClearUnorderedAccessViewUint: Not supported for typed buffers
debug: Compiling shader CS_b07abdecfaa160f91838a0a7f7ed04529f2caede
debug: Compiling shader CS_72d8b9a0e3165ff54bc51ec6342803f31fbf1370
debug: Compiling shader PS_c52eb3062310bc82016c7f8bd2e7bb42dff35b70
debug: Compiling shader VS_5d419c7d952b40e290f6489309bf2598d74e87ee
warn:  DxbcCompiler: Unhandled VS SV output: DxbcSystemValue::ClipDistance
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE5
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE4
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE6
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE7
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE15
debug: D3D11Device: No such vertex shader semantic: ATTRIBUTE14
debug: Compiling compute pipeline...
debug:   cs  : CS_40f374610c43ee3d068fa2b7d5111ea1dd067ccb
debug: Compiling compute pipeline...
debug:   cs  : CS_238a5ce580cd482e0d253ce2da0f0212afb0073f
debug: Compiling compute pipeline...
debug:   cs  : CS_b07abdecfaa160f91838a0a7f7ed04529f2caede
wine: Unhandled page fault on read access to 0x00000000 at address 0x7f3ad9cda846 (thread 004c), starting debugger...
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00007f3ad9cda846).
Register dump:
 rip:00007f3ad9cda846 rsp:000000000a2dd9f0 rbp:00007f3acd381898 eflags:00010206 (  R- --  I   - -P- )
 rax:00007f3acd443160 rbx:000000000a2dda28 rcx:00007f3acd443160 rdx:0000000000000000
 rsi:0000000000000013 rdi:00007f3acd3000b0  r8:0000000000000000  r9:00007f3acd3615a8 r10:0000000000000003
 r11:00007f3aeb01c1a0 r12:00007f3acd223870 r13:000000000a2dda20 r14:000000000a2de0a0 r15:00007f3adb6fbbe0
Stack dump:
(...)

[pingubot]

@60fpshacks, can you also upload the corresponding .spv files please ?

[thegamingrestoration]

@pingubot I already did, the three corresponding files are attached at the top of the log. And if you need the rest of them, they're on my second post.

[pingubot]

@60fpshacks maybe i am blind, but i only see the dxbc shaders in the cs.tar.gz and not the .spv files ?

[thegamingrestoration]

@pingubot Oh you're right, so sorry :/
Here you are: spv.tar.gz

[pingubot]

I also can confirm the issue here using the api trace with my gtx 970 and driver 390.42 . The game crashes during loading in the driver : wine_vkCreateComputePipelines seems to trigger it. The full trace is attached.

@60fpshacks :Using the spir optimizer 2 times (you have to do it multiple times, cause after fixing the first shaders with the optimizer, some shaders later on may cause the same issue), i am able to completely replay the apitrace without issues.

@pdaniell-nv: It would be fantastic if you could take a look at the 3 shaders in that package, they seem to crash the nvidia driver, maybe we are hitting another shader compiler issue here. Many thanks.

Here is the link: Broken Shaders

Backtrace: hellblade-backtrace.txt

[thegamingrestoration]

@pingubot Thank you for the information, I used the optimizer twice as you said and the game no longer crashes, in fact it lets you go ingame.
I'll try to finish the game but for now it looks perfectly playable. Hopefully those three shaders are the only issue to take care of.

[doitsujin]

@60fpshacks they aren't, as I mentioned in my first comment. It doesn't work on AMD at all and it might break on Nvidia any time due to some major bugs in DXVK. Won't fix them though because it's pretty much impossible to find out what is actually wrong.

[pingubot]

@60fpshacks , in addition to the 3 shaders other shaders also crash the driver, otherwise no second optimizing run would have been necessary. As soon as we have info from the nvidia engineer and a fix might be in place, i wil try to figure out which shaders still fail then.

[thegamingrestoration]

Hmm I understand.
I have other games with similar issues with the shaders (if it's of any help for later), but I'll wait until those major bugs are fixed.
Thank you.

[pingubot]

@60fpshacks : It would be VERY interesting to know the games and which shaders fail. There is a nvidia employee who helps to take a look at shaders which crash the nvidia drivers. @doitsujin was able to fix some code in Dxvk and also created a bunch of workarounds for issues in the nvidia driver.

The more broken shader files we have, the better it is cause it will make a) the driver and b) dxvk better for all of us nvidia users

[pingubot]

@60fpshacks : Please attach your informations to #64

[thegamingrestoration]

@pingubot Oh I see! I misunderstood. Ok, I'll try to post some info in #64

[pingubot]

@60fpshacks , thank you very much, as already mentioned, the more examples of shaders which break the nvidia driver we have, the better it is.

[zolfone]

@60fpshacks How did you get this game to run? All I get is this message:
"DX11 feature level 10.0 is required to run the engine"
if I run it without the native DLLs it runs (awfully) normally, maybe I'm missing some basic step/configuration...

[thegamingrestoration]

@zolfone Try using Staging instead of the vanilla version of Wine (Wine Staging 3.4).

[zolfone]

@60fpshacks I wasn't not using vanilla nor staging, I was on wine-vulkan as the README was telling me to do a few days ago... I just saw that doitsujin changed that to wine-3.4, I'll give it a try today, also I missed the (showstopper maybe?) information about Kepler cards not exposing feature level 11_0, so maybe it's a no-go for me at this point.

[thegamingrestoration]

Try using Staging instead of the vanilla version of Wine (Wine Staging 3.4).

@zolfone I said this because the game was working perfectly using wine-vulkan, and as soon as I upgraded to Wine 3.4 it gave me that same error message.
But if you have a Kepler GPU then it's a different story #127

[zolfone]

@60fpshacks Thanks I'll give it a try and report if it works (with or without that workaround in #127)

[pdaniell-nv]

@pingubot Sorry my reply to your question about https://github.com/doitsujin/dxvk/files/1821041/spv.tar.gz isn't very timely. I have been on vacation. Of the three shaders, the first two compile without crash for me and CS_b07abdecfaa160f91838a0a7f7ed04529f2caede suffers from the OpAtomicIAdd issue discussed in https://github.com/doitsujin/dxvk/issues/64.

[pingubot]

@pdaniell-nv : No problem at all, glad to have you here being super helpful all the time. Even with the fix in fcff10a, the replay still crashes for me in the nvidia driver,so there seems to be another issue in the cs shaders.

@60fpshacks : can you try on your side and find out which shaders are still broken for you ?

[pingubot]

@pdaniell-nv : I did some troubleshooting and the driver is failing in the attached shader if it is not optimized. Attached find the file including the broken shader, the optimized one and the correspondig .dxbc. This was done with a dxvk build which has a workaround from @doitsujin in place for the OpAtomicIAdd issue. So it might be an addiotional issue or the fix fcff10a of @doitsujin does not work for that shader. Would be great if you could take a look.

shaders.tar.gz

[pingubot]

@pdaniell-nv : As request by @doitsujin , attached find the same shader with a dxvk build from Saturday, 24.03.2018.
shaders.tar.gz

[pdaniell-nv]

@pingubot This failure is again because of OpAtomicIAdd. It's not yet clear to me if we have a problem with this even with valid SPIR-V. I'm trying to get an answer internally.

[pingubot]

@pdaniell-nv , thank you very much, looking forward to the analysis result.

[doitsujin]

@pdaniell-nv the shader in question uses unsigned integers for atomic operations when the resource has a signed integer format, this is a bug on my end. Could this cause the issue?

[pdaniell-nv]

@doitsujin I don't think that would cause the issue and I think that's valid SPIR-V. We definitely have an issue with our OpAtomic ops with buffer images and we have a compiler guy digging into it.

[pdaniell-nv]

@doitsujin Our compiler guy looked at CS_b07abdecfaa160f91838a0a7f7ed04529f2caede.spv and thought the SPIR-V was actually not valid.

%28 = OpTypeImage %int Buffer 0 0 0 2 R32i
%_ptr_UniformConstant_28 = OpTypePointer UniformConstant %28
%u0 = OpVariable %_ptr_UniformConstant_28 UniformConstant

%1374 = OpImageTexelPointer %_ptr_Image_uint %u0 %1371 %uint_0_24
%1380 = OpAtomicIAdd %uint %1374 %uint_2_5 %uint_72 %1377

Notice how the type of %28 is %int but the result type used with OpAtomicIAdd is %uint. If they matched it would have worked okay for us.

From https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpImageTexelPointer it says:

"The Sampled Type of the type of Image must be the same as the Type pointed to by Result Type"

If %28 is modified to be %uint it should work.

[doitsujin]

@pdaniell-nv that's bascially what I meant by using the wrong integer type. Thanks for the info.

@60fpshacks please test if it works with 47e78d0a9553d7608f912eff2a583af5b7bef2de.

[thegamingrestoration]

Sorry for the late reply, I've been a bit busy these weeks.

@doitsujin fcff10a fixed Echo (#64) and 47e78d0 fixed Hellblade. Now they both go ingame without issues.

[libcg]

Can you close this issue if that's fixed?