Serious Sam 3: BFE
avi9526 Mar 8, 2013 @ 11:52am
Serious Sam 3 use only one CPU
I am running Serious Sam 3 on linux (Ubuntu 12.10).
The problem is that Sam3 uses only one of my 4 CPU's all the time - CPU0.
It won't switch to others CPU's. Using Sam3 process PID and command "taskset" I found that
taskset -p 7160
pid 7160's current affinity mask: 1
Seems, that CPU-affinity set to only one CPU0. Why that was done?

Russian:
Я запускаю Serious Sam 3 на linux (Ubuntu 12.10).
Проблема в том, что Sam3 всё время использует только одно и то же ядро (CPU0). С помощью комманды taskset обнаружил что
taskset -p 7160
pid 7160's current affinity mask: 1
пролучается что игра привязана только к одному ядру. Вопрос: нафига?
< >
Showing 1-9 of 9 comments
kwahoo Mar 8, 2013 @ 1:27pm 
ren_bMultiThreadedRendering=1
ren_iMaxThreads=3

http://steamcommunity.com/app/41070/discussions/0/846945579812847461/
avi9526 Mar 8, 2013 @ 2:59pm 
Thnx for response. I know about this commands. But the problem still appear (of course less). Let me explain it more detailed to make it clear:

Normally if some program use only one CPU, its switch by OS to another CPU after some time, so every CPU used and CPU chip heated evenly.

Sam3 use one core CPU0 and don't want switch to another CPU. It's cause that core CPU0 is working all time at ~80..100% load while other CPU's (In my case CPU1..CPU3) is low-loaded at ~10..30%.

Even if I enable multicore rendering - Sam3 use one and same core CPU0. Because OS parameter called CPU-affinity set to 0x0001, while for other processes its 0x000F

Command
mpstat 1 300 -P ALL
give CPU usage after 300 seconds of monitoring:

CPU %idle
all 50.13
0 17.59
1 55.94
2 63.19
3 64.48

As You can see, most of all CPU's in this 300 seconds works CPU0 (less idle percentage).


To make Sam3 use all cores evenly I need call command
taskset -p f $PID
where $PID - ID of Sam3 process; f - hexadecimal number 15.

After doing that (even with mutlicore rendering disabled) I get

CPU %idle
all 59.78
0 54.28
1 63.33
2 66.84
3 54.52

Now, as You can see, all CPU loaded more evenly.

Of course, seems there was some performance decrease (feel like lost ~5 FPS)

So, I interested why this was done? And is there a way to make it permanent?
kwahoo Mar 8, 2013 @ 6:03pm 
That's intended behavior introduced during Linux beta testing. It resolves performance problems when CnQ is enabled. There are threads (low fps, shuttering, etc.) in the Linux Steam section...

You have a question:
Originally posted by avi9526:
So, I interested why this was done?

And you have an answer:
Originally posted by avi9526:
Of course, seems there was some performance decrease (feel like lost ~5 FPS)

Check also fps graph to see difference:
prf_bShowFPSGraph=1

Finally - If you have an i5 or i7 CPU check (using i7z[code.google.com]) how turbo mode works in both cases.
Last edited by kwahoo; Mar 8, 2013 @ 6:12pm
AlenL Mar 9, 2013 @ 8:35pm 
avi, can you please post your Sam3.log file?
avi9526 Mar 9, 2013 @ 10:36pm 
Sam3.log http://pastebin.com/LS42sAre

I am using next command to change CPU-affinity mask to 'F':
taskset -p F $(ps ax | awk '/Sam3$/ {print($1)}')

There is screenshot of CPU-load graph with moment of changing affinity mask to F at middle of graph: http://itmages.ru/image/view/932165/d41d8cd9

Next screenshots shows FPS graph when changing CPU-affinity:
switch CPU-affinity mask from 1 to F - http://itmages.ru/image/view/932148/d41d8cd9
switch CPU-affinity mask from F to 1 - http://itmages.ru/image/view/932147/d41d8cd9

Anyway, even assuming FPS drop, am I able to make this CPU-affinity mask permanent for my gameplay?
AlenL Mar 10, 2013 @ 6:08am 
I think that what you are seeing is not affinity mask for the entire process. The process uses several threads and automatically adapts to presence of multiple CPUs, by creating one worker thread per CPU. This approach works well on Windows and OSX, but on Linux, there are some issues when power saving on the CPU is enabled. See this line in your log:

07:51:00 WRN: CPU Power saving is enabled and performance governor is not used.

We have determined through testing that the "ondemand" governor (which is default, and which you have) seems to have some bugs and causes the erratic behavior that you see on your FPS graph. It appears as if the governor and scheduler interact in a weird way so that governor downclocks less used cores, but then the scheduler moves the main thread to that underclocked core, which the governor then clocks back, etc ad nauseam. We have contacted kernel devs, most notably developers from Intel that are working on that area, but they seem to still be looking into this.

The only workaround that we can come up from application side was to set strict affinity for each thread.

Ultimately, it is best if you switch to using the "performance" governor.

If you want to have the game not lock to threads, then set this cvar:

thr_iAffinityStrictness=0

Note that if you do that without performance governor, you will loose a few FPS as noted above.
avi9526 Mar 10, 2013 @ 1:29pm 
Thanks for support.

But seems that this doen't work http://pastebin.com/dmm7Up5D
I changed that cvar and restarted a game. thr_iAffinityStrictness still equal to 0 but command
taskset -p $(ps ax | awk '/Sam3$/ {print($1)}')
gives
pid 5119's current affinity mask: 1
AlenL Mar 11, 2013 @ 6:08am 
Well, if that is so, then it is not our doing. I don't know why that would happen.
AlenL Mar 11, 2013 @ 7:02am 
Oops, correction. We've found a bug that can cause such behavior. We'll have a fix in the next update.

Nevertheless, if you are going to be using this, then you should definitely switch to using the performance governor.
< >
Showing 1-9 of 9 comments
Per page: 1530 50

Date Posted: Mar 8, 2013 @ 11:52am
Posts: 9