I wasn’t expecting this. I upgraded to mesa 22.1.0 today and vkd3d-proton (v2.6 and any others I try, including dropping in a different build) stopped working, the games either hang on black screen or crash.
vkd3d-proton in Steam is working fine, but for some reason not Lutris’
DXVK also seems to be working fine in Lutris.
If I go back to my mesa 22.0.1 packages (built the same way), vkd3d starts working again in Lutris, but I’m not having that.
This is Control trying to launch. It just sits there on a black screen until killed. It looks like vkd3d is initializing.
lutris-wrapper: Control Started initial process 13277 from /home/grogan/.local/share/lutris/runners/wine/lutris-7.2-x86_64/bin/wine /storage3/shit/control/drive_c/GOG Games/Control/Control.exe -dx12 Start monitoring process. fsync: up and running. Initial process has exited (return code: 0) 017c:info:vkd3d_get_vk_version: vkd3d-proton - applicationVersion: 2.6.0. 017c:info:vkd3d_instance_init: vkd3d-proton - build: 3e5aab6fb3e18f8. 017c:info:vkd3d_memory_info_init_budgets: Applying resizable BAR budget to memory types: 0x0. 017c:info:vkd3d_bindless_state_get_bindless_flags: Device supports VK_VALVE_mutable_descriptor_type. 017c:fixme:d3d12_device_caps_init_feature_options1: TotalLaneCount = 2048, may be inaccurate. 017c:fixme:d3d12_swapchain_init: Ignoring swap effect 0x4. 017c:fixme:d3d12_swapchain_init: Ignoring swapchain flags 0x802. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_swapchain_GetFrameStatistics: iface 0000000049480050, stats 0000000049420208 stub! 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. 017c:fixme:d3d12_fence_init: Ignoring flags 0x1. Monitored process exited. Exit with return code 0 DEBUG 2022-05-19 16:02:59,531 [command.on_stop:195]:Process 13275 has terminated with code 0 DEBUG 2022-05-19 16:03:01,546 [game.beat:664]:Game thread stopped WARNING 2022-05-19 16:03:01,547 [game.on_game_quit:690]:Game still running (state: running) INFO 2022-05-19 16:03:01,547 [game.stop:675]:Stopping Control (wine) DEBUG 2022-05-19 16:03:01,547 [game.stop_game:628]:Control (wine) has run for 10 seconds DEBUG 2022-05-19 16:03:01,567 [game.on_game_quit:708]:Control stopped at Thu, 19 May 2022 16:03:01 DEBUG 2022-05-19 16:03:01,567 [game.save:268]:Saving Control (wine) with config ID control-1635474685 INFO 2022-05-19 16:03:04,000 [application.do_shutdown:885]:Shutting down Lutris
Ahh bollocks… it was D3D Extras causing it. I wouldn’t have thought that would even come into play here (I’m not using Wine D3D for this game) but I guess it changes symlinks to d3d compilers etc. and took a bite out of my ass.
Actually that wasn’t it either, it was a coincidence. The games stopped working again (and I hadn’t tried it for long)
This is too weird. I set Control and Cyberpunk 2077 up in Steam as non-steam games (from the same location as they are installed in Lutris) so I could test the same games. It creates its own wine prefixes in steamapps/compatdata. Both those games work there with vkd3d-proton, I copied in my game data and I can play them.
If I run them there, then launch them in Lutris they will work briefly. That’s why it loaded for me, not because I changed runner options. It would not go far though.
It seems somehow related to d3d12 shader compiling, as launching the games in steam will make them work again briefly, seemingly until shaders have to be compiled. If I delete my mesa shader cache, they won’t launch at all again in Lutris, until I run them in Steam and then they’ll work briefly in Lutris.
Why vkd3d-proton in Lutris and not valve’s or proton-ge’s in Steam? They must be doing something different. If I go back to Mesa 22.0.x it’s fine again.
Hi, you should check the debug options in the vkd3d repo:
There is a way to disable the shader cache but will reduce your performance on the other had you may need to delete the current cache. I beleive that is why it works in steam as it is starting fresh.
Just put a bunch of Env variables and hope for the best
The way the shader cache works is, new directories will be plunked down if you change anything to do with mesa (even a new build of the same version) or llvm. I delete them beforehand any time I am going to do anything that will cause them to be invalidated (and I don’t do that frivolously, as it sucks to lose it). Also, I do not use Steam’s shader cache. What a load of ridiculous spinning wheels that is.
That was actually the build of vkd3d-proton 2.6 that I had tried, and had the same problem as the one provided by Lutris.
Maybe something to do with the pipeline state cache though (vkd3d-proton.cache). I’ll try deleting that when I get to trying this again.
P.S. Everything else is really happy with this Mesa build. Only vkd3d-proton in Lutris hates it.
I made some progress with this before I went to bed this morning. It does seem related to the shader pipeline.
I seem to have gotten Control working properly now. I deleted the vkd3d-proton.cache file from the working directory. At first that didn’t work, I could still get to the main menu (because I was playing it as a non-steam game in Steam) but couldn’t load into game. However, the finishing touch was to change one graphics setting, launch the game, and change it back again (and yes I had tried that, I always do when a game stops working). When I do that I pick something serious, like texture resolution, which usually forces it to rebuild something.
I played Control for about half an hour, and traversed and fast traveled around. Quit all the way out and went back in a few times too and no problems.
However, no such luck with Cyberpunk 2077. It doesn’t get a vkd3d-proton.cache, it uses its own pipeline cache in appdata/local in the prefix. Deleting that was disastrous, the game won’t recreate it and it just hangs on a black screen until killed. For a joke, I tried dropping in the one from its steam wine prefix and it got me further, but of course freezes and crashes before the menu would come up (I wasn’t expecting that to be right, I was just observing behaviour)
My guess is that vanilla vkd3d-proton v2.6 release is too old for me with mesa 22.1.0 now, or is somehow not right. Proton and Proton-GE are using different commits (cherry picked?). I’m not set up to compile that, I don’t want to, but I think I’m going to set up a mingw environment on that system so I can try latest git.
I deleted the user settings actually, it’s dead in the water and the game can’t launch far enough to generate anything.
The shader pipeline is broken for me, even Control failed again in another hour or so of play. All was well, I played through one of the DLC missions. At the end, while looking for the best route out of there, I looked up and the game froze. It started again, but froze again a few minutes later. That game has never malfunctioned like that (there’s one crashy spot, but it often happens to people on Windows there too and it’s avoidable)
When I get some time I’m going to set up for a git build of vkd3d-proton
I think have the same issue. Bought “Diablo 2 Resurrected” yesterday and after a while playing my screens go black and never wake up again until I hard reset the PC. Sometimes I can play 10 minutes, sometimges an hour, but it’s going to happen at some point.
Running Lutris on Arch, plasma-wayland, RX 6700 XT
I use a heavily customized Manjaro, most of the significant parts of the system are my PKGBUILDs. I wouldn’t use a distro at all, except it’s too onerous to maintain all the things for gaming (+lib32) so I carefully maintain this system to keep up with Arch and maintain compatibilty with Manjaro for the distro packages. There’s not that much Manjaro here, I have pretty much gutted it and I don’t have any of their custom packages. Any distro packages I have are Arch configuration (just their builds of them), maybe just a little behind. That’s what attracted me to it, I just have to deal with a big dump of updates once a month or so instead of constantly chasing Arch updates.
I don’t use big desktop environments with compositors or anything either, and no login managers or silly KDE shit. Currently I use Lumina 1.60 with Fluxbox for the window manager, this is the best setup yet for correct focus behaviour in games (e.g. no taskbars or desktop elements popping up over top, or windows that show up but can’t be dismissed etc.)
Kernels are always mine (my way). Been doing that since 1999. Presently using Linux 5.17.9
I still haven’t solved this problem, the shader pipeline is broken (and Control actually isn’t OK either, I just had a good run but eventually the shaders got broken). This problem isn’t vkd3d, it seems to be the d3d compilers in the wine runner. I just built a new vkd3d-proton (git master) and I’m having identical behaviour with it. That’s just d3d12.dll
So that’s where I’m going next with this, a different wine build than the runners I’ve been using.
That’s what it is alright. Both games are working nicely with system Wine Staging 7.7 (and still using my new vkd3d-proton build that I dropped in). I have never actually used “system wine” before, I only have it installed because it’s a convenient way to get all the ridiculous dependencies (i.e. when it gets updated, it would pull in any new ones added). That’s a distro package, wine-staging.
I know that’s got it, because Cyberpunk 2077 wouldn’t run at all and Control would no longer load into the game, in the area where I was.
None of those Lutris wine runners worked for me for these games, I even tried the new lutris-GE-Proton-7-14
It’s not the same problem we’re having. I don’t know what the issue is (and I don’t play that game), but are you sure your system is hard locked up? That would be more likely a driver issue than wine issues if that’s the case.
When it happens, can you alt-tab to get to Lutris and hit Stop? (probably not)
You’re using KDE, can you CTRL+ESC to get the system monitor thingy (ksysguard?) up to kill the process?
Can you flip to another TTY with CTRL+ALT+F2? (If so you could kill the game process)
Ah okay, I thought because of the similar symptoms it could be the same thing or at least the same direction.
Yes, it’s hard locked. I can’t use alt+tab, ctrl+esc, nor switch TTY. the displays go into standby. It’s the first time since I’m using linux that I have encountered a non recoverable crash.
I guess I will search or open my own topic, sorry for cluttering yours! :3
I can say with confidence, that this problem I was having is fixed with the lutris-7.2-2 wine runner.
I have been testing for this (recently a few nights ago after recompiling mesa) and it’s been broken for me until now, with the -2 build of that wine runner solving it. (I’m familiar enough with the behaviour to know right away that it’s fixed)
I don’t know what’s different about that new runner, perhaps just that having been recompiled (new build) was the fix for me. There was a disconnect somewhere for me, the shader pipeline was broken.
It may not have been that I had switched to Mesa 22.1.x but that I had upgraded to gcc 12.1.0, bootstrapped and built mesa etc. Reverting back to my Mesa 22.0.x packages, those were compiled with gcc 11.2.0.
It was a mysterious failure, with only those wine runners.
P.S. I forgot to mention, I found out later it wasn’t just DirectX 12 games, but some DirectX 11 games too. For example, I had to downgrade my Origin wine prefix because Star Wars Battlefront II wouldn’t run anymore. This is now fixed too for me, with lutris-7.2-2
