[Bug 59450] New: VKD3D "fixme" errors and game hangs in Hades 2
http://bugs.winehq.org/show_bug.cgi?id=59450 Bug ID: 59450 Summary: VKD3D "fixme" errors and game hangs in Hades 2 Product: vkd3d Version: 1.18 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs@list.winehq.org Reporter: tfabris@gmail.com Created attachment 80434 --> http://bugs.winehq.org/attachment.cgi?id=80434 Shell console log output from Wine and VKD3D during run VKD3D "fixme" errors and game hangs in Hades 2 Having trouble running Hades 2 under Crossover 26.0 which includes v1.18 of VKD3D. Game runs fine for long periods, and produces some of these messages below during its run. At some point, the game intermittently hangs, with the hang not being necessarily coincident with any one particular message. It just sort of eventually, intermittently, hangs in the middle of a perfectly good run. Sometimes the game hangs very frequently (after only a few seconds of play) and sometimes it can run successfully for 30 minutes or more without a hang. The hang manifests itself as this: The graphics hang first. The game screen freezes and all of the pixels stay on the screen, unchanging. The game audio continues playing without any hitches or glitches, including, continuing to successfully play background music or long dialogue sequences without stopping. Sometimes, if the hang occurs while the character has an interaction prompt, there may be a brief window where you can still press the interaction button and hear the response audio from having pressed the button, but only the first instance of interaction, after that, nothing more is allowed and the game is truly hung. The console output stops updating, and the game's own "Hades2.log" file stops updating. The following console messages are seen in the console output. Even though the hang doesn't happen exactly at one of those messages, I wonder if any of these console messages point towards a root cause? vkd3d:023c:fixme:d3d12_root_signature_init Ignoring root signature flags 0x1d. vkd3d:023c:fixme:spirv_compiler_emit_global_flags Unhandled global flags 0x100. vkd3d:0264:fixme:d3d12_rtv_desc_create_rtv Unhandled view dimension 0x2. vkd3d:05e4:err:d3d12_device_init Cannot load DXIL conversion library, DXBC-TPF shaders won't be supported vkd3d:05e4:fixme:d3d12_device_CheckFeatureSupport Unhandled format 0x42. vkd3d:05e4:fixme:vkd3d_create_null_srv Unhandled view dimension 0xa. vkd3d:05e4:fixme:d3d12_root_signature_init Ignoring root signature flags 0x1d. Hades2's own log file, "Hades II.log" sometimes (not always) has this as its last line after a hang: 2026-02-21 15:12:48 [MainThread] App.cpp:649 INFO| Waiting for RenderCommands to be ready to write Note for developer: I'm aware that my hardware and OS that I'm using are not modern, and are outside the game's specs. But the whole point of Wine is to run games in places they weren't originally intended to run, and amazingly, in this particular case, it actually works. When Crossover 26 was released (including Wine 11.0, and whatever version of vkd3d is included with those two things), it runs Hades 2. I can sometimes play for long periods of time without troubles, there's just the occasional random hang that would be very nice to be able to fix. I wonder if this particular configuration is helping to surface some rare edge-case bugs in vkd3d? Any help or advice would be gleefully accepted. In particular, I'd like to know if there's any way to get more detailed VKD3D logs out of Crossover? I'm attaching a console log output but it's not particularly detailed. Also in the game's installed files, in the Hades2/Content/Shaders folder, there are a bunch of plain-text files, and I wonder if editing any of those could simplify the D3D12 calls and prevent the hangs. Software and hardware information: Game: Hades 2 version 1.133066 The messages, and the hang issue, occur equally in the Windows Steam version of the game, or the Windows Epic Games version of the game. The Epic Games version can run directly without a launcher, without Epic or Steam in memory. Machine: Macbook Pro 15-inch, 2016 CPU: 2.9 GHz Quad-Core Intel Core i7 RAM: 16 GB 2133 MHz LPDDR3 GPU: Radeon Pro 460 4 GB Driver: Whatever driver comes with MacOS Monterey 12.7.6 Wine version: Crossover 26.0, using Wine 11.0 VKD3D version: vkd3d 1.18 or whatever is included with Crossover 26.0 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 Tony Fabris <tfabris@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tfabris@gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #1 from Henri Verbeet <hverbeet@gmail.com> --- Hi, thank you for the report. You should probably be aware that CrossOver ships a modified version of vkd3d, and that makes it somewhat harder for us to provide support upstream. Ideally you would create a (Win32) build of upstream vkd3d, integrate that into your CrossOver build/bottle, and then test against that. I'm not sure how much experience you have with building and patching your own software; I can try to assist, but the learning curve may be a bit steep if you're very new to this. (In reply to Tony Fabris from comment #0)
I'm aware that my hardware and OS that I'm using are not modern, and are outside the game's specs. But the whole point of Wine is to run games in places they weren't originally intended to run, and amazingly, in this particular case, it actually works.
I'm probably in the minority on this, but personally I fully support and encourage that.
Any help or advice would be gleefully accepted. In particular, I'd like to know if there's any way to get more detailed VKD3D logs out of Crossover? I'm attaching a console log output but it's not particularly detailed.
There are some environment variables that should allow you to get more detailed debug output. In particular, VKD3D_DEBUG="trace" should enable debug output for libvkd3d, and VKD3D_SHADER_DEBUG="trace" should enable debug output for libvkd3d-shader. Note that both of these potentially produce a large amount of output. These environment variables and others are described in more detail in the "Environment variables" section of https://codeberg.org/vkd3d/vkd3d/raw/tag/vkd3d-1.19/README On the Wine side of things, the WINEDEBUG environment variable has a similar role, although with a slightly different syntax. WINEDEBUG="+seh" may provide some hints about any exceptions / access violations that may be happening around the time hang. Finally, the first question I have about the log you attached is how much the "vkd3d:060c:fixme:d3d12_rtv_desc_create_rtv Unhandled view dimension 0x2." lines correlate with the hang. Are those always present right after starting the game, or do those e.g. show up later with the game hanging shortly afterwards? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #2 from Tony Fabris <tfabris@gmail.com> --- Henri, thanks so much for your detailed response. To answer your last question quickly: The message "Unhandled view dimension 0x2" is a continuous stream in the console from the moment the game starts playing. Yet the game still runs fine during that stream of messages. I can play the game for long stretches with that message continuously spilling out of the console. The hang is not coincident with that message, or any other particular message. Regarding the fact that VKD3D is modified in Crossover: I had tried to contact their tech support about it first. I'm a lifetime-paid Crossover customer (they even sent me swag when I signed up) but they just shrugged their shoulders about it. Though whatever modification they made to VKD3D, it works, because I can run the game under Crossover but not under a vanilla build of Wine. I'd love to know what it is that they did; if there's a way to make that tweak (whatever it is) to a vanilla build of Wine, and then troubleshoot from there, that might be fruitful. Crossover's whole deal was that they were advertising that version 26.0 made a whole bunch of new games compatible, and I have a guess that their changes to VKD3D were a big part of that process. Here's their blog post about it: https://www.codeweavers.com/blog/mjohnson/2026/2/10/crossover-26-cures-artif... Regarding building my own software: As recently as a couple of years ago, I was the DevOps engineer in charge of the entire set of version control and build systems for a large software company. The problem is, it was an all Microsoft/Windows/Azure house, so I've got only a little bit of experience with building software on Linux/Unix/BSD/MacOS. Though I'm absolutely willing to give that a shot with some guidance. There's only a couple of barriers to that: I'm on MacOS v12 Monterey, and my Intel Mac won't run a newer OS than that. And the most common package manager, Homebrew, is deprecated on Macos v12 Monterey and I have to find versions of everything on MacPorts instead of Homebrew. However, I'm happy to spin up a virtual machine to run builds if needed: I'm a paying customer of Parallels as well, so if Wine/VKD3D builds can be built in one of those VMs I could do that too. I just wouldn't know where to start, or how to integrate those built files into a Crossover bottle, without guidance. In the meantime, I will try using those environment variables to get more information out of the version of VKD3D that's running in Crossover. If there's anything new in that output, I'll put it here, and also send it to the Crossover folks and see if they can come up with something too. Thanks so much for your help! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #3 from Tony Fabris <tfabris@gmail.com> --- Slight update about that one error message: "Unhandled view dimension 0x2" isn't the one that comes out in a continuous stream while playing the game. The one that comes out in a continuous stream is this one: "Hades2.exe[73770:1377817] addPresentedHandler cannot be called after drawable has been presented" and that's not even a VKD3D Message. So I'll try to get more information about "Unhandled view dimension 0x2" and get back to you. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #4 from Tony Fabris <tfabris@gmail.com> --- Created attachment 80444 --> http://bugs.winehq.org/attachment.cgi?id=80444 Console output after setting VKD3D_DEBUG=trace - Did that work? Attaching console output after executing these commands (I'm doing everything at the shell instead of using the Crossover UI): VKD3D_DEBUG="trace" "/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/CrossOver-Hosted Application/wine" --bottle "Games and Utilities" --cx-app "C:\Program Files\Hades2\Ship\Hades2.exe" The game hangs at the same time the stream of console output stops. I can't tell if the "trace" command had any effect on the console output. Did it work or am I doing it wrong? As always: The message "Hades2.exe[73770:1377925] addPresentedHandler cannot be called after drawable has been presented" is a continuous constant stream of output, intermixed with other messages, and that's not a VKD3D message so I don't think it's useful in this case? Mainly I'd like to know if the variable VKD3D_DEBUG="trace" worked at all? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #5 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #2)
To answer your last question quickly: The message "Unhandled view dimension 0x2" is a continuous stream in the console from the moment the game starts playing. Yet the game still runs fine during that stream of messages. I can play the game for long stretches with that message continuously spilling out of the console. The hang is not coincident with that message, or any other particular message.
Too bad; it would have been a relatively easy issue to address. :) I'll see what I can do about some of the FIXMEs in that log, but it doesn't look especially likely that they have anything to do with the hang you're seeing. Unfortunately that also casts some doubt on whether this is necessarily a vkd3d issue; I don't think an issue in a different part of Wine (or e.g. MoltenVK) can be ruled out at this point.
Regarding the fact that VKD3D is modified in Crossover: I had tried to contact their tech support about it first. I'm a lifetime-paid Crossover customer (they even sent me swag when I signed up) but they just shrugged their shoulders about it.
Sorry to hear that. Just so I don't give the wrong impression, I actually work for CodeWeavers, but I'm not that much involved with CrossOver or the macOS side of things, and my role in this bug tracker is purely that of vkd3d maintainer/developer.
Though whatever modification they made to VKD3D, it works, because I can run the game under Crossover but not under a vanilla build of Wine. I'd love to know what it is that they did; if there's a way to make that tweak (whatever it is) to a vanilla build of Wine, and then troubleshoot from there, that might be fruitful.
The source code for vkd3d (and Wine, and a few other components) in CrossOver can be found at https://www.codeweavers.com/crossover/source (There are a few different ways to get there from the CodeWeavers homepage; one way is to go to "CrossOver", scroll to the bottom of the page, then click "GET CROSSOVER SOURCE CODE".)
Regarding building my own software: As recently as a couple of years ago, I was the DevOps engineer in charge of the entire set of version control and build systems for a large software company. The problem is, it was an all Microsoft/Windows/Azure house, so I've got only a little bit of experience with building software on Linux/Unix/BSD/MacOS. Though I'm absolutely willing to give that a shot with some guidance. There's only a couple of barriers to that: I'm on MacOS v12 Monterey, and my Intel Mac won't run a newer OS than that. And the most common package manager, Homebrew, is deprecated on Macos v12 Monterey and I have to find versions of everything on MacPorts instead of Homebrew. However, I'm happy to spin up a virtual machine to run builds if needed: I'm a paying customer of Parallels as well, so if Wine/VKD3D builds can be built in one of those VMs I could do that too. I just wouldn't know where to start, or how to integrate those built files into a Crossover bottle, without guidance.
Wine uses Windows builds of vkd3d; in principle that means it doesn't matter too much whether the build was made on macOS, Linux, Windows, or somewhere else. Building on Windows is possible, but needs something like MSYS2 or Cygwin. WSL 2 might work as well, but I'm not aware of anyone having tried. If you have some familiarity with building things on Linux, building in a Linux VM may be the easiest option. For macOS, the main package you'll need is mingw-w64; I think that's called the same in both brew and MacPorts. mingw-w64 also includes WIDL in the form of x86_64-w64-mingw32-widl, at least in brew. There are some instructions at https://gitlab.winehq.org/wine/vkd3d/-/wikis/Building-a-MinGW-WoW64-Wine-wit... Those are written for Linux, but should largely apply to macOS as well. It may be best to just send me an e-mail if you run into any issues with this part, to avoid spamming the bug tracker too much. :) (In reply to Tony Fabris from comment #4)
I can't tell if the "trace" command had any effect on the console output. Did it work or am I doing it wrong?
It doesn't look like it; if it worked you'd see a lot of output of the form "vkd3d:....:trace:...". It may be that the CrossOver UI is interfering; I know it has a mechanism to set these environment variables through the GUI, and that may be overriding what you're setting on the command line. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #6 from Tony Fabris <tfabris@gmail.com> --- Henri, thanks so much for your response. If you're happy to answer direct emails about compiling my own VKD3D, that would be lovely. I'll ensure I've got mingw-w64 working, and then drop you a line. If my efforts produce any useful information, I'll provide updates here in the bug tracker. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #7 from Tony Fabris <tfabris@gmail.com> --- Created attachment 80458 --> http://bugs.winehq.org/attachment.cgi?id=80458 Vkd3d trace log output before crash Thanks to Henri, I'm successfully compiling various versions of vkd3d and I'm able to get it running under Crossover. This also helped me obtain trace log output from vkd3d which is attached to this message. (For some reason, adding VKD3D_DEBUG="trace" to the bottle's configuration didn't give me trace messages, so I had to hardcode the default to VKD3D_DBG_LEVEL_TRACE to get any trace output.) I'm able to compile both the mainline vkd3d version and also the modified version found in the Crossover 26.0 source code found at https://www.codeweavers.com/crossover/source Here's what I have learned so far: - Mainline versions of vkd3d won't even run Hades 2 at all. They all pop up a message box complaining that it can't create a renderer. Only the modified version of vkd3d that comes with Crossover 26.0 will run the game. - From looking at the diffs in the code, I wonder if it's the addition of mtlvkext (Molten VK extensions?) that lets Crossover's modified version run this game. Don't know. It's included in libs/vkd3d/vkd3d_private.h and the .h file is found in /include/private. There's also a line that targets a newer Vulkan version, in programs/vkd3d-compiler/main.c there's a line saying "spirv_target_info.environment = VKD3D_SHADER_SPIRV_ENVIRONMENT_VULKAN_1_1" which used to be "1_0". There's also a line in libs/vkd3d/device.c talking about the hacks they needed to do to to get around problems with a broken MoltenVK descriptor index. - From looking at the diffs in the code, I wonder if the hang is in memory or cache management? The modifications from the baseline version have some major changes to memory management and cache rebalancing. - When I have enabled trace output, the amount of text spewing to the console is massive. Enough to slow the game's frame rate down just a hair, making it kind of hitch and sputter ever so slightly. This reduced the frequency of hangs massively! It used to be that hangs would happen every few minutes (or every several minutes), but after switching it to "trace" output I was able to play the game for more than an hour before the first hang. So the hang happens depending on the timing of the game code. This also makes me wonder if it's a memory management bug which is only hit in intermittent situations. I'd love it if the Codeweavers developers who are in charge of the modified Crossover version of vkd3d could take a peek at this bug report and the attached trace output. I'd also be happy to try out any newer work-in-progress builds of their modified version of vkd3d. Right now the only source code I have of the modified version is the one that ships with Crossover 26.0. Henri, can you put in a good word for me? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #8 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #7)
- Mainline versions of vkd3d won't even run Hades 2 at all. They all pop up a message box complaining that it can't create a renderer. Only the modified version of vkd3d that comes with Crossover 26.0 will run the game.
- From looking at the diffs in the code, I wonder if it's the addition of mtlvkext (Molten VK extensions?) that lets Crossover's modified version run this game. Don't know. It's included in libs/vkd3d/vkd3d_private.h and the .h file is found in /include/private. There's also a line that targets a newer Vulkan version, in programs/vkd3d-compiler/main.c there's a line saying "spirv_target_info.environment = VKD3D_SHADER_SPIRV_ENVIRONMENT_VULKAN_1_1" which used to be "1_0". There's also a line in libs/vkd3d/device.c talking about the hacks they needed to do to to get around problems with a broken MoltenVK descriptor index.
The single most consequential change is probably the "vk_info->max_feature_level = D3D_FEATURE_LEVEL_12_2;" line; it changes the highest reported feature level, and some applications are known to require feature level 12.2. You can pretty much ignore any changes in programs/ and tests/; none of that code is used by Wine/CrossOver. The change to disable descriptor indexing you mentioned is also significant, but wouldn't typically help with the application failing to create a renderer. Other fairly significant changes are those to libs/vkd3d-shader, and potentially the change to d3d12_device_CheckFeatureSupport().
- From looking at the diffs in the code, I wonder if the hang is in memory or cache management? The modifications from the baseline version have some major changes to memory management and cache rebalancing.
Possibly; it's certainly non-trivial code.
- When I have enabled trace output, the amount of text spewing to the console is massive. Enough to slow the game's frame rate down just a hair, making it kind of hitch and sputter ever so slightly. This reduced the frequency of hangs massively! It used to be that hangs would happen every few minutes (or every several minutes), but after switching it to "trace" output I was able to play the game for more than an hour before the first hang. So the hang happens depending on the timing of the game code. This also makes me wonder if it's a memory management bug which is only hit in intermittent situations.
Yeah, that's a possibility; or some kind of synchronisation issue more generally. In terms of next steps, I think there are a couple of different routes of investigation: - If you can get the application to work with upstream vkd3d, e.g. by using the D3D_FEATURE_LEVEL_12_2 change mentioned above, that may help rule out an issue with the CrossOver changes. (Or confirm it's caused by one of those; that'd be good too, of course.) - If the hang you're getting is a crash, the earlier mentioned WINEDEBUG="+seh" would show some evidence of that, and provide some information about the circumstances. - If it's something like a deadlock, attaching to the process with winedbg and getting a backtrace may help you figure out where. There's some documentation about winedbg basics at https://gitlab.winehq.org/wine/wine/-/wikis/Commands/winedbg, and some more useful bits at https://gitlab.winehq.org/wine/wine/-/wikis/Debugging-Hints. It'll probably take some getting used to regardless. - Does the game always hang after a d3d12_command_list_ResourceBarrier() call like that? It may be worth adding a TRACE to the end of that function to determine whether the hang happens inside that function, or after it completes. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #9 from Tony Fabris <tfabris@gmail.com> --- Henri, thanks so much! I have written unit tests and integration tests before, as well as having written tool programs (albeit in C# on Windows), so I knew that I didn't need to be looking at anything in the Tests or Tools folder since they wouldn't be relevant to the issue. I was wondering when I was going to need to bite the bullet and start actually attaching a debugger. Thanks for the links to getting that working. I've done some app debugging on Windows before, but never debugged a video driver under Linux before, so that will be an interesting new area for me to dig into. Your suggestions are excellent and I'll give them all a shot. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #10 from Tony Fabris <tfabris@gmail.com> --- Tried so far: In the Crossover version of vkd3d 1.18, I tried setting the debug level back to the default level of "fixme" and adding these lines at the beginning and the end of the d3d12_command_list_ResourceBarrier function: FIXME("****** START d3d12_command_list_ResourceBarrier ******\n"); FIXME("****** END d3d12_command_list_ResourceBarrier ******\n"); The reason I did them at fixme level instead of trace level was so that I could hopefully induce the hang more often. These lines indeed show up on my console outuput, but they show up as often as the other trace messages did, so the continuous console spew still slows down the game's framerate, thus, as before, preventing a repro. In the Crossover version of vkd3d 1.18, I tried confirming that "vk_info->max_feature_level " is the reason that Crossover runs the game and Mainline vkd3d doesn't. Indeed, this seems to be true: setting the Crossover version back down to the same version as mainline vkd3d 1.18 (D3D_FEATURE_LEVEL_11_0) does produce the dialog box, and setting the mainline vkd3d 1.18 version to D3D_FEATURE_LEVEL_12_2 does allow the game to launch. (By the way, the dialog box in question is the one that says "Renderer creation failed. Please ensure your graphics card meets the minimum requirement".) However, even though mainline vkd3d 1.18 will "launch" the game with that one-line change, it doesn't render it on the screen at all, I get a fully red screen instead of the game screen. The game's main menu music still plays in the background, so I feel like we're making progress towards getting mainline vkd3d running it. My next task will be trying to build the latest build of mainline vkd3d (1.19 or newer) and see if a simple change to max_feature_level will let it launch the game. However I can't download its source code from git because, purely by coincidence, the web site hosting the latest code (codeberg.org) is down right now. Sigh. I'll try again later. :-) In the meantime, I'll go back to the Crossover version with the messages on the d3d12_command_list_ResourceBarrier function, and see if a longer play session will induce the bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla