Hyprland
Hyprland copied to clipboard
nvidia_anti_flicker = false significantly increases CPU and GPU utilization + unuseable lag after opening special
Hyprland Version
Hyprland, built from branch main at commit 78f9ba9fdd7e258747b862ca2ae7d4cf5335f4ed dirty (makefile: add symbolic link for lowercase binary name). Date: Fri Dec 29 04:37:58 2023 Tag: v0.33.1-113-g78f9ba9f
Bug or Regression?
Bug
Description
I toggled nvidia_anti_flicker to false to fix low framerate. Now, GPU temps are up, Hyprland utilization went from averaging 1% of CPU to 4%, and when I open special, the mouse lags and becomes virtually unusable.
GPU temps, which usually stay at around the low 40's, climb to 60's, and the fan starts to speed up to counteract the high temps audibly.
How to reproduce
Toggle nvidia_anti_flicker to false, open special workspace. On my system at least, there is a lot of lag both with opening special, and after the special is open, mostly noticeable on the mouse movement.
Crash reports, logs, images, videos
The beginning of the CPU utilization graph is when nvidia_anti_flicker is toggled false. Soon after, I toggle it to true and the CPU load goes down (Given the GPU temp difference, I imagine GPU load is also going down).
do you have decoration:blur:special
enabled? it's very expensive.
Yes, I do. I will disable it and let you know if it improves. Just one second, I am finishing a test of power consumption between the anti-flicker being off and off.
Just in case this information is in any way useful:
These are the GPU stats with nvidia_anti_flicker = false. Low GPU temps, and only 6 Watts being used by the GPU (RTX 2070 Mobile):
These are the GPU stats with nvidia_anti_flicker = true. Temps have risen over 20 degrees Celcius, and power consumption has been multiplied by 5 times.
With blur turned off, the special no longer lags while loading. However, my GPU power consumption and temps have not improved.
I am seeing that you have translucent windows with blur - blur on special is equally expensive - either turn it off or enable xray.
Currently, I have disabled many of the effects. This is the script I ran:
The only effect I am seeing that is still in effect is translucent windows (no blur, however).
GPU stats are somehow worse than before, although I have not opened any new apps, just passed my mouse between monitors.
I mean if they are translucent hyprland needs to pump out 2x as many pixels with special open, sounds quite normal, no? Your gpu is an nvidia mobile, not only mobile, but nvidia..
I think the increased power usage in the last screenshot might be because autocpufreq turned off powersaving mode due to the high load, so not related to turning off the effects.
I can see why the load might be high in the first place due to the effects, but I still don't understand why it would increase this dramatically only after turning anti-flickering off. All of these effects were present when anti-flicker = true, so should the power draw not be high then as well? From what I can tell, the only difference in the code is that glFlush is called instead of glFinish, but why would that 5x the power consumption?
likely because nvidia
Fair, lol.
By default my integrated GPU should be used though, so I still don't understand why it seems like the Nvidia card is being relied on so strongly now.
shouldnt be. you can specify what card is used for hl with WLR_DRM_DEVICES
It is already set. However, when toggling nvidia_anti_flicker, it starts being used to great extent.
This is what I have in my hyprland.conf: env = WLR_DRM_DEVICES,/dev/dri/card0:/dev/dri/card1
And these are my nvidia env vars: env = GBM_BACKEND,nvidia-drm env = LIBVA_DRIVER_NAME,nvidia env = __GLX_VENDOR_LIBRARY_NAME,nvidia env = __GL_VRR_ALLOWED,1
no clue. Nvidia moment I guess.
Yeah :(
One more thing that might be relevant. This is related to #4240.
When nvidia_anti_flicker = true, I get 60 fps on vkmark. Meanwhile, if nvidia_anti_flicker = false, I get 1132 fps on vkmark.
I am wondering if when nvidia_anti_flicker = false there is no cap in FPS, and then Hyprland's FPS would far exceed the refresh rate of the monitor. I apologize for my ignorance, but could this be the reason for the increased power draw?
Image for vkmark runs:
possible, but nvidia_anti_flicker is basically what the nvidia patches were, so I'll leave it on by default. For the vast majority they fix flicker and terrible artifacts. Blame nvidia.
I also have sort of the same issue.
With nvidia_anti_flicker = true
: the whole desktop feels a bit laggy, even the mouse, and glxgears
runs at ~30fps. If a video is playing on youtube on the foreground glxgears goes up to 60fps.
With nvidia_anti_flicker = false
: the desktop is smooth overall and glxgears runs at 60, but some apps have delayed rendering except when there is input (keypress or mouse). This is very noticeable on terminals, where their output sometimes does not update until I press another key or move the mouse. If glxgears is running this delay is gone.
I would prefer to have nvidia_anti_flicker = false
, if it wasn't for the rendering delays on some apps.
By the way, some extra info on glFlush vs glFinish:
- on v0.32.3 (where glFlush() was used): same behavior as
nvidia_anti_flicker = false
, no weird black tearing - on the commit https://github.com/hyprwm/Hyprland/commit/3fe6162 I had the huge tearing like this video: https://github.com/hyprwm/Hyprland/issues/3952#issuecomment-1826361529
- huge tearing fixed by that commit https://github.com/hyprwm/Hyprland/commit/6f733 -> behavior became like
nvidia_anti_flicker = true
- on master now I don't have tearing with glFlush or glFinish.
My laptop has an Intel and Nvidia RTX 3050 Ti Mobile. The Nvidia is the one connected to the external ports, so unfortunately I cannot just turn it of.
UPDATE: setting debug:damage_tracking = 0
and nvidia_anti_flicker = false
makes everything smooth and working great, so it looks like a problem with damage tracking?
I noticed that when I disabled 'nvidia_anti_flicker' and set it to 'false', I experienced significant input lag on my second monitor in certain applications like the terminal or rofi. However, after adding 'debug:damage_tracking = 0' to the hyprland config, everything seems to be smooth now. Much appreciated!
@eingrid I'd advise against using that as a solution unless you know what you're doing. Disabling damage tracking forces your gpu to re-render your entire screen(s) as many times as your refresh rate, even when you're not using it.
I now use the following patch to render 10 extra frames, which seems to solve all the missing frame issues I had, without the full impact that disabling damage tracking has:
diff --git a/src/helpers/Monitor.hpp b/src/helpers/Monitor.hpp
index c08cdea4..16423aba 100644
--- a/src/helpers/Monitor.hpp
+++ b/src/helpers/Monitor.hpp
@@ -73,6 +73,8 @@ class CMonitor {
CMonitorState state;
+ int extraRenderFrames = 0;
+
// WLR stuff
wlr_damage_ring damage;
wlr_output* output = nullptr;
diff --git a/src/render/Renderer.cpp b/src/render/Renderer.cpp
index 863279ac..8c565d64 100644
--- a/src/render/Renderer.cpp
+++ b/src/render/Renderer.cpp
@@ -1084,6 +1084,13 @@ void CHyprRenderer::renderMonitor(CMonitor* pMonitor) {
// check the damage
bool hasChanged = pMonitor->output->needs_frame || pixman_region32_not_empty(&pMonitor->damage.current);
+ if (hasChanged) {
+ pMonitor->extraRenderFrames = 10;
+ } else if (pMonitor->extraRenderFrames > 0) {
+ pMonitor->extraRenderFrames -= 1;
+ hasChanged = true;
+ }
+
if (!hasChanged && **PDAMAGETRACKINGMODE != DAMAGE_TRACKING_NONE && pMonitor->forceFullFrames == 0 && damageBlinkCleanup == 0)
return;
It may require some changes to apply to the current master branch, but shouldn't be too hard.
feel free to make a MR. 10 seems a lot though.
feel free to make a MR. 10 seems a lot though.
Sure, I will do. I never did because when I posted about it in discord I got the feeling it would not make sense since this is a workaround for Nvidia AFAIK.
At 6 I still got some small artifacts from time to time, so ended up at 10 just to be safe.
@vaxerski should this be put behind a setting?
probably
since this comes with a (small?) performance hit and most people don't need it, if it would be a pr it should default to 0 with the number of frames configurable IMO
I'll wait to test out 555 drivers before opening a PR, since people are reporting a lot of improvements with those.
@abmantis did you have time to test 555 drivers?
@abmantis did you have time to test 555 drivers?
Yep, no change.