Improve desktop animations by raising GPU min frequency

[es20490446e]

👤 Reporter

Hi, I'm the current maintainer of optimus-manager.

I have observed an idea I wanted to share with you. Otherwise I may implement it on optimus-manager itself.

---

🔍 Description

By default the NVIDIA GPU lowers its speed to its lowest when it isn't used.

But that has a drawback on window managers that use composition. Animations after a period of inactivity are presented kind of choppy.

But if I set the minimum clocks to the 0.5 of the max with:
sudo nvidia-smi --id=0 --lock-gpu-clocks=892,1785

Suddenly all choppiness is gone.

---

🧫 Reproducing

I have an Nvidia GeForce 1650 on an Optimus laptop: Lenovo IdeaPad Gaming 3 15IMH05.

I'm using Plasma with Kwin, having as (Desktop Effects -> Window Open/Close Animation -> Glide).

You can see the difference more when opening or closing windows that have complex drawings on them, like on (Inkscape -> Help -> About Inkscape).

---

📊 Metrics

Before running nvidia-smi Plasma reports 2:45 minutes of battery, and after that 2:40. So the power usage difference isn't that much.

If I go as far as 0.6, then I get 2:30. So 0.5 seems just the sweet spot.

---

🪛 Commands

Other useful commands are:

• nvidia-smi --id=0 --query-supported-clocks=graphics --format=csv
• nvidia-smi --id=0 --query-gpu=clocks.current.graphics,clocks.current.sm,clocks.current.memory,clocks.current.video --format=csv

[mtijanic]

Hi! It's true that waking up from deep idle takes a bit longer than ideal. This is something that should (hopefully) gradually improve in future releases, but as far as I know we don't have a silver bullet solution in the works.

However, I don't think that locking clocks is a thing that can be applied unconditionally. For many usecases, the power draw at idle is a much more important metric than animation choppiness. If a certain distribution or compositor or whatever wants to try it, go for it! The tools are all there. Just ensure your users are aware of the tradeoff.

There may be another thing to try. The chopiness comes from (a) waking up the GPU/etc (sometimes, if it went into a deep idle mode) and (b) warming up the GPU to handle the work. The second part is usually done dynamically, depending on the workload, so it might take a bit for it reach the clock levels necessary.
A window manager would know when such a process needs to take place and it could give the GPU a nudge and say "we're about to start a heavy workload, ramp up your clocks!". That might get rid of some of the (b) issues.

Let me know if anyone wants to give this a try and I can share some magic commands to see if there's a tangible benefit. These wouldn't be production worthy, but if the benefit is there we can work together to get something that is.

[es20490446e]

Thanks for the reply 👍

I have also started a discussion on Reddit, in case you want to inspect what other people think.

What I have extracted is that I shall bisect if this is a limitation of the Nvidia GPU or drivers, by comparing with the integrated GPU.

I will let you know my findings 🔍

[es20490446e]

This doesn't happen on the integrated Intel GPU. The performance is lower, but consistent.

The Nvidia GPU may be using a more aggressive approach, which makes sense when being used as secondary GPU.

But when it also renders the desktop, the time it takes can be a bit too much.

While using dynamic power management the settings "coarse" and "fine" decide if to send the GPU to idle based on if any program is being rendered on it.

Maybe a similar approach could take place for minimum clock speeds. Instead of universally using the lowest, deciding it based on something else.

[pallaswept]

Thanks for looking into this, OP. It's good that you're trying to sort this out. Your methods might need some refinement, though.

But that has a drawback on window managers that use composition.

Does it, though?
MS Windows for example, also clocks down the card to the same idle clocks we have, when it is idle, and does not suffer the same choppy animations, it just increases clocks as required for the load, and returns to idle as expected.

But if I set the minimum clocks to the 0.5 of the max
Suddenly all choppiness is gone.

This is a good sign that the clock speeds are related to the problem. It is NOT a sign that you should implement higher clock speeds for all of your users.

This is like
"My car makes a strange squeaking noise when I accelerate at a green light."
"Well, obviously the entire problem is that you stopped for traffic lights. Just don't ever do that. I'll make it so nobody ever does that."

This is not the way to fix cars... or computers or anything else 😆

[pallaswept]

Well if we think about that squeaky car analogy I talked about before: What is a car's correct minimum speed?
The normal one. The one where it stops at lights and everything is fine.
So what's the correct minimum clock speed on an nvidia GPU at the desktop?
The normal one. The one where it comes down to 210MHz and everything works fine.

The way to fix that car, is to find what makes it unable to accelerate like normal, and fix that, so that it can accelerate like normal. The GPU is the same.

Adjusting the minimum speed (of the car, or GPU) is not part of the correct response to this. The minimum speed is not the problem. In fact, the minimum speed is good. We LIKE being able to stop our car, or put our GPU into idle clocks. When we stop our car/idle our GPU, everything works as it should. That's why we shouldn't change that.

The problem is with acceleration. Of course, if we avoid the need to accelerate ever, by not slowing down, we avoid that problem. But then, even though we don't see it any more, the problem with acceleration still exists. And now also we have introduced other new problems, like car accidents, hot PCs, reduced peak performance, noisy PCs, reduced battery life, etc.

So, avoiding acceleration is not the way. But if we were to somehow fix acceleration, then we could still stop our car/idle our GPU, and still avoid accidents/have low temps, and high battery life, and all the things we LIKE about our normal minimum speed, without the original problem of squeaking/stuttering. This is what we should aim for - not a workaround, but a fix.

[es20490446e]

Now I understand.

I guess I cannot tell myself without looking into some details.

[pallaswept]

looking into some details.

I thought about this. It's super-complex and requires microsecond timing and tracing of all kinds of metrics... It's a hard one.

I'd be inclined to wait on this. The proprietary hardware suffers this same behaviour, when using the GSP firmware which the open driver must always use, and Nvidia are aware of it and working on it. It doesn't make any sense to release a driver that doesn't work, so we can safely anticipate that to be fixed in the release of the 56x series drivers, and if/when that fix happens, this problem of stuttering animations might just disappear....We hope :D

[es20490446e]

Oki, lets wait a bit then 🙃

[pallaswept]

Yes, I am very patient....furiously spams F5 on the driver page 😆