Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
ren_iMaxThreads=3
http://steamcommunity.com/app/41070/discussions/0/846945579812847461/
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?
You have a question:
And you have an answer:
Check also fps graph to see difference:
Finally - If you have an i5 or i7 CPU check (using i7z[code.google.com]) how turbo mode works in both cases.
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?
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.
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
Nevertheless, if you are going to be using this, then you should definitely switch to using the performance governor.