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.