http://bugs.winehq.org/show_bug.cgi?id=59027 --- Comment #7 from FoX <virtuousfox@gmail.com> --- I've figured out the cause for "the regression": between wine version 10.10, the last compatible with original patch, and 10.16, with rebased incorporated version, I seem to have switched to building kernel with CONFIG_PREEMPT_RT but wine's sync is EXTREMELY sensitive to scheduling and really-really-really hates RT kernel. I've switched back and got the original numbers when running wine-staging plainly. RT kernel is also incompatible with CONFIG_TRANSPARENT_HUGEPAGE but using CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS (along with big zswap on fast NVMe) generally helps to further reduce stuttering in all multimedia/gaming apps. Even though theory suggests that RT kernel should do so better instead. So, it's not a regression but wine sync's original bottleneck that makes it heavily under-utilize CPU & GPU in CPU-bound cases (like 2D games). Because weird core load & fps drop pattern still persists in all cases, under all settings of all kernel schedulers and wine's sync variants. I even tried out alternative userspace/BPF schedulers in https://github.com/sched-ext/scx but they are all worse than kernel's own EEVDF. SCX's scx_cosmos is kind of close but still noticeably behind. Also, limiting FP2 to 2 cores and using RT (via chrt) is still required to get 20-50% boost but even then fps never exceeds 120-140 without any limiter and vsync. All due to this scheduling bottleneck. There is always constant stuttering every 3-10 seconds, spoiling frame's max delay from good 11-15 ms into 22-30 ms, making 100-140 fps "on paper" feel like 41 fps in practice but this might be due to app's own stupidity.
What I'm trying to say is there's no such thing as a "sync thread". Synchronization is the tool you use to deal with multiple threads. Synchronization primitives don't by themselves do work, or spawn threads.
You say that but there are some kind of threads that spawn when an app is active under wine and they always go unto all CPU's hardware threads unless limited with taskset. But I haven't managed to find out their names and parent process. Those could be kernel's internal threads of some kind that spawn transparently on some particular syscall. But it's weird that they can be limited by taskset to wine. With non-NTSync sync methods those threads eat up ridiculous amounts of CPU-time and even with it, it's more than the game itself. At least for FP2. At first I thought that under-utilization in FP2 and Dishonored 2 both stem from wine's sync. But I've also figured out that D2 can be forced to properly use all resources (doubling fps in autoscaled 4K while maxing out GPU-load) by tweaking settings related to GPU-sync in dxvk: d3d11.maxImplicitDiscardSize = 16384 d3d11.maxDynamicImageBufferSize = 2048 d3d11.cachedDynamicResources = "ci" dxvk.numCompilerThreads = 16 dxvk.enableMemoryDefrag = True I don't have Windows to check if FP2 is acting weird there too, so not sure if that's entirely wine's fault either or if it's bound by flawed internal logic. -- 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.