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.