Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: High CPU usage when Vsync is enabled on Win32 videodriver #10079

Closed
DefinitelyNotRau117 opened this issue Oct 12, 2022 · 6 comments · Fixed by #12067
Closed

[Bug]: High CPU usage when Vsync is enabled on Win32 videodriver #10079

DefinitelyNotRau117 opened this issue Oct 12, 2022 · 6 comments · Fixed by #12067
Labels
needs triage This issue needs further investigation before it becomes actionable

Comments

@DefinitelyNotRau117
Copy link

DefinitelyNotRau117 commented Oct 12, 2022

Version of OpenTTD

Windows 12.2

Expected result

With vsync enabled, FPS is automatically tied to the screen refresh rate, the processor is used in normal mode

Actual result

изображение
image
FPS limit is removed completely, the game runs at 999+ fps, OpenTTD creates a high CPU load (one core).
Re-tested on a weaker laptop without a discrete GPU, the result is similar, ~999 fps and high load

Steps to reproduce

  1. Change videodriver in your openttd.cfg to Win32 (or run openttd with -v win32 parameter)
  2. Open Game settings
  3. Enable Vsync
  4. Check task manager
@James103
Copy link
Contributor

  1. What is the make and model of your CPU, GPU, and any monitors you're using?
  2. What refresh rates are your monitors running? It appears the frame rate is shown to be close to 1,000 Hz; therefore, the monitor's refresh rate may be reported as 1,000 Hz, even though the actual refresh rate is much lower.

I can't reproduce this issue for me on my 60 Hz setup with an Intel i5-9400F and a GTX 1660.

@DefinitelyNotRau117
Copy link
Author

pc: intel i7 9700k
nvidia rtx 2070s
Windows 10 1809 (pretty old)
Monitor default 60 Hz, but 75 is toggled in nvidia control panel

laptop intel i5 10210u @ 1.6 GHz
intel UHD 620
Windows 10 20H2
built-in laptop screen, 60 Hz

@DefinitelyNotRau117
Copy link
Author

Hmm, I checked with a completely new openttd.cfg - problems are gone, everything works as it should.

The difference that I found was
videodriver="win32"
in openttd.cfg
I don't remember when and why I set it, but after changing this parameter in a new .cfg, the game started to give out 999+ fps.

@DefinitelyNotRau117 DefinitelyNotRau117 changed the title [Bug]: High CPU usage when Vsync is enabled [Bug]: High CPU usage when Vsync is enabled on Win32 videodriver Oct 13, 2022
@James103
Copy link
Contributor

James103 commented Oct 13, 2022

With openttd -v win32 (which behaves the same as videodriver="win32" in openttd.cfg) and vsync enabled, I can reproduce the same issue (999 fps on a 60 hz monitor) in 3e86f33.

In this mode, disabling vsync instantly brings the FPS back to the value specified in "Display refresh rate", while turning it back on sets the limit to 1000 Hz.

@DefinitelyNotRau117
Copy link
Author

DefinitelyNotRau117 commented Oct 13, 2022

Okay, now another problem has appeared - at a non-standard refresh rate (75Hz) when using «empty» driver and vsync, in full screen mode, fps drops to ~50, and it becomes very unpleasant to play.

@2TallTyler 2TallTyler added the needs triage This issue needs further investigation before it becomes actionable label Oct 19, 2022
@TrueBrain
Copy link
Member

Okay, this bug is cute, and a typical case of us not handling all cases properly.

What goes wrong here, is that win32 doesn't have vsync. So you also can't change vsync when win32 is selected (read: hardware acceleration is not enabled). However, if you click Hardware Acceleration, you are being told to restart the game, but the vsync button also unlocks. Now, if you toggle vsync, you go to 1000fps.

Why? Most likely a 1ms sleep in the driver-thread that is not causing it to go to 10000000000fps; as the win32 doesn't have vsync, drawing returns instantly.

That is just cute :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage This issue needs further investigation before it becomes actionable
Projects
None yet
4 participants