Framerate drops to 1 FPS when Screen Energy Saving activates / screen turns off

JemaOne commented 8 months ago

Tested versions

v4.2.1.stable.official [b09f793f5]

System information

Godot v4.2.1.stable - Fedora Linux 39 (KDE Plasma) - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 1650 (nvidia; 545.29.06) - 11th Gen Intel(R) Core(TM) i9-11900T @ 1.50GHz (16 Threads)

Issue description

In the MRP an audio is played every 0.2 seconds. As soon as the monitor turns off (due to energy saving), the audio is being played only around every 3 seconds.

Btw. the same issue also happens when dragging the window around.

Expected behaviour is of course that it should continue playing every 0.2 seconds.

Steps to reproduce

set energy saving monitor turn off to 1 minute
run MRP in linux ( I don't know if the same issue occurs on windows)
wait for 1 minute until the monitor turns off

Minimal reproduction project (MRP)

MonitorTest.zip

Calinou commented 8 months ago

Can you check the project's rendered framerate by running the project with the --print-fps command line argument?
Can you reproduce this issue in other games?
Can you reproduce this issue if the project window is minimized?

Riteo commented 8 months ago

Mh yeah this feels like it might be related to "low consumption mode" (minimized window). Would be worth checking out #82222 if it indeed happens indeed to happen on a minimized window.

JemaOne commented 8 months ago

Can you check the project's rendered framerate by running the project with the --print-fps command line argument?

I did print the time in seconds since start, the delta value and FPS in the _process function:

seconds: 60.05 delta: 0.016 fps: 59 seconds: 60.204 delta: 0.133 fps: 59 seconds: 61.206 delta: 0.133 fps: 59 seconds: 62.206 delta: 0.133 fps: 5 seconds: 63.206 delta: 0.133 fps: 1 seconds: 64.206 delta: 0.133 fps: 1 seconds: 65.206 delta: 0.133 fps: 1 seconds: 66.206 delta: 0.133 fps: 1 seconds: 67.207 delta: 0.133 fps: 1 seconds: 68.208 delta: 0.133 fps: 1 seconds: 68.279 delta: 0.070 fps: 1 seconds: 68.279 delta: 0.000 fps: 1 seconds: 68.28 delta: 0.000 fps: 1 seconds: 68.286 delta: 0.016 fps: 1 seconds: 68.306 delta: 0.008 fps: 1

As you can see, when the monitor goes to sleep, the _process function is only called (exactly) once per second.

Can you reproduce this issue in other games?

You mean a published game not made in Godot? I currently don't have any games installed on this PC, but I can install one tomorrow and test.

Can you reproduce this issue if the project window is minimized?

No, I can't. When the window is minimized, the issue doesn't occur anymore when the monitor turns off.

Here is the code I used:

extends Node2D

@onready var audio_stream_player = $AudioStreamPlayer

var time : float

func _process(delta):
    print("seconds: %s " % str(Time.get_ticks_msec() / 1000.0), 
        "delta: %s " % str(delta).pad_decimals(3),
        "fps: %s " % Performance.get_monitor(0))

    time += delta
    var do_play = false
    while time > 0.5:
        do_play = true
        time -= 0.5
    if do_play:
        audio_stream_player.play()

AThousandShips commented 8 months ago

No, I can't. When the window is minimized, the issue doesn't occur anymore when the monitor turns off.

That's a very interesting and arguably relevant detail

Riteo commented 8 months ago

You know, I heard about some WSI limiting to 1 fps in certain circumstances. I wonder if there's something fishy going on. This is an nvidia card after all :P

JemaOne commented 8 months ago

When dragging the window around quickly, the same thing happens:

seconds: 9.81 delta: 0.061 fps: 31 seconds: 9.81 delta: 0.005 fps: 31 seconds: 9.976 delta: 0.110 fps: 31 seconds: 10.644 delta: 0.127 fps: 31 seconds: 11.767 delta: 0.135 fps: 10 seconds: 14.768 delta: 0.134 fps: 1 seconds: 14.778 delta: 0.010 fps: 1 seconds: 14.778 delta: 0.000 fps: 1 seconds: 14.779 delta: 0.000 fps: 1 seconds: 14.78 delta: 0.009 fps: 1

As you see, there is an exact gap of 3 seconds.

JemaOne commented 8 months ago

I just tested on a raspberry pi 4 and it has the same issue when the monitor turns off. So this issue is not caused by specific hardware/GPU/CPU, linux distribution, X11/wayland or desktop environment.

Dragging the window around didn't cause problems though, so I guess this isn't related to the issue of turning off the monitor.

Riteo commented 7 months ago

@akyoto reported that a similar issue got fixed by the latest driver update: https://github.com/godotengine/godot/issues/88493#issuecomment-1971768776

Could you try reproducing this issue again?

JemaOne commented 7 months ago

@Riteo I can't test the latest drivers, as my linux distribution didn't ship it yet. I will do it once the driver is shipped.

As I mentioned in my last post, the issue also occurs on a raspberry pi, so I don't think it's related to the nvidia driver.

I just tested on Godot V4.3 dev4 and the issue is still there (Fedora 39, X11, nvidia driver 545).

Riteo commented 7 months ago

@JemaOne

As I mentioned in my last post, the issue also occurs on a raspberry pi, so I don't think it's related to the nvidia driver.

Oh right, sorry. I got things mixed up too, as that was a Wayland issue and this one isn't :sweat_smile:

JemaOne commented 7 months ago

@akien-mga I think the new title doesn't fit the issue.

As I mentioned in another post, dragging the window around seems to be another issue not related to the issue of turning off the monitor.

Also, the "monitor off" issue occurs on X11 and also on wayland.

akien-mga commented 7 months ago

Yeah I just tested myself to confirm. Tested both 4.2.1-stable and 4.3-dev4 / current master (7d2ca2d8ac49cde9767e00b70f9eaf1920eb266d).

I couldn't reproduce the issue with dragging the window, which was the easiest step to reproduce in the OP, so I suggest editing the OP to clarify that.

I can reproduce the issue with Screen Energy Saving turning off the screen, on KDE Plasma on Fedora 39, both with X11 and Wayland sessions. On a Wayland session, it happens whether running with the X11 or Wayland display server.

The FPS seems to drop to 1 when energy saving is toggled, and as soon as it ends it goes back to normal framerate:

Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 164 (6.09 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 87 (11.49 mspf)
Project FPS: 1 (1000.00 mspf)
Project FPS: 1 (1000.00 mspf)
Project FPS: 1 (1000.00 mspf)
Project FPS: 1 (1000.00 mspf)
Project FPS: 1 (1000.00 mspf)
Project FPS: 1 (1000.00 mspf)
Project FPS: 1 (1000.00 mspf)
Project FPS: 45 (22.22 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 164 (6.09 mspf)
Project FPS: 165 (6.06 mspf)

When the window is minimized, the issue doesn't occur anymore when the monitor turns off.

I can also reproduce this fact, which is interesting to say the least.

akien-mga commented 7 months ago

Mh yeah this feels like it might be related to "low consumption mode" (minimized window). Would be worth checking out #82222 if it indeed happens indeed to happen on a minimized window.

Tested this PR and it doesn't affect the bug described here:

Still goes to 1 FPS when screen goes black
Still does not go to 1 FPS when the window is minimized and screen goes black

But we established in another issue on Wayland that minimizing windows on KDE Plasma doesn't seem to have the same effect as you seem to observe on some other DEs/WMs, so this might need to be tested on multiple DEs.

BTW, can anyone not on KDE Plasma reproduce the issue too? So far we've established the issue is triggered by KDE's "Screen Energy Saving" mode where it turns off the screen. I assume some other DEs might have similar features, but possibly with a different effect.

JemaOne commented 7 months ago

@akien-mga I tested on a raspberry 4 with raspberry OS (which is based on debian and has another DE, not KDE) and was able to reproduce the issue.

akyoto commented 7 months ago

BTW, can anyone not on KDE Plasma reproduce the issue too?

I tried:

Gnome/X11 session
Gnome/Wayland session
Hyprland/Wayland session

All of them successfully reproduce the issue when the monitor is turned off.

akien-mga commented 7 months ago

To clarify the "monitor turned off", do you folks reproduce this on an external monitor when physically powering it off, or only when letting the OS turn it off for power saving?

On my end on a laptop (no physical button to power off the monitor):

I reproduce it when KDE starts the power saving mode
I can't reproduce it if I turn off the monitor with Fn+F10 (which behaves similarly to power saving, any input event turns it back on)

akyoto commented 7 months ago

To clarify the "monitor turned off", do you folks reproduce this on an external monitor when physically powering it off, or only when letting the OS turn it off for power saving?

Physically pressing the off button (on the external monitor).

JemaOne commented 7 months ago

To clarify the "monitor turned off", do you folks reproduce this on an external monitor when physically powering it off, or only when letting the OS turn it off for power saving?

I originally tested by letting the OS turning it off. I just tested now by pressing the button on my external monitor and I was NOT able to reproduce the issue.

Riteo commented 7 months ago

I wonder, can this be replicated on OpenGL or other Vulkan programs (e.g. vkcube)? This feels really weird.

akyoto commented 7 months ago

With the flag --display-driver wayland which is available in 4.3 this problem no longer occurs in a Wayland session on my machine.

There is still a very short-lived hiccup when the monitor goes off, but it goes back to normal FPS shortly after:

~/downloads/MonitorTest
godot.linuxbsd.template_release.x86_64.llvm ./project.godot --display-driver wayland --print-fps

Godot Engine v4.3.dev.custom_build.df78c0636 (2024-02-28 08:34:40 UTC) - https://godotengine.org
Vulkan 1.3.277 - Forward Mobile - Using Device #0: NVIDIA - NVIDIA GeForce GTX 1070
Requested V-Sync mode: Enabled - FPS will likely be capped to the monitor refresh rate.

WARNING: Icon not supported by this display server.
     at: set_icon (servers/display_server.cpp:591)
Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 50 (20.00 mspf) <-- monitor turned off
Project FPS: 118 (8.47 mspf)
Project FPS: 145 (6.89 mspf)
Project FPS: 145 (6.89 mspf)
Project FPS: 145 (6.89 mspf)
Project FPS: 145 (6.89 mspf)
Project FPS: 145 (6.89 mspf)
Project FPS: 145 (6.89 mspf)
Project FPS: 145 (6.89 mspf)
Project FPS: 148 (6.75 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)
Project FPS: 165 (6.06 mspf)

I wonder, can this be replicated on OpenGL or other Vulkan programs (e.g. vkcube)?

mangohud vkcube with logging enabled shows that the FPS are stable during the entire test. It doesn't care if the monitor is turned off or not.

saulbensach commented 1 day ago

Hi all, I'm on a new Fedora 40 install, is happens when I unfocus the window it just goes to 1FPS

godotengine / godot