http://bugs.winehq.org/show_bug.cgi?id=59027
--- Comment #3 from FoX virtuousfox@gmail.com --- (In reply to Zeb Figura from comment #2)
This doesn't make any sense. Sync methods don't, by themselves, "try to get all cores". Applications might, but that shouldn't make ntsync worse.
This is what doesn't make sense. No matter the application, all cores are always used in background, judging by core utilization graph in gkrellm. I doubt that every single Windows game has something explicitly coded to scale only synchronization on all cores but nothing else.
I also can't reproduce these results. I have a fairly high-powered computer, and with ntsync I reach even the highest FPS limit available (288 FPS). But without ntsync, performance gets worse, and if I limit it to 2 cores with taskset, performance gets worse still. That's more or less what I'd expect.
Good for you but I've never seen such magic. And I did say that performance is worse without ntsync. It's just still bad with it (proton is outlier in this). But I'm 90% sure performance in wine-staging was decent with original ntsync merge request. 10% chance is that I misremembering due to it still being way better than complete slideshow without ntsync and core-limiting.
Make no mistake, at some scenes some games also can reach high fps for me. But when they are affected by this, it tanks hard. It took me few levels to reach one where Freedom Planet 2 is comically slow.
Can you please test with unmodified upstream non-staging wine, in a fresh prefix, without any external components including dxvk?
Did that but had to at least switch to vulkan renderer, as using default opengl one hanged whole wine when I tried loading GALLIUM_HUD (which is opengl-only), so much that I had to use `wineboot -k -f -e` to make wine unstuck. With vanilla wine's native vulkan renderer performance is almost exactly the same as wine-staging with dxvk but way more stuttery. Same core load distribution too.