100% GPU load on empty scene

[FyiurAmron]

Godot version

3.x (multiple), 4.x (multiple, "Compatibility" renderer)

System information

Windows 7, Radeon RX 580, Adrenalin 21.5.2, GLES2/3

Issue description

Empty scene in Godot 3.x/4.x "Compatibility" renderer with opengl3 driver (it's happening for me since at least 3.2, and is still happening with 3.5) causes 100% GPU load. Adding a sensible run/frame_delay_msec prevents immediate GPU inferno (GPU still bursts to 100% every frame though), but also (obviously) induces stutter etc.

At first I thought that this might be a VSync issue, but no VSync setting (neither via Godot project settings nor GPU settings) helped. Manually checking the amount of rendered frames per sec suggests that VSync is indeed on.

It doesn't happen for Godot 4.x with the new renderers, FWIW.

Steps to reproduce

create empty scene, run, watch how the GPU spews fire

[Calinou]

Related to https://github.com/godotengine/godot/issues/60100.

I can't reproduce this on 3.5.beta5 on Linux (with default project settings and a 144 Hz monitor):

Adding a sensible run/frame_delay_msec prevents immediate GPU inferno (GPU still bursts to 100% every frame though), but also (obviously) induces stutter etc.

Try enabling Low Processor Usage Mode in the Project Settings instead. You could also set Debug > Force Fps, which is a FPS limiter with a variable sleep duration (unlike frame delay, which is constant and is meant to simulate high CPU load for testing purposes).

[FyiurAmron]

@Calinou I'm quite convinced this is related to some specific driver/OS config (maybe Windows 7 + Radeon?) going haywire on otherwise sound code/shaders etc. Trying to run Godot 3.x in a Linux VM (Ubuntu @ VirtualBox) results in Built-in function "texelFetch(sampler2D, ivec2, int)" is only supported on the GLES3 backend, but your project is using GLES2. - and trying to switch to GLES3 does nothing (editor reverts to GLES2 again), so ATM it's hard for me to say if it would repro there (probably not anyway).

Force FPS set to current VSync Hz didn't do anything at all, but Low Processor Mode with default 6900 usec setting did reduce the GPU load to 0%, although the GPU clocks were still set to high-performance mode. On 4.x it still gets to almost idle (near the lowest possible) clocking without any tricks.

BTW, I was wondering if there's some way to profile/debug the GPU-intensive parts of Godot without recompiling it from source (doing that fails on my box, due to some Python-not-supported-on-Win7-related etc. stuff).

[Calinou]

BTW, I was wondering if there's some way to profile/debug the GPU-intensive parts of Godot without recompiling it from source (doing that fails on my box, due to some Python-not-supported-on-Win7-related etc. stuff).

You can use a GPU profiler like NSight, but these are specific to your brand of GPU and generally only support recent hardware (especially for Vulkan profiling). OpenGL profiling is also often only available in limited form, since GPU profilers are typically focused around Direct3D support.

AMD has a NSight equivalent, but I don't know if it can profile OpenGL 3.x (and whether it still works on a RX 580).

[FyiurAmron]

I've noticed there are newer GPU drivers for my platform, but updating from 21.5.2 to 22.6.1 didn't fix this. I'll try repro-ing on another Win box I got my hands on lately (Win10 laptop) and see how it goes there.

[FyiurAmron]

@Calinou I've found one thing, hard for me to say if it's to be expected or not:

if I press the mouse on the "close window" X button the GPU usage drops to 0% for as long as I keep the mouse button pressed. It doesn't matter if I keep the mouse cursor over the X button, move it over the game window, move it completely outside etc., as long as I keep the button pressed.

Moving the window, resizing it etc. doesn't seem to trigger this however.

[Calinou]

@FyiurAmron It might be worth checking whether Radeon Software 22.7.1 fixes this, as it features notable OpenGL performance improvements (at the cost of visual glitches).

[rintroix]

Can confirm 100% CPU usage on one core on empty project on 3.5 stable Godot from flatpak.

fedora linux 36, both Wayland and X11 Gnome sessions.
Godot Engine v3.5.stable.flathub.991bb6ac7
OpenGL ES 3.0 Renderer: Mesa Intel(R) HD Graphics 2000 (SNB GT1)

Bug is not present with manually downloaded Godot 3.5 from the web site.

edit:

Try enabling Low Processor Usage Mode in the Project Settings instead. You could also set Debug > Force Fps, which is a FPS limiter with a variable sleep duration (unlike frame delay, which is constant and is meant to simulate high CPU load for testing purposes).

With both settings enabled CPU usage with flatpak version is ~70%.

[Calinou]

Can confirm 100% CPU usage on one core on empty project on 3.5 stable Godot from flatpak.

This is likely a different issue (caused by something Flatpak is doing or one of its libraries), and is tracked at https://github.com/flathub/org.godotengine.Godot/issues/108. I don't know why it's happening.

[FyiurAmron]

@Calinou correct me if I'm wrong, but wasn't 22.6.1 the last release for Win7? 22.7.1 & 22.8.1 seem to be only in Win10/11 versions, as far as I can see.

[Calinou]

@Calinou correct me if I'm wrong, but wasn't 22.6.1 the last release for Win7? 22.7.1 & 22.8.1 seem to be only in Win10/11 versions, as far as I can see.

Windows 7 is EOL, so GPU manufacturers are no longer releasing new drivers for it. You'll need to upgrade to Windows 10/11, or switch to Linux if you want competent OpenGL drivers :slightly_smiling_face:

[FyiurAmron]

@Calinou out of curiosity: I wasn't able to find any place that would explicitly say that Godot does or doesn't support Win7 (e.g. Unity explicitly says it still supports Win7, UE4 also say it does in 4.27, UE5 says it doesn't and that it in turn requires full DX11.3 & DX12 explicitly) - what is actually the case here ATM?

[Calinou]

• what is actually the case here ATM?

As of writing, Godot still explicitly supports Windows 7. We aim to have Godot 4.0 support Windows 7 too, but third-party changes may prevent this from materializing. It's not guaranteed that releases past 4.0.x will keep Windows 7 support.

[XDRiVE888]

I CONFIRM this bug, with the only difference being that on my Windows 10 device, Intel HD Graphics 2000, the GPU loads a 50% empty Godot 3.5.1 project. I noticed that the load is proportional to the size of the window, that is, the smaller the window, the less load on the gpu. This is the same in html5 project too, although the load is a little more - 65%. I consider this to be a significant performance bug, as it limits the game's capabilities, and on a mobile device causes a rapid discharge. It seems that somewhere there is an unoptimized copying of data to the screen or gpu. For comparison, on my full hd device, a 60 fps video displayed in the browser loads the gpu by 35% of everything. It turns out that the empty Godot project loads the gpu almost twice as much as playing a 60 fps video in full hd. I received data on the load on the gpu using the GPU-Z utility. And yet, perhaps this will help with the search for this bug, then when you set the get_viewport().render_target_update_mode = 0 code, the load on the GPU completely disappears to 0%, well, it’s clear that nothing will be drawn and displayed with this code.

[Calinou]

Intel HD Graphics 2000, the GPU loads a 50% empty Godot 3.5.1 project

This is a very slow IGP (low-end Sandy Bridge). It's expected to show high load in basic 3D scenes, as its graphics power is very limited. Even back in 2011, it was already considered very limited compared to entry-level dedicated GPUs of the time (such as a GTX 550 Ti).

For comparison, on my full hd device, a 60 fps video displayed in the browser loads the gpu by 35% of everything. It turns out that the empty Godot project loads the gpu almost twice as much as playing a 60 fps video in full hd

Video decoding uses entirely different hardware compared to GPU rendering. You can't compare the GPU utilization percentages for those.

and on a mobile device causes a rapid discharge

You can decrease the FPS limit in the editor to reduce resource usage at the cost of responsiveness. This is done by increasing Low Processor Mode Sleep Usec to 33300 in the editor settings. Targeting 60 FPS on integrated graphics is hard enough already, but it's even harder on 11 year old integrated graphics (and the low-end variant at that).

[XDRiVE888]

Targeting 60 FPS on integrated graphics is hard enough already, but it's even harder on 11 year old integrated graphics (and the low-end variant at that).

@Calinou , are you familiar with the Sega Megadrive? the video processor, if I'm not mistaken, is about 12 megahertz. Here is an example of playing on it https://youtu.be/xhNv476tAs8 Intel HD Graphics 2000 with a frequency of 1000 megahertz, that is, almost a hundred times more powerful than Sega's video processor. The question is, where and what is 50% of the power of this GPU spent when displaying an empty screen of an empty Godot project? This is the power of as many as 50 such games as on Sega working in parallel. And is it possible to fix this by freeing up this power, and not wasting the power of the GPU in nowhere?

[RubberDuckShobe]

Unsure if I should open another issue for this, but I am having the same issue on Godot 4 instead of Godot 3. The issue suddenly manifested in a project I was working on, even in empty scenes. I tried creating a new project with an empty scene and the issue persisted.

This only happens when testing the game, the editor is fine. Capping the FPS doesn't help either. My GPU is an NVIDIA RTX 2070.

[Calinou]

Unsure if I should open another issue for this, but I am having the same issue on Godot 4 instead of Godot 3. The issue suddenly manifested in a project I was working on, even in empty scenes. I tried creating a new project with an empty scene and the issue persisted.

This only happens when testing the game, the editor is fine. Capping the FPS doesn't help either. My GPU is an NVIDIA RTX 2070.

What framerate are you getting in the running project? What refresh rate do you have? If the refresh rate isn't reached and the CPU isn't fully utilized, the GPU will be fully utilized as expected.

Also, how are you checking GPU utilization? The Windows task manager is wildly known to give unrealistic readouts for GPU usage. Try using something like NVIDIA's own overlay (Alt + R) instead.

[RubberDuckShobe]

What framerate are you getting in the running project? What refresh rate do you have? If the refresh rate isn't reached and the CPU isn't fully utilized, the GPU will be fully utilized as expected.

When uncapped, my framerate is usually over 1000. My monitor's refresh rate is 144Hz.

Also, how are you checking GPU utilization? The Windows task manager is wildly known to give unrealistic readouts for GPU usage. Try using something like NVIDIA's own overlay (Alt + R) instead.

I was indeed checking GPU utilization with Task Manager, NVIDIA's overlay produced numbers that are definitely more in line with what I'd expect. So, another mystery solved, thank you.

[RubberDuckShobe]

Nevermind, it's definitely not just Task Manager, now the NVIDIA overlay shows extremely high usage as well:

[Calinou]

Nevermind, it's definitely not just Task Manager, now the NVIDIA overlay shows extremely high usage as well:

At uncapped FPS, this is expected. At capped FPS, high GPU utilization can occur if the GPU is downclocking as a result of low utilization (since the GPU is running at a lower power state). Check the core and memory frequencies when running at capped FPS, as well as the power consumption figure. This is the figure you should care about the most, as it'll directly impact noise/heat/battery life.

A RTX 2070 at full load generally pulls about 190W, though custom AIB models may pull significantly more as a result of factory overclocking.

[RubberDuckShobe]

Okay, so, mystery solved for real this time. Thanks for the additional info! Turns out my issue was a combination of:

• Task Manager's questionable readouts, which makes the GPU usage appear much higher than it actually is
• Uncapped FPS, which made the GPU usage actually high

[Calinou]

@FyiurAmron Can you check if power consumption is actually high on your GPU with capped framerate/V-Sync, as mentioned in the above comments?

For reference, typical power consumption for a RX 580 at full load is 200-210W (more for factory overclocked models).

[FyiurAmron]

@Calinou Tested today with Godot_v3.5.2-stable_mono_win64

before running an empty project: after runnning an empty project:

40-50W is definitely too much for just an empty scene with 0 objects, 0 extra triangles, 0 additional shaders etc. The temperature slowly rises if it's left for longer periods of time. Afterwards, the fans go up. The problem is definitely organic and not an artifact of the measuring tools.

As I've already stated, neither manual framerate capping nor various VSync modes work here. I've tried using regular VSync via Godot, forced VSync via Radeon Software, I tried using Radeon Chill with various caps, and Radeon Enhanced Sync. I've measured 60 FPS all the way (on a 60 Hz display mode). I was also able to run with max FPS after disabling VSync, which increased the GPU temperatures and power consumption even more.

Like I said, the only things that worked to limit it were either switching to Godot 4, using run/frame_delay_msec or Low Processor Mode.

This is the empty scene in Godot 4, for comparison:

The power consumption bounces up and down a bit, but it generally around 20 W, and in the 5-35 W range in total. Also, both %GPU usage, temperatures and clocks are way lower.

And BTW 1: no, to reach 200W it actually requires more than just typical 100% GPU load. Even FurMark max GPU stress tests hit approx 150W peak and about 110W avg power on my setup due to auto power limits, thermal throttling etc. In any case I wouldn't call "200-210W" a "typical power consumption" for RX 580. Even 180W is the advertised max AFAIR, to go higher you need to both overclock it and select a thermal profile that would handle that much power. I'd even say that it's almost impossible to get there if you enable some options to reduce the total power consumption; I'm able to run new-ish games at 1920x1080 at 30-60 FPS without much trouble or too much heating going on, staying <= 100W.

See e.g. the discussion at https://www.reddit.com/r/Amd/comments/b9bel8/average_power_usage_by_rx_580_8_gb/ ; the values provided by people there match my experience from the past 3 years of using this GPU.

BTW 2 in any case, I wouldn't say I would expect an empty Godot scene to be about as demanding for my GPU as e.g. Titanfall 2, Against the Storm or Dyson Sphere Program at "Medium" quality settings :)

[FyiurAmron]

@Calinou I have an additional data point here. I went back to Godot dev after hiatus, so I switched to 4.x which provides "Compatibility" renderer... lo and behold, as soon as I go with "Compatiblity" on core OpenGL 3, this bug is back! :D

Forward+ (everything in order)

Mobile (everything in order)

Compatibility & opengl3 (yup, flat 100% GPU and egg-cooking-on-the-PC-case mode enabled as soon as I switched to it)

Compatibility & newly-added opengl3_angle (wow. It works as expected again!)

This does happen with both 2D and 3D scene root BTW - so yeah, this is definitely linked to OpenGL shader code+drivers combo, and probably affects only a tiny minority of users. Thankfully, ANGLE can be seen as a "fix" for this, as core OpenGL 3 without ANGLE is extremely problematic anyway.

FWIW I'm leaving this open ATM because

1. this still always happens for the mainline (supported) 3.x releases with no real workaround unless we get ANGLE in 3.x XD,
2. 4.2 is still a preview version, and "Compatible" renderer (impacted) has been there for a while,
3. as long as raw opengl3 is there in the trunk alongside opengl3_angle, this can and will still occur in the wild, even if for only a small bunch of people.

I wouldn't get frustrated if this got a "won't fix/can't fix" resolution ATM, since the actual impact on the 4.2+ versions is still next to none.

[ZerxZ]

I also have this problem, I tried the official solution and still have the problem. Then I found another way, a possible solution. Project ->Project Setting -> Application -> Run -> Max FPS The default is 0, which may result in 100% GPU utilization. I recommend setting it to 30 or 60 to see if this solves the problem.

[FyiurAmron]

I also have this problem, I tried the official solution and still have the problem. Then I found another way, a possible solution. Project ->Project Setting -> Application -> Run -> Max FPS The default is 0, which may result in 100% GPU utilization. I recommend setting it to 30 or 60 to see if this solves the problem.

TBH, VSync (or every-other-Vsync etc.) is exactly this, hence the report in the first place. It should be impossible to get 100% GPU with proper VSync on empty scene, because VSync explicitly caps the frame rate to refresh frequency. For me, 100% GPU happened even with only 60 frames being rendered per second.

[ZerxZ]

I also have this problem, I tried the official solution and still have the problem. Then I found another way, a possible solution. Project ->Project Setting -> Application -> Run -> Max FPS The default is 0, which may result in 100% GPU utilization. I recommend setting it to 30 or 60 to see if this solves the problem.

TBH, VSync (or every-other-Vsync etc.) is exactly this, hence the report in the first place. It should be impossible to get 100% GPU with proper VSync on empty scene, because VSync explicitly caps the frame rate to refresh frequency.

My problem even with VSync disabled has 100% GPU issues. Just setting Max FPS solved it.

And I'm replying for reference purposes only, maybe it will help someone else with the same problem.

Godot v4.2.2.stable.mono - Windows 10.0.22000 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Laptop GPU (NVIDIA; 31.0.15.5123) - 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 Threads)

[FyiurAmron]

@ZerxZ

My problem even with VSync disabled has 100% GPU issues.

By disabling VSync, you explicitly tell the GPU to use 100% of power and render as many frames as possible, ignoring the actual monitor refresh rate. To cap the GPU use, you usually enable VSync or any of its relatives. Either you have a typo in your reply to me, or what you get is the actual expected result, no bug whatsoever. What you should check is the amount of actual frames/second rendered with VSync enabled (and no other FPS cap turned on). If you get an FPS count different than the one expected with VSync enabled (i.e. ~equal to your monitor refresh rate), IMVHO that's a completely different problem (and should be posted as a separate bug report). Strictly speaking, there should be no need to cap FPS with VSync at all, because you already capped it via waiting for vertical synchronization signal from the monitor.