Allow disabling low-processor mode on headless platforms

[Calinou]

This can be used when you want processing to happen as fast as possible (at the cost of high CPU usage). This is generally not what you want for a dedicated game server, so low processor-mode is still enabled by default on headless platforms.

• Enable low-processor mode by default on headless platforms (mimics the previous behavior).
• Use a 60 FPS limit on headless mode by default (down from 144 FPS). This can be overridden by changing the Server override for application/run/low_processor_mode_sleep_usec. This allows effectively changing the server's _process() tick rate, balancing CPU usage and network bandwidth usage with latency.

This closes #32404.

Question: Can someone check if feature tags are actually case-sensitive? The documentation claims they are, but I noticed the Windows pen driver code uses .windows instead of .Windows to override the default setting. cc @bruvzg

[akien-mga]

You have some changes that I already checked in in master, needs a rebase.

[Calinou]

You have some changes that I already checked in in master, needs a rebase.

Fixed.

Also, in the master branch, this pull request won't have any effect since the server platform hasn't been reimplemented yet. When we get around to making the headless DisplayServer, it should have the Server feature tag applied to it (or server if we settle on making all feature tags lowercase). Unless we decide to rename it to headless, that is 🙂

[Faless]

window_can_draw depends on the OS/DisplayServer, e.g. window is minimized.
So, frame delay won't be applied when window is minimized, resulting, I think, in much higher CPU usage.

[Calinou]

Ah, I thought it returned a constant based on the platform.

Do you know if there's a way to make this configurable for the server platform without impacting the behavior on minimized windows?

[Faless]

well, more then one, I'm just not sure what's the best approach.

• OS implementations could change is_in_low_processor_usage_mode when minimized instead, but that might have side effects on some platforms
• Otherwise get_low_processor_usage_mode_sleep_usec could be adjusted when the display is headless.

In general, I don't like the fact that low_process_mode_sleep_usec is abused this way, but it's hard to reconcile the need of different platforms (different window/app lifecycle), display servers (vsync/headless), and the extra constrain of "adding more delay"

[bruvzg]

Question: Can someone check if feature tags are actually case-sensitive? The documentation claims they are, but I noticed the Windows pen driver code uses .windows instead of .Windows to override the default setting. cc @bruvzg

godot/core/os/os.cpp

Lines 364 to 370 in 07f076f

	bool OS::has_feature(const String &p_feature) {
	if (p_feature == get_name()) {
	return true;
	}
	#ifdef DEBUG_ENABLED
	if (p_feature == "debug") {
	return true;

It seems to be case-sensitive, the pen driver override should be changed to .Windows.

[Calinou]

@bruvzg Thanks! I opened a pull request to fix this: #47255

[Faless]

I've been wondering, would it make sense to have the !p_can_draw sleep time independent from the low_processor_mode one?

Normally, the engine is expected to run at a fixed iteration per second. This is usually handled by vsync. But as I understand it, when the window is minimized vsync won't happen, and we would end up doing millions of iterations per second. To avoid this we add the low_processor_usage_mode_sleep_usec delay (even if we are not in low_processor_mode).

But what we really want to do in that case, is trying to keep the FPS constant, so if we are not in low_processor_usage_mode what we should do is keep the FPS value consistent with the previous one, i.e. the vsync-ed one.

When vsync is unknown (headless) or disabled, either target_fps must be specified, or a default can be used (e.g. 60).

I'm also unsure if we should keep low_processor_usage_mode_sleep_usec at all. It's confusing, and if you are creating an app, you can set the target_fps if you really want the loop to sleep more and have almost the same result (keeping low_processor_usage_mode = true).

Thoughts? ( @reduz )

[Calinou]

@Faless See also godotengine/godot-proposals#2001, where I suggested capping the FPS to 20 in unfocused and minimized windows by default (adjustable with project settings).

[Faless]

See also godotengine/godot-proposals#2001, where I suggested capping the FPS to 20 in unfocused and minimized windows by default (adjustable with project settings).

Actually, on e.g. Windows FPS are indeed capped to 144 FPS like the server platform in the original issue. Exactly as a side effect of low_processor_mode_sleep_usec being applied when !p_can_draw.

[Faless]

So, maybe with hindsight from your proposal, we could change low_processor_mode_sleep_usec to be low_processor_mode_max_fps and have a low_processor_mode_when_incative (unfocused/minimized) boolean option,

[Calinou]

@Faless Sounds good to me 🙂

However, I want to stress that even with low-processor mode enabled, the default FPS limit is quite high. Being able to use a lower FPS limit selectively can help a lot with decreasing power consumption. This is why I suggested having separate project settings for each state (focused, unfocused, minimized).

Right now (without relying on scripts), you can decrease the low processor mode FPS limit globally, but then it becomes too low when you're actually using the application.

[PanTrakX]

This can be used when you want processing to happen as fast as possible (at the cost of high CPU usage). This is generally not what you want for a dedicated game server, so low processor-mode is still enabled by default on headless platforms.

Why this is not something you generally want?
What type of games with a dedicated game server is better suited with low-process enabled and what with it disabled?
If it is a session based competitive 5v5 fps game it is better with low-process disabled right?

[Calinou]

Why this is not something you generally want?

Simulating _process() as fast as possible wastes CPU cycles. Not only this increases power usage and heat/noise emissions, this is problematic for server environments where you're hosting multiple game servers on the same machine. To prevent CPU resource leeching, most VPS hosts will also shut down your machine if its load average becomes too high over a long period of time.

If it is a session based competitive 5v5 fps game it is better with low-process disabled right?

No, you should still keep low-processor mode enabled in this case, as movement updates should happen in _physics_process() instead of _process(). You don't want network updates to be sent at a variable rate depending on how fast the server simulates things 🙂