-
Notifications
You must be signed in to change notification settings - Fork 61
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] integrated mode does consume double the power than nvidia mode #166
Comments
Hi @grimba, EnvyControl relies on udev rules for turning off your GPU so without lspci output I wouldn't be able to tell what's different on your device. |
Hey, thanks for the really quick answer. No problem, here the outputs: integrated: nvidia: hybrid: |
That's strange since the Nvidia GPU is correctly removed from the PCI bus and the kernel shall take care of the power management. In the other hand, bbswitch works by doing a call to the Nvidia GPU telling it to turn off (old method used in the pre Windows 10 era). |
I also found out (using your other guide to turn of nvidia gpu), that _SB.PCI0.LPC.EC.PUBS._OFF is the right ACPI call to turn off the GPU. Would it be possible to add a function to turn the GPU off by acpi_call for Devices, where the udev rules do not work? Similar like Suse does with SUSE-PRIME and the optional use of bbswitch? |
The problem with |
I don't think, that this is a problem at all, if it would be an optional feature. Envycontrol would only have to check if acpi_call module is loaded. How the user got the module running, would be out of your scope and no hard dependency of Envycontrol at all. The call itself, in my case _SB.PCI0.LPC.EC.PUBS._OFF, could also be defined by the user and set into the cache json for example. bbswitch is also not a dependency of suse-prime, it is optional. But i know, both, bbswitch and acpi_call haven't been actively developed since many years. But if Envycontrol could use it, i think it would be the best tool out there atm. |
Sup folks. I'm having basically the same problem with When setting to It does not reproduce on hybrid mode, but, with that mode it keeps nvidia powered up consuming constant 8W since it is a gaming laptop and having nvidia completely powered down makes battery life when laptop is not docked way better. Not trying to compare software here or bash anyone, just adding some more data: With Edit: yeah, looks like
|
I had the same problem, basically the gpu is woken up at startup and since the nvidia driver is not loaded (so no power management) it remains in the P0 power state. |
Hey there.
I have a Thinkpad W530. It has a pre Turing GPU, the Quadro K2000M, i use NVIDA Driver Version 470 on Arch Linux.
When i use envycontrol to set integrated mode, powertop does not show the NVidia Device in device statistics any more, but with my display backlight set to the darkest mode possible, all pm modes in powertop set to enabled and wifi switched off with the hardware switch, the computer consumes still 18-20W power.
But when i switch to nvidia mode, with the same setting, the power usage is around 10W, half of integrated mode. But the nvidia card is acitve and usable. Even now, while i am writing this text with around 50% backlight and Wifi on, it still uses only 15W of power, still less than integrated mode.
I once had a OpenSuSE Tumbleweed setup, and it brings its own Optimus Switcher, SUSE-PRIME, which uses bbswitch, if it is installed. When i used integrated mode (intel) there, the power usage was around 7W. So i guess SUSE-PRIME was able to turn off the NVIDIA GPU successfully using bbswitch and that value is my reference. On Nvidia Mode, Power Usage was around 12W, so comparable to arch. In fact, that was the only setup, where i was able to successfully turn off the nvidia gpu since the bumblebee times when i bought that laptop.
So i guess there must be something wrong with envycontrol, because it seems as if it does really not turn off the nvidia gpu. Maybe i missed something. I really do not know. Does someone have the same problem?
The text was updated successfully, but these errors were encountered: