Hello @Leopard1907, can you also test how Proton Experimental behaves?
Hi @kisak-valve , i've tested it with Experimental too as requested.
Results are:
1-) Experimental made the game work however it was a slideshow,even in the menu and intro videos.
2-) Forcing dxvk dxgi on Experimental made the game work optimally.
Logs from different situations:
steam-233130-Experimental-DXVK dxgi.log
steam-233130-Experimental-Wine dxgi.log
steam-233130-Proton-6.3.4wine-dxgi.log
From experimental Wine dxgi log:
info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_11_1
info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_11_0
info: D3D11CoreCreateDevice: Using feature level D3D_FEATURE_LEVEL_11_0
info: Device properties:
info: Device name: : llvmpipe (LLVM 12.0.0, 256 bits)
info: Driver version : 0.0.1
Which explains slowness.
In summary: DXVK dxgi is still needed.
I don't see anything obvious in Proton 6.3-3 that would have caused it to start choosing the wrong device. Are you certain that Proton 6.3-2 was working well with this setup?
I'm also surprised that Experimental makes a difference. We do ship a slightly newer DXVK in there, I wonder if it handles this crummy device differently.
Yes, it didn't have such issue with 6.3-2 ( but in any case QA shouldn't take an end users word for it so let's say i'm 99 percent sure). All i see as dxgi changes noted in the changelog are Origin overlay fixes.
On Experimental with Wine dxgi somehow lavapipe ( which exists on every users system that have up-to-date Mesa) gets picked despite
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only
is in use which is suppose to avoid such issues.
https://github.com/doitsujin/dxvk/blob/master/src/dxvk/dxvk_instance.cpp#L170
This should be how DXVK handles it.
But looks like it isn't in effect with Wine dxgi somehow and lavapipe gets picked.
https://github.com/KhronosGroup/Vulkan-Loader/pull/553
It might be a good idea to blacklist lavapipe indefinitely until PR linked above has come to a conclusion due to how it can cause issues currently.
Also this is an indicator of that happened with 6.3-3.
https://github.com/ValveSoftware/Proton/issues/4817#issuecomment-839888909
https://github.com/ValveSoftware/Proton/issues/4815#issue-884226710
Probably not a coincidence that these issues are reported against 6.3-3.
Indeed. We did find a DXGI regression caused by one of those commits (see #4824) but I'd expect it to cause a crash, not performance problems... but, who knows.
Anyway, I uploaded a build of Wine's DXGI here which fixes that issue. Can you drop it into your Proton 6.3 dist/ directory, overwriting the dxgi files that are already there, and see if it helps? dxgi_issue4835.tar.gz
It didn't help.
Yeah, I'm not surprised. We did bump some stuff related to reporting the Windows version in 6.3-3, I guess that might have caused some games to take a different codepath and so cause this regression. But otherwise I'm out of ideas.
We do plan to switch back to DXVK's DXGI in the near future, which I guess will solve this, but I wish we understood what caused the problem.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/4828#note_930644
Fwiw that Wine dxgi regression affects single gpu users as well. With lavapipe they effectively has two gpu devices and anything newer than Proton 6.3-3 makes the issue visible.
Closing this issue because it is resolved with Proton 6.3-5.
https://github.com/ValveSoftware/Proton/issues/4815#issue-884226710
https://github.com/ValveSoftware/Proton/issues/4874
These issues linked above should be closed as well since root cause for them was also usage of Wine DXGI.
proton 6.3-5x1 2021-06proton 6.3-3x3 2021-05proton 6.3x2 2021-05proton 6.3-2x1 2021-05proton experimentalx1 2021-05WINEDLLOVERRIDES=dxgi=nx1 2021-05WINEDLLOVERRIDES=dxgi=n %command%x1 2021-05
Prime setups ( Intel+Nvidia and AMD+Nvidia) suffers from this issue. While issues such as this exists , they are far from describing the issue as it affects all d3d11 and 12 games, not tied to games produced with a specific engine. D3D9 games are not affected since they don't use dxgi.
Regression point: It started to happen with Proton 6.3-3 release. Prior to that, there was no such issue.
Setup info:
https://gist.github.com/Leopard1907/fdd3f3f53b3dd6c54cb6cf07c0fab948
How i use Steam:
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only steamClient only sees Nvidia as gpu with those vars so Fossilize compiles shaders against it and it also removes need of classic setting this up each time for individual games via game launch options.
A log from a game that failed under Wine DXGI ( default of Proton) :
steam-611500.log
Parts from log that caught my attention:
warn: D3D11CoreCreateDevice: Adapter is not a DXVK adapterinfo: D3D11CoreCreateDevice: Probing 0err: D3D11CoreCreateDevice: Requested feature level not supportedSame affected games works with DXVK dxgi:
WINEDLLOVERRIDES=dxgi=n %command%