Wanted to also add here, this game used to work fine with Mesa (TGL and DG2). Latest update to the game (or changes in proton?) seems to have started this issue to happen.

For the SPIR-V, you have to enable --scalar-block-layout to validation.

Thanks, I verified and no validation errors with this with the shaders I collected.

That is the latest version what Ubuntu LTS has, does Steam/Proton come with a wine version of its own?

If you use proton then it won't use your system's wine at all. So I guess this is just running on proton experimental.

If you use proton then it won't use your system's wine at all.

Ah right ok .. sorry, wine version should not then really matter here (I just filled because it was part of template). Most games that I've tested also seem to work fine, it's just something special going on with Cyberpunk.

Wine version definitely matters. It decides which Vulkan extensions are usable by Windows applications.

But it's not running on wine-6.0.3~repack-1, but rather what comes with proton experimental-7.0-20230330, so should be new enough.

The game failing to start seems to be unrelated to the watchdog timer. If I stub out some of the complex compute shaders, then compilation speed is no longer an issue, and the watchdog doesn't trigger...but the game fails to start in the same way.

Changing vendorID in VkPhysicalDeviceProperties from 0x8086 to 0x9999 and using Mesa MR !21645 to speed up shader compilation gets the game running. My current...guess...is that something with XeSS/XeFX is going wrong, and Cyberpunk is using that if vendor is Intel, even if XeSS isn't enabled. It's just a guess, though.

I think looking at XeSS makes sense, i suspect it's causing issues with some UE4 titles on intel as well: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8094 and also it has been reported that the XeSS demo application crashes on anv with vkd3d-proton: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7075#note_1631824

Looks like XeFX is calling CM_Get_Device_ID_List_SizeW, CM_Get_Device_ID_ListW, and CM_Locate_DevNodeW which are stubbed. From the PROTON_LOG=1 steam-1091500.log:

1910.504:0134:0138:fixme:setupapi:CM_Get_Device_ID_List_SizeW 0000000000219DF0 L"{4D36E968-E325-11CE-BFC1-08002BE10318}" 0x00000200: stub
1910.504:0134:0138:fixme:setupapi:CM_Get_Device_ID_ListW L"{4D36E968-E325-11CE-BFC1-08002BE10318}" 0000000003E84640 0 0x00000200: stub
1910.504:0134:0138:fixme:setupapi:CM_Locate_DevNodeW 0000000000219DF4 L"\6573\4674\6165\7574\6572\6e45\6261\656cd" 0x00000000: stub

Quite possible that XeFX takes a different path if the vendor id is Intel, but the demo app and the implementation in multiple games work fine on radv and nvidia on proton.

17 May 2023, 01:29 by @.***:

Looks like XeFX is calling > CM_Get_Device_ID_List_SizeW> , > CM_Get_Device_ID_ListW> , and > CM_Locate_DevNodeW> which are stubbed. From the PROTON_LOG=1 steam-1091500.log:

1910.504:0134:0138:fixme:setupapi:CM_Get_Device_ID_List_SizeW 0000000000219DF0 L"{4D36E968-E325-11CE-BFC1-08002BE10318}" 0x00000200: stub1910.504:0134:0138:fixme:setupapi:CM_Get_Device_ID_ListW L"{4D36E968-E325-11CE-BFC1-08002BE10318}" 0000000003E84640 0 0x00000200: stub1910.504:0134:0138:fixme:setupapi:CM_Locate_DevNodeW 0000000000219DF4 L"\6573\4674\6165\7574\6572\6e45\6261\656cd" 0x00000000: stub

—
Reply to this email directly, > view it on GitHub https://github.com/HansKristian-Work/vkd3d-proton/issues/1519#issuecomment-1550484108> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/A3G6J6LN7IT4F6RNXKLCT5TXGQEV5ANCNFSM6AAAAAAXCIB6EY> .
You are receiving this because you commented.> Message ID: > <HansKristian-Work/vkd3d-proton/issues/1519/1550484108> @> github> .> com>

@tpalli Could you try this again with a updated mesa main? If it's the XeSS crash then that should have been worked around now for this game.

Yes it launches now. I will close this.