[Posila] [0.16.41] Melting CPU while in Mainmenu (constant 55%)

[Tami]

Factorio is melting the CPU while in mainmenu (and playing).

https://youtu.be/LZwjNUuLjCA

Running huge map:
https://youtu.be/CKJbDTucHCQ
CPU usage goes low while running this map

Running multiple games:
https://youtu.be/xeBRrhmEoOI

Running older Version of Factorio, everything seems fine:

[quyxkh]

Might be a windows-only thing, I get 10% in the menu and 50% in my current medium-sized base.

[Loewchen]

You can prevent that by activating VSync.

[Tami]

you are right, was there a change lately that turned off VSync?
For example in 15.x Version everything is fine, i for myself havent played in the options lately. Is there a hotkey that switch VSync in the game that i may have smashed?

[Zavian]

If I recall correctly, the game reset some?/all? graphics options when I upgraded from 0.15-0.16. So if you have only recently upgraded that would explain vsync being off. But since the game is limited to 60ups/60fps, I was surprised at how much cpu factorio was using in your video, so I tried the same experiment with 0.16.36 on my i7, on win 10.

After reaching the menu screen factorio drops to 0.5% cpu on the main menu (it seems to take a few seconds before it drops, but that might just be windows task manager averaging over multiple adjacent update cycles). After starting a new game, cpu use stabilizes at about 2.5% (again it takes a few seconds before it drops to 2-3%, it might be that map chunk generation takes a few seconds after the player spawns, or it might just be windows task manager).

0.16.36 Windowed mode, normal sprite quality, Vsync off.

Edit: Just updated to 0.16.41 to test this. Factorio is now using about 22% of my cpu (an i7 860) whilst sitting at the main menu, same cpu use in a new game, and whilst paused (by bring up the menu) in a new game, so it looks like something has changed. Enabling vsync gets cpu usage back to 0.16.36 levels. Did someone try to improve things for freesync monitors, by getting factroio to render as fast as possible, even when nothing has changed?

[Tami]

is it possible that the menu has no 60fps limit while ingame is a 60fps limit while vsynch is off?

[cyfrov]

same problem, even when the game is paused and minimized (or on another virtual desktop in Win10)

Does it really need the spin locks?
Can't you guys just throw in a sleep(10ms) call in the main loop when the game is paused and out of focus?

[Rseding91]

same problem, even when the game is paused and minimized (or on another virtual desktop in Win10)

Does it really need the spin locks?
Can't you guys just throw in a sleep(10ms) call in the main loop when the game is paused and out of focus?

No, it updates at 60 FPS in the main menu and while paused.

If you don't want it to take CPU then exit the game

[Tami]

same problem, even when the game is paused and minimized (or on another virtual desktop in Win10)

Does it really need the spin locks?
Can't you guys just throw in a sleep(10ms) call in the main loop when the game is paused and out of focus?

No, it updates at 60 FPS in the main menu and while paused.

If you don't want it to take CPU then exit the game

If it does like you say, then its indeed a bug, if the game cant run more than 60 fps and consume huge amount of CPU while in mainmenu. There has something strange happened between .36 and .41 that caused that.

[Rseding91]

same problem, even when the game is paused and minimized (or on another virtual desktop in Win10)

Does it really need the spin locks?
Can't you guys just throw in a sleep(10ms) call in the main loop when the game is paused and out of focus?

No, it updates at 60 FPS in the main menu and while paused.

If you don't want it to take CPU then exit the game

If it does like you say, then its indeed a bug, if the game cant run more than 60 fps and consume huge amount of CPU while in mainmenu. There has something strange happened between .36 and .41 that caused that.

Nothing in that logic changed since 0.13.

[Zavian]

Well as I tried to point out earlier Factorio 0.16.36 sitting idle in the main menu uses 0.5% of my cpu. Start a new game and it uses about 2.5% of my cpu. Total load on my cpu from everything (include about 50 chrome tabs) is about 4-5% utilization and task manager is mostly reporting the cpu clock speed to be between 1.5 and 1.8 GHz. (Vsync is off in this test, and for the first part of the 0.16.41 tests).

Upgrading to 0.16.41 and Factorio sitting idle on the main menu is using 24.9% of my cpu. The cpu is now running at around 3.03 to 3.09 GHz, so it looks like Factorio is has about 2 threads running almost continuously. If I start a new game, Factorio continues to use around 25% of my cpu. Total cpu utilization is now around 28%, and cpu clock are still over 3 GHz.

Exit back to the main menu, enable vsync, and restart Factorio. Now version 0.16.41 is idling at the main menu using about 0.5% of my cpu. Start a new game, and Factorio is using about 2.5%. Total cpu utilization is about 4-5% and cpu clocks are about 1.5 GHz.

So something seems to have changed between 0.16.36 and 0.16.41. (vysnc code maybe)?

