http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #10 from Claudiu Curca Alexstrasza2@gmail.com 2009-01-06 07:44:54 --- (In reply to comment #7)
(In reply to comment #6)
This suggests that the problem may be the way in which threading is implemented in World of Warcraft, but to study this is kinda out of my reach.
Either that it could be that either WoW decides not to schedule as much work as it does on Windows
I don't know if it'll be useful, but maybe something can be spotted if you add traces to dlls/kernel32/thread.c for some of the functions which don't have traces (CreateThread, SuspendThread, ResumeThread, SetThreadPriority, SetThreadPriorityBoost, SetThreadAffinityMask, SetThreadIdealProcessor) which print the function parameters using the TRACE macro then attach a +thread,+tid log here.
I've followed your advice and dug a bit deeper. Unfortunately, I found out a sad thing.
By the looks of it, World of Warcraft does NOT use multiple threads for rendering or analysis during gameplay. I started the game, entered the world and played for a few minutes.
As you can see from the snippet of the status of the threads yielded by "ps alm", only ONE thread has been using CPU time (the one with 5:29). The rest are clearly there, but they are not used for extensive operation.
But then why does it work on Windows? I think i can answer that too.
By looking at the snippet of the wine log you can see that there's one specific thread that's being thrown from one CPU to the other (using the SetThreadAffinityMask function). On windows this might cause the "illusion" that 2 threads are actually using one core each. I might be wrong, but I don't know how else to demonstrate the windows behavior.
I will try to install wine on a windows machine (if i can get one) and see if the behavior is the same. Maybe it can shed a bit more light on the subject.