It's a radv issue afaik. I don't think Nvidia users have the same problem. Tho i could remember wrong.
It also hangs with Mesa 23.1.0, but without such verbose errors in dmesg. I only see this:
[ 181.182871] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, but soft recovered
Kernel 6.3.3.
I tried to test it with latest amdvlk (v-2023.Q2.2) and interestingly, enabling ray tracing in the game also cases a GPU hang. So I wonder if it's a kernel or vkd3d-proton problem after all. Or may be it's defective hardware (i.e. specific to ray tracing accelerator)?
Amdvlk hangs the GPU even with the rt tests in the vkd3d-proton testsuite, I wouldn't read too much into it. I think defective hardware is extremely unlikely to cause hangs just in rt workloads.
Good to know, thanks. Then I suppose it's still something in radv.
When this hangs happens (and it still does), I also notice these errors in Wine/vkd3d-proton log. I wonder why should it be complaining about nvapi:
...
0160:fixme:nvapi:unimplemented_stub function 0xe24ead45 is unimplemented!
141545.067:0020:01a8:err:vkd3d-proton:vkd3d_wait_for_gpu_timeline_semaphore: Failed to wait for Vulkan timeline semaphore, vr -4.
...
013c:fixme:nvapi:unimplemented_stub function 0x8d025b77 is unimplemented!
...
141545.074:0020:0140:err:vkd3d-proton:vkd3d_memory_transfer_queue_flush_locked: Failed to submit command buffer, vr -4.
013c:fixme:nvapi:unimplemented_stub function 0x8d025b77 is unimplemented!
013c:fixme:nvapi:unimplemented_stub function 0x8d025b77 is unimplemented!
141545.074:0020:01ac:err:vkd3d-proton:d3d12_command_queue_signal: Failed to submit signal operation, vr -4.
013c:fixme:nvapi:unimplemented_stub function 0x8d025b77 is unimplemented!
141545.074:0020:01ac:err:vkd3d-proton:d3d12_command_queue_signal: Failed to submit signal operation, vr -4.
013c:fixme:nvapi:unimplemented_stub function 0x8d025b77 is unimplemented!
...
@shmerl
0160:fixme:nvapi:unimplemented_stub function 0xe24ead45 is unimplemented!
013c:fixme:nvapi:unimplemented_stub function 0x8d025b77 is unimplemented!
These are NvAPI_D3D12_BuildRaytracingAccelerationStructureEx and NvAPI_D3D12_GetRaytracingAccelerationStructurePrebuildInfoEx respectively and I had to implement them in dxvk-nvapi because CP2077 was trying to use them even if we claimed they are not implemented.
Why do you have any nvapi at all (which doesn't look like dxvk-nvapi to me) though? Have you tried disabling/removing it? Wine 8.8 doesn't provide this library (Staging used to but it was disabled long ago) and you are on AMD GPU, it makes no sense to install it into your prefix, and the fact that the game attempts to use it in the exact same way it caused issues for us in dxvk-nvapi suggests that it could be causing issues for you as well.
No idea, I guess it got installed somehow in the past, may be by older GOG installer?
And I just deleted system32/nvapi64.dll and syswow64/nvapi64.dll and the hang is gone! That indeed was the culprit. Thanks a lot for digging into it!
I'll just make a clean prefix and try re-installing the game and will check if nvapi appears from anywhere or not.
I'll close it, since it's not vkd3d-proton's issue. Thanks again for the help!
Oh, just to confirm. Those nvapi64.dll are shown to be Wine built-in ones. My guess would be, I attempted to use that prefix with Wine-staging in the past, it created those dlls in it, and then even with other versions of Wine or later Wine staging it was just lingering there despite being not necessary. And then CP2077 started picking it up.
Now I'm wondering if this doesn't cause any issues to Windows users that switched from Nvidia to AMD GPU and still have some NV driver files left on their systems :thinking:
I don't get why CP2077 needs to insist on using nvapi dll if it exists even when it detects AMD GPU. Must be a bug.
Now I'm wondering if this doesn't cause any issues to Windows users that switched from Nvidia to AMD GPU and still have some NV driver files left on their systems 🤔
NVIDIA’s NVAPI dlls (and also our dxvk-nvapi dlls when not configured otherwise) just refuse to initialize when there is no NVIDIA card. My guess is though that the wine staging implementation just happily returns OK on initialization without any GPU vendor / driver check.
NVIDIA’s NVAPI dlls (and also our dxvk-nvapi dlls when not configured otherwise) just refuse to initialize when there is no NVIDIA card. My guess is though that the wine staging implementation just happily returns OK on initialization without any GPU vendor / driver check.
Ah, right, it does explain this case, although there is another one where we actually do have both AMD and NV GPUs and we are currently using AMD one. Hopefully the game will at least skip ignore NVAPI if none of the adapters it reports match GPU that's currently in use.
As far as I know, the adapter LUID can be used to correlate across different APIs. But yeah, I guess it is indeed up to the game to handle this properly.
Now I'm wondering if this doesn't cause any issues to Windows users that switched from Nvidia to AMD GPU and still have some NV driver files left on their systems 🤔
Got a 7900 xtx with this issue on windows, searched for a while, turns out because of this issue I found out my 1030 in my system was the cause, I knew having 2 gpu from the seperate vendors wasn't the greatest idea but it's first issue I ever encounter. I can only get past it when I disable the 1030 in device manager.
I'm asking here in case, any way to disable cyberpunk from using the nvapi dll in Windows outside of disabling the GPU?
I'm asking here in case, any way to disable cyberpunk from using the nvapi dll in Windows outside of disabling the GPU?
HAve you ever found a solution? I am in the same boat
Trying with latest vkd3d-proton master
More detailed report here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8857
An interesting message in the recent hang was this:
Is it something on the radv / mesa side or may be it's vkd3d-proton one?