Windows 10 Pro.
CPU I7 860 @2.8Ghz (the 3GHz+ clocks are turboboost).
GPU AMD Radeon HD 5770 with 1GB. Driver version 15.201.1151.1008
Tested with the Steam version of Factorio using a default sized window (looks like 1280x720)

If you can't reproduce this let me know and I'll provide logs and whatever else you need.

[Dimble]

(Windows 10, AMD FX 6300, nvidia gpu)

I can also report seeing this same behavior, and have narrowed it down to 0.16.39.
In .38 cpu usage is normal, with .39 and v-sync off it maxes out as soon as the title screen finishes.

gpu-z doesn't show the gpu load as being any different between the two, but that's the limit of my diagnostic ability in that area.

[Rseding91]

After looking into this more I think it should be fixed for the next version of 0.16.

[posila]

It was caused by replacing std::this_thread::sleep_for by WinAPI Sleep() to fix this: 59956, I will give it another shot in 0.17 instead

[Zavian]

Thanks for taking a look at it. Assuming you weren't using Sleep(0), then "WTF" at Microsoft if their Sleep() function is really doing a busy wait.

[posila]

Thanks for taking a look at it. Assuming you weren't using Sleep(0), then "WTF" at Microsoft if their Sleep() function is really doing a busy wait.

We call sleep_for with sub-millisecond duration in which case it resulted in Sleep(0) after the change and that is what caused it; I haven't had chance to look into it further yet.

[kitcat]

I haven't had chance to look into it further yet.

To get you started, maybe have a look at timeBeginPeriod/timeEndPeriod and timeGetDevCaps, mentioned in the Sleep() api. By default, Windows uses low resolution timers (important on laptops to conserve power) and you have to explicitly tell the system what kind of timer resolution you want. Sleep durations below the currently configured timer resolution may result in immediate wake-ups. If you’re already using timeBeginPeriod/timeEndPeriod with the correct timer resolution, sorry for wasting your time.

Linux (and probably Mac) should not be affected by this because all non-ancient desktop distributions have variable on-demand timers enabled that give you exactly the sleep duration you ask for.

[Rseding91]

I haven't had chance to look into it further yet.

To get you started, maybe have a look at timeBeginPeriod/timeEndPeriod and timeGetDevCaps, mentioned in the Sleep() api. By default, Windows uses low resolution timers (important on laptops to conserve power) and you have to explicitly tell the system what kind of timer resolution you want. Sleep durations below the currently configured timer resolution may result in immediate wake-ups. If you’re already using timeBeginPeriod/timeEndPeriod with the correct timer resolution, sorry for wasting your time.

Linux (and probably Mac) should not be affected by this because all non-ancient desktop distributions have variable on-demand timers enabled that give you exactly the sleep duration you ask for.

We already do use those

[cyfrov]

same problem, even when the game is paused and minimized (or on another virtual desktop in Win10)

Does it really need the spin locks?
Can't you guys just throw in a sleep(10ms) call in the main loop when the game is paused and out of focus?

No, it updates at 60 FPS in the main menu and while paused.

If you don't want it to take CPU then exit the game

Exit? but how else can I pass the time waiting for my Spectre sims to finish.



@posila ... sub-ms sleep accuracy is needed when paused? I can understand a need when the game is running and crunching numbers (quantization error is the bane of my existence, though you can noise shape and make it sorta go away), but while paused seems like overkill... response of human eyes is on the order of ~10ms, so if the pause screen sleeps for 16 or 17ms, instead of 16.66666663ms...imperceptible. On the otherhand, when the laptop starts glowing red when using VNC and the game is paused in the background... big problem

On the optimization front, I'm really curious as to what actually requires that kind of super accurate time step.
Was that like a "if we do this, then we can skip floating point and do integers everywhere" decision?
or a "we're getting funky computation results when we do time dither, so we best reduce it as much as possible" (I can help point you what to do here )
or something completely different?

[Rseding91]

@posila ... sub-ms sleep accuracy is needed when paused? I can understand a need when the game is running and crunching numbers (quantization error is the bane of my existence, though you can noise shape and make it sorta go away), but while paused seems like overkill... response of human eyes is on the order of ~10ms, so if the pause screen sleeps for 16 or 17ms, instead of 16.66666663ms...imperceptible. On the otherhand, when the laptop starts glowing red when using VNC and the game is paused in the background... big problem

You're simply wrong... you can notice fractions of a millisecond timing and we/players do all the time when the game doesn't process everything it should within the 16.66~ window.

On the optimization front, I'm really curious as to what actually requires that kind of super accurate time step.
Was that like a "if we do this, then we can skip floating point and do integers everywhere" decision?
or a "we're getting funky computation results when we do time dither, so we best reduce it as much as possible" (I can help point you what to do here )
or something completely different?

The main loop does. If it doesn't sleep for the correct amount of time you get a random frame per second or two that takes twice as long and then it hickups.