[Bug 20602] New: thread/cpu affinity not correct with multi core enabled source engine games
http://bugs.winehq.org/show_bug.cgi?id=20602
Summary: thread/cpu affinity not correct with multi core enabled source engine games Product: Wine Version: 1.1.32 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: fzielcke@z-51.de
This is actually with current git HEAD de00535c13fba643c9c2bc178225be3cecafd92d not the 1.1.32 release.
Even if I enable the Multi Core support in Day of Defeat:Source or Team Fortress 2, the cpu mask is set to one CPU. I checked /proc/($pgrep hl2.exe)/status and also run both in a window with top running in the background and visible P column (last used CPU).
wine taskmgr shows an affinity of both CPUs. If I uncheck one and check one again then the main 2 threads needing CPU time run on both my cores.
This is a huge increase in performance for me. For example in ctf_2fort on a well visited server I get only ~10-20 FPS on the bridge if there's fighting and the hl2 process is locked on 1 core. Whereas if they run on both, it's good playable and I think it's somewhat around ~40 FPS.
It also works fine if I compile wineserver without HAVE_SCHED_SETAFFINITY I tried mat_queue_mode 2, too. mat_queue_mode -1 seems to be the default for multicore enabled.
So even if TF2/DoD:S have a bug to still force a CPU affinity of 1, wine taskmgr should at least display it correctly.
I use Debian sid + experimental. For compilation I use Debian 4.4.2-2 with CFLAGS="-march=native -pipe -O2"
Hardware is Athlon64 X2 4600+, 2 GiB RAM and a Geforce GTS 250 with the 190.42 Nvidia proprietary drivers.
http://bugs.winehq.org/show_bug.cgi?id=20602
Luke Bratch l_bratch@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #1 from Luke Bratch l_bratch@yahoo.co.uk 2009-11-07 10:00:26 --- I can confirm that I see the same thing. With multicore rendering enabled, only one CPU core is utilised by a hl2.exe thread. Unchecking, then rechecking one CPU box in wine taskmgr causes two hl2.exe threads to utilise a CPU core. At the lowest framerate part of a given map, this increases the FPS from around 70 FPS to 110 FPS.
http://bugs.winehq.org/show_bug.cgi?id=20602
Patrick McFarland diablod3@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |diablod3@gmail.com
--- Comment #2 from Patrick McFarland diablod3@gmail.com 2009-11-09 06:50:58 --- I'd also like to mention that schedtool confirms the game is not running multithreaded and is bound to the 2nd of 2 cores on my machine.
Not only that, forcing it to not be affined fixes the sound skip bug while, for example, updating the server list.
http://bugs.winehq.org/show_bug.cgi?id=20602
msn@gaiatools.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |msn@gaiatools.com
http://bugs.winehq.org/show_bug.cgi?id=20602
Artem Semendyaev lifeissecret@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #3 from Artem Semendyaev lifeissecret@gmail.com 2009-11-11 02:25:39 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=20602
Artem Semendyaev lifeissecret@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lifeissecret@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20602
Gianfranco Liporace gliporace@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gliporace@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #4 from Henri Verbeet hverbeet@gmail.com 2009-11-13 08:57:48 --- Is this a regression? If so, could you do a regression test? There were some affinity related patches in 1.1.31.
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #5 from Felix Zielcke fzielcke@z-51.de 2009-11-13 13:17:53 --- (In reply to comment #4)
Is this a regression? If so, could you do a regression test? There were some affinity related patches in 1.1.31.
Thanks somehow I missed/forgot them. The performance for TF2 wasn't always that great for me since I started to play it with wine. I think some 1.1.2x release. So lately I haven't followed much the changes affecting TF2
Anyway, it's not surprising that the last commit with affinity in the commit message causes this behaviour:
commit 474b2e4bfb46cf1bb8db0faa6ecfdb3fd157b117 Author: Juan Lang juan.lang@gmail.com Date: Tue Sep 29 09:17:30 2009 -0700
server: Use kernel support for thread affinity when available.
Then I tried the 1.1.30 release with above commit and the 2 main threads still run on both cores. So the real problem is some of the other commits. I do more testing later. I hope I didn't screw up anything. I think it would be just good if someone else could confirm my testing.
http://bugs.winehq.org/show_bug.cgi?id=20602
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #6 from Henri Verbeet hverbeet@gmail.com 2009-11-13 13:32:58 --- I'm not sure if Juan reads wine-bugs or not, but I added him to CC. The reason that commit comes up is probably just because it adds support for setting thread affinity, which wasn't there before.
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #7 from Juan Lang juan_lang@yahoo.com 2009-11-13 13:42:25 --- That patch should probably be reverted. It was an attempt to fix bug 19982, but it does not: Wine uses the posix API to create threads, and it should use the posix API to set the affinity too.
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2009-11-13 15:21:10 --- (In reply to comment #7)
That patch should probably be reverted. It was an attempt to fix bug 19982, but it does not: Wine uses the posix API to create threads, and it should use the posix API to set the affinity too.
No, the Posix API only works inside the process, from the wineserver using the syscall is correct. There must be some other problem here.
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2009-11-13 15:45:32 --- (In reply to comment #8)
No, the Posix API only works inside the process, from the wineserver using the syscall is correct. There must be some other problem here.
Indeed, yet when the wineserver makes the syscall, it only appears to take effect on the main thread, not on other threads. I agree that there must be some other problem, and I only surmised that the Posix API was interfering with it. C.f. the man page of sched_setaffinity: "If you are using the POSIX threads API, then use pthread_setaffinity_np(3) instead of sched_setaffinity()." That was just a guess, but it's clearly not working the way we're doing it now (except for the main thread.)
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2009-11-13 16:03:52 --- (In reply to comment #9)
(In reply to comment #8)
No, the Posix API only works inside the process, from the wineserver using the syscall is correct. There must be some other problem here.
Indeed, yet when the wineserver makes the syscall, it only appears to take effect on the main thread, not on other threads. I agree that there must be some other problem, and I only surmised that the Posix API was interfering with it. C.f. the man page of sched_setaffinity: "If you are using the POSIX threads API, then use pthread_setaffinity_np(3) instead of sched_setaffinity()." That was just a guess, but it's clearly not working the way we're doing it now (except for the main thread.)
That's because your patch uses unix_pid instead of unix_tid.
http://bugs.winehq.org/show_bug.cgi?id=20602
Felix Zielcke fzielcke@z-51.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #11 from Felix Zielcke fzielcke@z-51.de 2009-11-20 11:13:51 --- (In reply to comment #10)
That's because your patch uses unix_pid instead of unix_tid.
Thanks Alexendra for fixing my bug. This time I payed attention to the commits and this fixes it:
commit a764fe89212500b0ffa23fa9a9f699db89fd7d59 Author: Alexandre Julliard julliard@winehq.org Date: Fri Nov 20 11:44:54 2009 +0100
server: Use the correct thread id to set affinity.
http://bugs.winehq.org/show_bug.cgi?id=20602
--- Comment #12 from Felix Zielcke fzielcke@z-51.de 2009-11-20 11:14:56 --- (In reply to comment #11)
(In reply to comment #10)
That's because your patch uses unix_pid instead of unix_tid.
Thanks Alexendra for fixing my bug.
Args AlexendrE of course :(
http://bugs.winehq.org/show_bug.cgi?id=20602
ray@pobox.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ray@pobox.co.uk
--- Comment #13 from ray@pobox.co.uk 2009-11-23 11:55:42 --- (In reply to comment #12) These patches look like they have also fixed http://bugs.winehq.org/show_bug.cgi?id=19982
http://bugs.winehq.org/show_bug.cgi?id=20602
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org 2009-12-04 12:16:24 --- Closing bugs fixed in 1.1.34.
-
wine-bugs＠winehq.org