[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.
http://bugs.winehq.org/show_bug.cgi?id=59450 --- Comment #11 from Tony Fabris <tfabris@gmail.com> ---
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.
Building 1.19 of mainline vkd3d with that change has the same behavior as 1.18: Game launches but screen is solid red, no rendering. -- 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 #12 from Tony Fabris <tfabris@gmail.com> --- Okay interesting. I reproduced a hang with those messages active in the d3d12_command_list_ResourceBarrier function. And the last is not at the start of the function. If these messages are to be believed, it's not hanging *inside* that function. The last six lines of the output are: vkd3d:0130:fixme:d3d12_command_list_ResourceBarrier ****** START d3d12_command_list_ResourceBarrier ****** vkd3d:0130:fixme:d3d12_command_list_ResourceBarrier ****** END d3d12_command_list_ResourceBarrier ****** vkd3d:0130:fixme:d3d12_command_list_ResourceBarrier ****** START d3d12_command_list_ResourceBarrier ****** vkd3d:0130:fixme:d3d12_command_list_ResourceBarrier ****** END d3d12_command_list_ResourceBarrier ****** vkd3d:0130:fixme:d3d12_command_list_ResourceBarrier ****** START d3d12_command_list_ResourceBarrier ****** vkd3d:0130:fixme:d3d12_command_list_ResourceBarrier ****** END d3d12_command_list_ResourceBarrier ****** -- 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 #13 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #10)
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.
That's likely to be either from the vkd3d-shader changes, or from disabling VK_EXT_descriptor_indexing. In principle setting the VKD3D_DISABLE_EXTENSIONS environment variable to "VK_EXT_descriptor_indexing" should allow you to disable the extension without modifying the vkd3d source, but if you're worried about CrossOver interfering with environment variables, you can also just add the "vulkan_info->EXT_descriptor_indexing = false;" line to vkd3d_init_device_caps(). (You don't need the condition that limits it to MoltenVK for our purposed here.) The vkd3d-shader changes most likely to matter are those that touch dxil.c and spirv.c, and those depend on the changes to struct vsir_program in vkd3d_shader_private.h. As a first step it may make sense to just apply all the changes to vkd3d-shader, and then just remove things step by step. The other thing to point out is that shader compilation failures should result in a "Failed to compile shader, ..." WARN message from create_shader_stage(), which may help to narrow things down. -- 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 #14 from Tony Fabris <tfabris@gmail.com> ---
you can also just add the "vulkan_info->EXT_descriptor_indexing = false;" line to vkd3d_init_device_caps().
I added that line into mainline vkd3d v1.19, and it didn't allow the game to render. Still a red screen.
shader compilation failures should result in a "Failed to compile shader, ..." WARN message from create_shader_stage(), which may help to narrow things down.
It gets a slightly different error about shader compilation when it is displaying the red screen. The console ouput fills with this message during the red screen: "[mvk-error] VK_ERROR_INVALID_SHADER_NV: Vertex shader function could not be compiled into pipeline. See previous logged error."
As a first step it may make sense to just apply all the changes to vkd3d-shader, and then just remove things step by step.
Do you mean this? Go through the diffs between the Crossover version of vkd3d and the mainline version of vkd3d and try to port the shader changes over? Sounds like a big job which might require domain knowledge about video driver coding. I'll look at the diffs, though, and see if it's within my powers. :) -- 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 #15 from Tony Fabris <tfabris@gmail.com> --- Created attachment 80488 --> http://bugs.winehq.org/attachment.cgi?id=80488 Small chunk of the console output during the "red screen" Actually, porting the Crossover vkd3d 1.18 changes over to mainline vkd3d 1.19 was not too bad, as long as I restricted myself to *only* the libs/vkd3d-shader directory. Which I think was what you were suggesting. Alas, it still just renders a red screen, and there are still a lot of shader compilation errors on the console output. I tried to grab some of them and attach them here. -- 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 #16 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #15)
Actually, porting the Crossover vkd3d 1.18 changes over to mainline vkd3d 1.19 was not too bad, as long as I restricted myself to *only* the libs/vkd3d-shader directory. Which I think was what you were suggesting.
Right.
Alas, it still just renders a red screen, and there are still a lot of shader compilation errors on the console output. I tried to grab some of them and attach them here.
That's a little odd. With the exception of the descriptor indexing extension change, the changes outside libs/vkd3d-shader generally shouldn't affect shader compilation. -- 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 #17 from Tony Fabris <tfabris@gmail.com> --- Finally figured out why I couldn't get Wine or vkd3d environment variables to work. Simple syntax problem, either at the shell prompt or inside the bottle's cxbottle.conf. Every example I saw said to set Wine environment variables like this, with spaces and quotes: VKD3D_DEBUG = "trace" Turns out it has to be without quotes or spaces, like this (this one works in cxbottle.conf): VKD3D_DEBUG=trace Similarly for the shell prompt, though at the shell prompt I also had to prefix it with the "export" command or else it wouldn't work. That's also something that everyone omits from all the examples I saw when I was searching for instructions about it. It took Google's AI bot to tell me that, so it's useful for something I suppose. :) So my current situation is: - I can build and test versions of vkd3d from either Crossover or from mainline vkd3d. For crossover, I only have the source code for the version 1.18 included in Crossover 26.0. - So far only the Crossover 26.0 version (with the modified vkd3d v1.18) will run the game at all. Without modification, it hangs frequently, without any console message indicating a crash. If I switch its default console output to VKD3D_DEBUG=trace, the frame timing changes and the game doesn't hang, or hangs very rarely. - Can't figure out how to get mainline vkd3d 1.18 or 1.19 to actually render the game. Without modification, it halts with an error dialog which says "Renderer creation failed. Please ensure your graphics card meets the minimum requirement", but if I modify device.c with the line "vk_info->max_feature_level = D3D_FEATURE_LEVEL_12_2;" it just renders a red screen, even if I port all the changes from the crossover vkd3d-shader over to it. - Haven't tried attaching a debugger to the process yet, looks like that's my next step. I still suspect a memory management or cache management bug, but if so, I'll bet that catching that in the debugger will be tricky. -- 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 #18 from Tony Fabris <tfabris@gmail.com> --- Wait, I just got mainline vkd3d 1.19 rendering the game. The secret was learning the special secret syntax to get environment variables working for Wine. Once I added this line to my script (in this exact syntax, with no spaces or quotes as I had previously been mistakenly led to believe were needed) then mainline VKD3D 1.19 is running and rendering. export VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_indexing When I had tried to hardcode that earlier, I must have been putting the line in the wrong place or something. Anyway, it now renders the game the same as the Crossover version did. Including the hang! So we have a repro on 1.19! Note: This is still the version of VKD3D 1.19 that I had modified. - I had added this hardcode at the end of the vkd3d_init_feature_level function in device.c: vk_info->max_feature_level = D3D_FEATURE_LEVEL_12_2; - Ported the Crossover changes to the code in libs/vkd3d-shader. This tells me one important thing so far: Whatever the issue is, it's not the thing I suspected (the memory and cache management changes in the Crossover version of vkd3d) because this build doesn't have those in it. I'm going to see if using a more "plain" version of mainline VKD3D 1.19 will work (one with fewer modifications), and attempt to get a debugger attached. -- 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 #19 from Tony Fabris <tfabris@gmail.com> --- Created attachment 80493 --> http://bugs.winehq.org/attachment.cgi?id=80493 Crash stacktrace I'm able to get a cleaner build of mainline VKD3D 1.19 running the game. It does NOT need the shader changes ported over from the Crossover version. It only needs this one hardcoded line change to get past the ""Renderer creation failed. Please ensure your graphics card meets the minimum requirement" dialog box: ~/src/vkd3d-git/libs/vkd3d/device.c line 1484: // Add this line before the TRACE statement at the // end of the vkd3d_init_feature_level function: vk_info->max_feature_level = D3D_FEATURE_LEVEL_12_2; It also needs this environment variable to be set, so that the screen renders instead of showing a red screen: export VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_indexing Then it runs, and also reproduces the issue. NOTE: I think there might be more than one crash or hang issue. Sometimes I get a crash with a stacktrace on the console, sometimes I get a graphics hang where I can still hear myself make menu selections but the screen doesn't refresh, and those don't have a crash/stacktrace on the console. So that might be two separate bugs. Anyway, attached is the one with the stacktrace. Any ideas on this one? -- 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 #20 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #19)
Then it runs, and also reproduces the issue. NOTE: I think there might be more than one crash or hang issue. Sometimes I get a crash with a stacktrace on the console, sometimes I get a graphics hang where I can still hear myself make menu selections but the screen doesn't refresh, and those don't have a crash/stacktrace on the console. So that might be two separate bugs. Anyway, attached is the one with the stacktrace. Any ideas on this one?
The interesting part is part is probably entry #5, pointing to libMoltenVK.dylib. I'm not a MoltenVK or Objective-C expert by any stretch, but it looks like Metal is running a "scheduled" handler for a command buffer, added by MoltenVK with MTLCommandBuffer::addScheduledHandler() [1], and the handler then ending up with an "unrecognized selector" exception, possibly because the object the selector is called on was already free'd. The location ("vk_icdGetPhysicalDeviceProcAddr + 117451") just looks wrong. I don't immediately know why that is; perhaps missing/broken debug info. Conveniently though, there's only a single place in MoltenVK that calls addscheduledhandler(): MVKPresentableSwapchainImage::presentCAMetalDrawable() [2]. The "present" selector from the stack trace would be consistent with the "[mtlDrwbl present];" line from presentCAMetalDrawable(). [1] https://developer.apple.com/documentation/metal/mtlcommandbuffer/addschedule... [2] https://github.com/KhronosGroup/MoltenVK/blob/v1.4.1/MoltenVK/MoltenVK/GPUOb... -- 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 #21 from Tony Fabris <tfabris@gmail.com> --- Excellent info, thanks so much! I have a slight understanding of what's going on there, but it looks like that MoltenVK source code isn't under my control. Am I right about that? There's some stuff in the vulkan headers which points to that code, but the code itself doesn't seem to part of the vkd3d build process. Is there anything I can do to help find the root cause of that crash? -- 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 #22 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #21)
I have a slight understanding of what's going on there, but it looks like that MoltenVK source code isn't under my control. Am I right about that? There's some stuff in the vulkan headers which points to that code, but the code itself doesn't seem to part of the vkd3d build process. Is there anything I can do to help find the root cause of that crash?
It's not part of vkd3d, but it is part of CrossOver, and included in the CrossOver sources; in principle you could create your own build of MoltenVK, much like you did for vkd3d. The process is a bit different because MoltenVK uses a different build system and is a macOS library instead of a set of Windows DLLs like vkd3d though. It's perhaps also worth pointing out how these things fit together. MoltenVK is a Vulkan implementation for macOS, on top of Metal. The main alternative these days is probably the Mesa based KosmicKrisp, but that depends on Metal 4 and newer macOS. vkd3d uses MoltenVK for the Vulkan calls it makes. However, the MVKPresentableSwapchainImage::presentCAMetalDrawable() call doesn't ultimately originate from vkd3d. Instead, it would originate from a vkQueuePresentKHR() call in d3d12_swapchain_queue_present() in Wine's dlls/dxgi/swapchain.c. Much like d3d12 on Windows, vkd3d doesn't directly interact with windows and swapchains; that's the responsibility of the DXGI component. In terms of debugging things, it may be worth enabling the DXGI debug channel with WINEDEBUG="+dxgi". You'd expect a d3d12_swapchain_Present() or d3d12_swapchain_Present1() shortly before the crash, and if it's in fact the same issue, before the hang as well. -- 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 #23 from Tony Fabris <tfabris@gmail.com> --- Fantastic info, thanks! I'll try to get those DXGI messages to output, and continue trying to find the source of the (possible) other hang bug which occurs without a crash/stacktrace. -- 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 #24 from Tony Fabris <tfabris@gmail.com> --- I'm also able to launch the game under winedbg. The issue seems to be less frequent with the debugger attached. But I can still get the occasional repro. When the "hang" issue does occur (the one without the crash/stacktrace), the debugger doesn't automatically break in, and I can't find the keyboard shortcut to break in. It's not ctrl-c because that kills the game process. -- 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 #25 from Tony Fabris <tfabris@gmail.com> --- And I can't seem to get any dxgi debug messages to show up on the console. I've tried these syntaxes: cxbottle.conf: "WINEDEBUG"="+dxgi" WINEDEBUG="+dxgi" shell prompt: export WINEDEBUG="+dxgi" export WINEDEBUG=+dxgi Nothing related to dxgi showing up on the console. -- 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 #26 from Tony Fabris <tfabris@gmail.com> --- Created attachment 80502 --> http://bugs.winehq.org/attachment.cgi?id=80502 Full backtraces during hang issue Ah, you don't need to launch the game with the debugger attached. You can attach the debugger after-the-fact and have it print a full backtrace for every process that Wine is running. Attached is a backtrace from during one of the "hang" moments: When the game is hung but there is no crash or stacktrace shown at the shell prompt. I don't know if anything in there is significant? -- 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 #27 from Tony Fabris <tfabris@gmail.com> --- Created attachment 80518 --> http://bugs.winehq.org/attachment.cgi?id=80518 bt all while the hang is occurring - winedbg hung and didn't finish the bt all command and didn't return to the prompt Here's an interesting (if not useful) backtrace. During one of the "hang" events, I launched winedbg and did a "bt all". Attached is its output. It froze and did not complete the backtrace, and never returned to its prompt. I notice that, different from the previous backtrace, the game isn't in the list of processes despite the fact that the game was still a live process, just frozen. Perhaps the backtrace hung at the first moment that it attempted to get a backtrace of the game process? -- 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 #28 from Tony Fabris <tfabris@gmail.com> --- Created attachment 80519 --> http://bugs.winehq.org/attachment.cgi?id=80519 Another backtrace during a hang, this backtrace completed. Another backtrace during a game hang, this one fully completed instead of hanging itself. -- 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 #29 from Tony Fabris <tfabris@gmail.com> --- I don't know much about how to read the information in these backtraces. But one fun thing I notice is that FMOD keeps running. That's the reason the game sound keeps playing even after the game itself has hung. -- 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 #30 from Tony Fabris <tfabris@gmail.com> --- Created attachment 80529 --> http://bugs.winehq.org/attachment.cgi?id=80529 Another similar backtrace Attaching another backtrace during a hang. Comparing it to previous ones, I see a lot of commonalities, but I don't know if they're significant. For example, this bit is always the same, but it sometimes has zero instead of "7c0d28" in the addresses below: Backtracing for thread 0178 in process 0120 (C:\Program Files\Hades2\Ship\Hades2.exe): Backtrace: =>0 0x006ffffb3d9103 in winevulkan (+0x19103) (0x000000007c0d28) 1 0x006ffffc71ddcb vkd3d_fence_worker_main+0x17b(arg=<is not available>) [/home/parallels/src/vkd3d-git/libs/vkd3d/command.c:358] in libvkd3d-1 (0x000000007c0d28) 2 0x006ffffc739111 call_thread_main+0x11(data=000000000CD22910) [/home/parallels/src/vkd3d-git/include/private/vkd3d_memory.h:52] in libvkd3d-1 (0000000000000000) 3 0x006fffffed1469 in kernel32 (+0x11469) (0000000000000000) 4 0x006ffffff50da3 in ntdll (+0x10da3) (0000000000000000) And I notice this bit is always the same, but with different addresses, and it has some information surrounding RenderCommands.cpp line 366. Backtracing for thread 0124 in process 0120 (C:\Program Files\Hades2\Ship\Hades2.exe): Backtrace: =>0 0x006ffffff50974 in ntdll (+0x10974) (0x0000000010fc88) 1 0x006ffffff79588 in ntdll (+0x39588) (0x0000000010fc88) 2 0x006ffffff74ff4 in ntdll (+0x34ff4) (0x00002995ff5fce) 3 0x006fffffc7138d in kernelbase (+0x6138d) (0x00002995ff5fce) 4 0x000001401fbbf5 Release() [C:\Jenkins\workspace\Iris_PC_Latest\Code\The-Forge\Common_3\OS\Windows\WindowsThread.cpp:67] in hades2 (0x00002995ff5fce) 5 0x000001401fbbf5 sgg::RenderCommands::WaitCanWrite+0x45(msTimeout=<register EBX not accessible in this frame>) [C:\Jenkins\workspace\Iris_PC_Latest\Code\Engine.Native\Code\Rendering\RenderCommands.cpp:366] in hades2 (0x00002995ff5fce) 6 0x00000140062ae9 sgg::App::UpdateAndDraw+0x169(this=<register RBX not accessible in this frame>, elapsedSeconds=*** Invalid address 0x00002995ff5fce *** ) [C:\Jenkins\workspace\Iris_PC_Latest\Code\Engine.Native\Code\App.cpp:649] in hades2 (0x00002995ff5fce) 7 0x00000140302b49 in hades2 (+0x302b49) (0x00002995ff5fce) 8 0x0000014001b9c3 WindowsMain+0x3c3(app=*** Invalid address 0x00002995ff5fce *** Internal symbol error: unable to access memory location 0000002995FF5FCE) [C:\Jenkins\workspace\Iris_PC_Latest\Code\The-Forge\Common_3\OS\Windows\WindowsBase.cpp:1210] in hades2 (0x00002995ff5fce) 9 0x0000014030109b in hades2 (+0x30109b) (0000000000000000) 10 0x00000140312595 main+0x45(argc=<register ESI not accessible in this frame>, argv=<register RDI not accessible in this frame>) [C:\Jenkins\workspace\Iris_PC_Latest\Code\Game.Native\main.cpp:17] in hades2 (0000000000000000) 11 0x0000014038e5e0 invoke_main+0x22() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78] in hades2 (0000000000000000) 12 0x0000014038e5e0 __scrt_common_main_seh+0x10c() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288] in hades2 (0000000000000000) 13 0x006fffffed1469 in kernel32 (+0x11469) (0000000000000000) 14 0x006ffffff50da3 in ntdll (+0x10da3) (0000000000000000) -- 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 #31 from Henri Verbeet <hverbeet@gmail.com> --- I'm afraid this is looking more and more like a MoltenVK issue, but for what it's worth: (In reply to Tony Fabris from comment #30)
Attaching another backtrace during a hang. Comparing it to previous ones, I see a lot of commonalities, but I don't know if they're significant. For example, this bit is always the same, but it sometimes has zero instead of "7c0d28" in the addresses below:
Backtracing for thread 0178 in process 0120 (C:\Program Files\Hades2\Ship\Hades2.exe): Backtrace: =>0 0x006ffffb3d9103 in winevulkan (+0x19103) (0x000000007c0d28) 1 0x006ffffc71ddcb vkd3d_fence_worker_main+0x17b(arg=<is not available>) [/home/parallels/src/vkd3d-git/libs/vkd3d/command.c:358] in libvkd3d-1 (0x000000007c0d28) 2 0x006ffffc739111 call_thread_main+0x11(data=000000000CD22910) [/home/parallels/src/vkd3d-git/include/private/vkd3d_memory.h:52] in libvkd3d-1 (0000000000000000) 3 0x006fffffed1469 in kernel32 (+0x11469) (0000000000000000) 4 0x006ffffff50da3 in ntdll (+0x10da3) (0000000000000000)
The vkd3d_fence_worker_main() thread is a vkd3d worker thread for notifying d3d12 fences. The backtrace suggests it's waiting for a fence to finish, which in principle would be a normal state for that thread to be in.
And I notice this bit is always the same, but with different addresses, and it has some information surrounding RenderCommands.cpp line 366.
Backtracing for thread 0124 in process 0120 (C:\Program Files\Hades2\Ship\Hades2.exe): Backtrace: =>0 0x006ffffff50974 in ntdll (+0x10974) (0x0000000010fc88) 1 0x006ffffff79588 in ntdll (+0x39588) (0x0000000010fc88) 2 0x006ffffff74ff4 in ntdll (+0x34ff4) (0x00002995ff5fce) 3 0x006fffffc7138d in kernelbase (+0x6138d) (0x00002995ff5fce) 4 0x000001401fbbf5 Release() [C:\Jenkins\workspace\Iris_PC_Latest\Code\The- Forge\Common_3\OS\Windows\WindowsThread.cpp:67] in hades2 (0x00002995ff5fce) 5 0x000001401fbbf5 sgg::RenderCommands::WaitCanWrite+0x45(msTimeout=<register EBX not accessible in this frame>) [C:\Jenkins\workspace\Iris_PC_Latest\Code\Engine. Native\Code\Rendering\RenderCommands.cpp:366] in hades2 (0x00002995ff5fce) 6 0x00000140062ae9 sgg::App::UpdateAndDraw+0x169(this=<register RBX not accessible in this frame>, elapsedSeconds=*** Invalid address 0x00002995ff5fce *** ) [C:\Jenkins\workspace\Iris_PC_Latest\Code\Engine.Native\Code\App.cpp:649] in hades2 (0x00002995ff5fce) 7 0x00000140302b49 in hades2 (+0x302b49) (0x00002995ff5fce) 8 0x0000014001b9c3 WindowsMain+0x3c3(app=*** Invalid address 0x00002995ff5fce *** Internal symbol error: unable to access memory location 0000002995FF5FCE) [C:\Jenkins\workspace\Iris_PC_Latest\Code\The- Forge\Common_3\OS\Windows\WindowsBase.cpp:1210] in hades2 (0x00002995ff5fce) 9 0x0000014030109b in hades2 (+0x30109b) (0000000000000000) 10 0x00000140312595 main+0x45(argc=<register ESI not accessible in this frame>, argv=<register RDI not accessible in this frame>) [C:\Jenkins\workspace\Iris_PC_Latest\Code\Game.Native\main.cpp:17] in hades2 (0000000000000000) 11 0x0000014038e5e0 invoke_main+0x22() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78] in hades2 (0000000000000000) 12 0x0000014038e5e0 __scrt_common_main_seh+0x10c() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288] in hades2 (0000000000000000) 13 0x006fffffed1469 in kernel32 (+0x11469) (0000000000000000) 14 0x006ffffff50da3 in ntdll (+0x10da3) (0000000000000000)
That looks like an application thread waiting to be able to render more frames. It's consistent with the application hanging, but probably not the cause. The lack of debug symbols for CrossOver's Wine makes things a bit harder, but this backtrace (a similar ones in the other logs) is consistent with the MVKPresentableSwapchainImage::presentCAMetalDrawable() related crash from earlier: Backtracing for thread 0178 in process 0120 (C:\Program Files\Hades2\Ship\Hades2.exe): Backtrace: =>0 0x006ffffb3d8f7b in winevulkan (+0x18f7b) (0x0000000b7a6d20) 1 0x006ffffd4aa041 in dxgi (+0xa041) (0x0000000b7a6d20) 2 0x006ffffd4aa908 in dxgi (+0xa908) (0x006ffffff6c400) 3 0x006fffffed1469 in kernel32 (+0x11469) (0000000000000000) 4 0x006ffffff50da3 in ntdll (+0x10da3) (0000000000000000) If you were able to get WINEDEBUG=+dxgi to work you may be able to confirm this, but I'd expect the call stack here to look something like this: (Some of these functions may have gotten inlined.) winevulkan.vkWaitForFences() dxgi.d3d12_swapchain_acquire_next_vulkan_image() dxgi.d3d12_swapchain_queue_present() dxgi.d3d12_swapchain_op_present_execute() dxgi.d3d12_swapchain_worker_proc() I.e., I suspect the dxgi d3d12_swapchain_worker_proc() thread is waiting for the next swapchain image the become available, which never happens because that Metal thread crashed. (There are potentially a couple of other places where d3d12_swapchain_worker_proc() could hang in a similar way; the basics are the same.) Some of the messages from the first log, like "[CAMetalLayerDrawable texture] should not be called after already presenting this drawable. Get a nextDrawable instead." also seem to point in a similar direction. I think what it comes down to is that at first sight these all look like the same underlying issue manifesting itself in slightly different ways. It's not necessarily clear whether it's the root cause, but I think the thing to figure out is what's happening with MoltenVK's _mtlDrawable/mtlDrwbl. My best guess at this point is that some kind of race causes _mtlDrawable to either be released while it's still in use, or to be released too often. The main path through which that may happen is probably MVKPresentableSwapchainImage::releaseMetalDrawable(). The following is mostly speculation, but here are some ideas: - If two different threads were to call MVKPresentableSwapchainImage::releaseMetalDrawable() and MVKPresentableSwapchainImage::getCAMetalDrawable() at the same time, getCAMetalDrawable() could observe "_mtlDrawable" after the [_mtlDrawable release] from releaseMetalDrawable(), but before the "_mtlDrawable = nil;" assignment. I.e., getCAMetalDrawable() could return a (potentially) already destroyed "_mtlDrawable" to its caller. - Places that call releaseMetalDrawable() aren't hard to find. For example, vkAcquireNextImageKHR() calls MVKSwapchain::acquireNextImage(), which calls MVKPresentableSwapchainImage::acquireAndSignalWhenAvailable(), which calls releaseMetalDrawable(). - getCAMetalDrawable() is of course called from MVKPresentableSwapchainImage::presentCAMetalDrawable(). The interesting part is probably how MVKPresentableSwapchainImage::presentCAMetalDrawable() is called. vkQueuePresentKHR() calls MVKQueue::submit(const VkPresentInfoKHR* pPresentInfo), which eventually calls MVKQueue::submit(MVKQueueSubmission* qSubmit). MVKQueue::submit(MVKQueueSubmission* qSubmit) can then execute "qSubmit" either synchronously as "execute(qSubmit)", or asynchronously using dispatch_async(). (MVKQueuePresentSurfaceSubmission::execute() calls MVKPresentableSwapchainImage::presentCAMetalDrawable().) In the asynchronous case, that would mean MVKPresentableSwapchainImage::releaseMetalDrawable() and MVKPresentableSwapchainImage::getCAMetalDrawable() end up being called from different threads. - I think asynchronous submission is the default. -- 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 #32 from Tony Fabris <tfabris@gmail.com> --- Excellent information and analysis! Thank you! I shall try to figure out how to get MoltenVK to compile so that I can insert a hand-built version into my bottle, like I did for vkd3d. Then I could do some debugging-by-printf or at least get backtraces with symbol tables. Should I be poking the folks over at https://github.com/KhronosGroup/MoltenVK at this point? -- 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 #33 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #32)
I shall try to figure out how to get MoltenVK to compile so that I can insert a hand-built version into my bottle, like I did for vkd3d. Then I could do some debugging-by-printf or at least get backtraces with symbol tables. Should I be poking the folks over at https://github.com/KhronosGroup/MoltenVK at this point?
Well, at this point we mostly have some speculation based on some assumptions. :) It all sounds plausible to me, but that doesn't mean it's true; I don't think it can hurt to ask the MoltenVK people to take a look at this point, but ideally we'd try to confirm some of this stuff first. One of the first things to try may be whether setting MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS=1 [1] makes any difference. The documentation claims that's the default, but there's also a corresponding build-time configuration option; the version of MoltenVK in CrossOver may not have been built with the default options. [1] https://github.com/KhronosGroup/MoltenVK/blob/main/Docs/MoltenVK_Configurati... -- 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 #34 from Tony Fabris <tfabris@gmail.com> --- Okay, I'm currently trying to do an A/B comparison between having one of these two statements in my launcher script, and seeing if it makes a difference in the frequency of the hangs. Note that I'm also temporarily setting the vkd3d debug text level to its lowest setting, so that the hang should be more likely to occur. export VKD3D_DEBUG=none export MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS=1 export VKD3D_DEBUG=none export MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS=0 So far, setting it to "1" (the supposed default) seems (maybe?) like it might be helpful. Setting it to "0" produced a hang in just a minute or two, and I was able to run it for more than 30 minutes without a hang when it was set to "1". But I need to run it for a longer period of time to be certain, since it was quite intermittent to begin with. Here's something interesting I found when comparing the Crossover version of MoltenVK with the version currently on GitHub: File: Docs/Whats_New.md ----------------------- #### MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS ##### Type: Boolean ##### Default: `1` _(The default value is `0` for OS versions prior to macOS 10.14+/iOS 12+)._ My MacOS version is 12.7.6, so this shouldn't apply to me. (Maybe? Unless the version number detection in their code is broken?) It looks like this is where that's implemented in the code: File: MoltenVK/MoltenVK/Utility/MVKEnvironment.h ------------------------------------------------ Github version: #ifndef MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS # define MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS 1 #endif Crossover version: #ifndef MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS # define MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS mvkOSVersionIsAtLeast(MVK_CONFIG_MTLEVENT_MIN_OS) #endif Note that MVK_CONFIG_MTLEVENT_MIN_OS is set to "10.14" in the code. So the only way that this code could apply to me is if there's a bug in the "mvkOSVersionIsAtLeast()" function and my system is erroneously being detected as lower than 10.14. This is only other code difference I see which is related to synchronousQueueSubmits. I don't know if it's relevant to the issue or not: File: MoltenVK/MoltenVK/GPUObjects/MVKQueue.mm ---------------------------------------------- Crossover Version: if ( !getMVKConfig().synchronousQueueSubmits ) { // Determine the dispatch queue priority dispatch_qos_class_t dqQOS = MVK_DISPATCH_QUEUE_QOS_CLASS; GitHub Version: if ( !getMVKConfig().synchronousQueueSubmits ) { dispatch_qos_class_t dqQOS; switch (_globalPriority) { case VK_QUEUE_GLOBAL_PRIORITY_LOW: dqQOS = QOS_CLASS_UTILITY; break; case VK_QUEUE_GLOBAL_PRIORITY_HIGH: dqQOS = QOS_CLASS_USER_INTERACTIVE; break; case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM: default: // Fall back to default (medium) dqQOS = QOS_CLASS_USER_INITIATED; break; } Anyway, I'm going to do more A/B testing of that environment variable and see if I can get a definitive answer as to whether it helped. -- 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 #35 from Tony Fabris <tfabris@gmail.com> --- Henri, thanks again for your excellent sleuthing and suggestions. Zeroing in on that variable was a stroke of genius. As I promised in my prior comment, I've done more testing (aka, playing the game a bunch) and I'm pretty confident about this now: Hang bug no longer repros after hours of play: export MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS=1 Hang bug repros at the same frequency as before: export MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS=0 And since, before I knew about that variable, the hang bug repro'd without that variable being set at all, I wonder if that means (as I discussed in my prior comment) that the value is defaulting to 0 on my system, even though my system is higher than version 10.14, so it should have defaulted to 1? Of course, the version of MoltenVK that's having the issue is the one that came with Crossover 26.0, which (I think?) differs significantly from the one on GitHub, at least with regard to the handling of the synchronous queue submits. I suspect that, in the Crossover version, the function "mvkOSVersionIsAtLeast()" is the thing that's doing me dirty here. I don't think it's the fault of the folks at https://github.com/KhronosGroup/MoltenVK in this case, because their version on GitHub just hard-codes that variable's default value to 1 without any version check. Henri, do you have any way of confirming that stuff above and in my prior comment? For instance, do you have access to the internal git system at CodeWeavers, so you can Git Blame to find out who's responsible for that version check in the Crossover build, and ask them about this? -- 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 #36 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #35)
And since, before I knew about that variable, the hang bug repro'd without that variable being set at all, I wonder if that means (as I discussed in my prior comment) that the value is defaulting to 0 on my system, even though my system is higher than version 10.14, so it should have defaulted to 1?
Not necessarily. The CrossOver sources unfortunately don't contain the scripts used to control MoltenVK compilation, but the defaults for configuration variables like MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS can be changed at build time. I.e., building MoltenVK with $ make MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS=0 would make it default to 0.
I don't think it's the fault of the folks at https://github.com/KhronosGroup/MoltenVK in this case, because their version on GitHub just hard-codes that variable's default value to 1 without any version check.
From a quick look at the upstream MoltenVK sources, I think it has the same synchronisation issue, even though it may require setting MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS=0 to trigger it.
-- 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 #37 from Tony Fabris <tfabris@gmail.com> --- Henri, thanks so much for those insights. Okay, so who do I report the bug to, then? :-) It's a philosophical question at this point: Is the bug the handling of the MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS flag, or the actual queue submit code itself? I'm going to think out loud here, tell me if any of this sounds wrong: Crossover version of MoltenVK: The Crossover code intentionally changes the value of that flag, depending on the system version, with older systems setting it to 0, thus inducing the bug. Observed repro behavior suggests that it might be getting the version check wrong, which is why it's inducing the bug on my system when I don't think it should be. Mainline version of MoltenVK: Intentionally leaves the default value of that flag at 1, with no system version check. Unless you go out of your way to compile it with a special command or set the flag by hand at runtime. Both versions: There's a bug in asynchronous queue submits, which induces the hang. Definitely exists in Crossover version, but not yet certain it exists in mainline MoltenVK, because I've only been able to run the Crossover version. So, reiterating the philosophical question another way: If the bug only repros in mainline MoltenVK when the user changes that flag, then is that even a bug, or is it just user error? I think that, if the Crossover version really changes the flag to 0 on my 12.7.6 system, then that's definitely a bug in Crossover, since the code clearly intends it to be set to 0 only on systems 10.14 and lower. My current status is: I can reproduce the bug with a pure/original version of Crossover (no VKD3D substitution). I can reliably cure the bug by setting the flag to 1 at runtime. I can reliably reproduce the bug by not setting the flag at all, or by setting it to 0. I want be certain that the unmodified flag is getting set to 0 at runtime, and if it's happening because the version checker in the Crossover version is malfunctioning. I think the only way to be sure of this would be to attach a debugger and find the value of the flag, and if it's coming out as 0, then step through the "mvkOSVersionIsAtLeast" function in the debugger to find out for sure if it's responsible. But I've got no idea how to even begin doing that level of debugging in my current setup. I haven't tried to compile the mainline MoltenVK code. It took me quite a long time (and tons of help from you) to be able to compile VKD3D at all, and I'm not sure I'm ready to begin that same process for MoltenVK. Because you gave me a simple and perfect one-line workaround (just force the flag to 1 with a console command), the whole thing has become entirely academic to me now. I'm sure that the folks working on Crossover and/or MoltenVK would love to have the exact bug found and reported, and so that would be my incentive to keep digging. But for me personally, the bug is solidly fixed by that one-liner, and so I no longer actually need anything else. Still, I want to help if I can, and I want to know who report the bug to, if possible. Thanks again! -- 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 #38 from Tony Fabris <tfabris@gmail.com> --- AHA! Updated information: I'm able to look at the Git Blame for the mainline MoltenVK since that's up on GitHub. I can't see Crossover version's Git Blame, since I don't have access to their internal git system. But it turns out I don't need to, the answer is in the mainline MoltenVK on GitHub. The fix to MVKEnvironment.h to hard-code MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS to "1" without a version check, was made 5 months ago (Oct 4 2025) by Squidbus. It was part of a project to clean up the code after they dropped support for MacOS 10.14 and lower. This is the commit which fixes the bug: https://github.com/KhronosGroup/MoltenVK/commit/3675d87f942e48498ba9bb0b2dc9... Prior to that commit, it did a system version check which set the value to 0 on older systems. I can't be sure that version check ever worked correctly or not, but it doesn't matter, because that version check is only getting called in an outdated version of Molten VK. So this bug is occurring because the version of MoltenVK that's shipping with Crossover 26.0 is older than than Squidbus' October 2025 commit. As long as future releases of Crossover will include more current versions of MoltenVK, then the bug won't occur on future versions, and I don't have to report anything to anyone! So: Bug is already fixed, I have your one-liner workaround, and I think we can close this thread. What do you think? Henri, thanks again for all your help with this. -- 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 #39 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Tony Fabris from comment #37)
Okay, so who do I report the bug to, then? :-)
It's a philosophical question at this point: Is the bug the handling of the MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS flag, or the actual queue submit code itself?
If it's indeed the issue we think it is, this would be something to report to upstream MoltenVK. The CrossOver build may make the issue easier to encounter, but it exists in upstream MoltenVK as well.
So, reiterating the philosophical question another way: If the bug only repros in mainline MoltenVK when the user changes that flag, then is that even a bug, or is it just user error?
I think that's still a bug. It may not be a very important one if the position of upstream MoltenVK is that synchronous submission is always preferable on current versions of macOS, but in that case it could also be argued that the right thing to do is to simply remove the asynchronous submission code because it's broken.
I haven't tried to compile the mainline MoltenVK code. It took me quite a long time (and tons of help from you) to be able to compile VKD3D at all, and I'm not sure I'm ready to begin that same process for MoltenVK.
Because you gave me a simple and perfect one-line workaround (just force the flag to 1 with a console command), the whole thing has become entirely academic to me now. I'm sure that the folks working on Crossover and/or MoltenVK would love to have the exact bug found and reported, and so that would be my incentive to keep digging. But for me personally, the bug is solidly fixed by that one-liner, and so I no longer actually need anything else. Still, I want to help if I can, and I want to know who report the bug to, if possible.
I can probably write a MoltenVK patch for you to test, but that would still require you to build MoltenVK yourself. I could instead try to make a MoltenVK build for you to test, but the only macOS setup I have available for that purpose is a few versions newer than yours; it may not work. -- 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 #40 from Tony Fabris <tfabris@gmail.com> --- I think that the thing I found (described in my most recent comment) means that the MoltenVK team doesn't intend for asynchronous queue submits to happen at all. I think that feature was only ever intended for older versions of the OS that, now, are completely deprecated. So I don't think there's a remaining bug to investigate any more, i.e., it's already fixed in the main MoltenVK source code. -- 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 Henri Verbeet <hverbeet@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED --- Comment #41 from Henri Verbeet <hverbeet@gmail.com> --- Resolving; not a vkd3d issue. -- 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 Henri Verbeet <hverbeet@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #42 from Henri Verbeet <hverbeet@gmail.com> --- And closing. -- 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