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.