https://bugs.winehq.org/show_bug.cgi?id=47767
--- Comment #3 from Paul Gofman gofmanp@gmail.com --- (In reply to iodreamify from comment #2)
... so I'd just like to ask, is there any chance of a proper fix within Wine or is this solely the game's fault? Should this be closed? Thanks.
This looks like a valid bug, I am not aware of any reason to close it yet and I hope this will be fixed sooner or later.
Besides, while this game exhibits some ultimate case, that spin locking around CS thread in wined3d can affect performance in much more applications. Probably in any case when the game performance is CPU bound. Even if the game is not using all the available cores while being CPU bound, and we can have a core absolutely free to spin in CS thread, it is still harmful for performance for the following reasons: - spinning in lock involves memory access and memory fences (implicit on x86, but they are still there), which slows down the memory access for other cores or CPUs; - a common practice on today's desktop CPUs is to utilize heavy overclocking on the busy core(s). But this is not symmetric, in often can't overclock all the cores at the same time, or maybe it can for some time, but in any case will have to throttle CPU clock back as heat goes up.
I think similar issue came up before, but there is probably no good and quick solution. I think just always using mutex (or similar) instead of going for long spin locks would be better. But as far as I understand it is currently a no go to use native host sync primitives in Wine DLLs (for various reasons). Using the Windows API ones is a no go too as currently all blocking waits end up in wineserver calls and it is worse for a general case (with this game being an exception).