Nvidia Optimus lights on/off like a christmas tree, any workaround ?

Dear forum readers,

I recently got a new MSI laptop (GP76 10UG). As is now usual with Nvidia-equipped hardware, this thing has Optimus. However, yet again, the dGPU switches on from time to time for no apparent reason. While it's not very often, it's still too much since I'm not using it, and the system should not be using it in my back.

I thought of deactivating the dGPU in the device manager, but the same happens as with my old computer in such a case, the dGPU remains on at all times. So, bad idea.

In addition to the random times when some process uses it in my back, the dGPU switches on when :
- I start the Task Manager
- I quit the Task Manager
- Sometimes (but not always) when I visit Settings => System => Display
- I log in
- I log out
- I lock my user session
- I unlock my user session
- The screen goes into power saving mode
- The screen leaves power saving mode

I want the system to not use the dGPU under any circumstances, unless I authorise it to, and the dGPU to remain off in the meantime. Is it even possible ? I can achieve this on Linux, but never did on Windows.

Fwiw, my Windows version is 20H2 (19042.867).

I have had few instances of that too . In my case its apparently some of the store apps where I set to run using High Performance GPU do run in background from time to time firing it for a second then immediately dismisses it , mind you browsers that claim to have "Acceleration Features" sometime do manage to access the High Performance GPU directly without a set instruction in NVidia's Control Panel , and sometimes it's one of the NVContainer service instances running in background (responsible for NVidia Control Panel and Experience apps) do that for no explained reason by NVidia .

I found out if I do use NVSlimmer to setup the driver and use minimal settings such as Driver and Physics and Optimus this kind of cools off but not 100% go .

Now it is known that there are some rogue apps may lurk and try to abuse your CPU or GPU when you leave it in idle such as "Bitcoin Miners" infections where for that you might need to use Malware Bytes just to make sure you don't have one of those too .

Now finally if you switch Task Manager to Full Details and make sure you have both GPU and GPU Engine columns enabled and leave it there you may be able to spot what processes manage to fire GPU 1 upon happening in case it is not one of the upper discussed services and try to research the reasons for that .

If you are not quite a user of the dGPU and use your laptop for business use and the whole idea is trying to save on power then you can turn it off from BIOS if that is the case , you may just want to consult your laptop manual over the option name .

So bottom line you can cool it down significantly but you can't quite control it .

Hope this helps you .
Cheers

(Late) Thanks for your reply !

I generally prefer to remain vanilla, and do some changes myself, knowingly, instead of relying on a magic program. Moreover, according to what you said, it doesn't seem to really solve the problem...

From what I understand, except for explicit requests made by some apps, GPU autoselection on MS Hybrid Graphics systems is made through a so-called dList dll that's provided with the driver. In the case of Nvidia, it's that dList that interrogates the Nvidia database and decides if the dGPU shall be used or not. The dList itself can be overriden per-app in the Windows Graphics Parameters.

So according to this, I removed the dList-related entries in the registry (there are two of them, one for native programs and one for programs running through the Windows-on-Windows subsystem, i.e. 32-bit programs I suppose), and indeed it worked somehow, since selections configured through the Nvidia control panel are now ignored and if I want a program to run on the dGPU I have to explicitly ask for it in the Graphics Parameters... but unfortunately I'm not quite sure it has reduced the amount of unwanted dGPU solicitations.

(For those interested, in my case at least, the registry values are UserModeDListDriverName and UserModeDListDriverNameWow, and located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{353857C8-8C08-11EB-B0B1-806E6F6E6963}\0000. There are other keys seemingly containing the same values, such as 0001, 0002 and 0003 in my case, but deleting the values in 0000 triggered removal in the other registry keys as well. While the registry keys may be different for you, the values to look for are the same since they are part of the Hybrid system DDI.)

My conclusion is that some system programs explicitly make requests to the dGPU, and possibly Nvidia programs too. This situation causes two problems :

1. It reduces hardware durability with useless requests
2. When on battery, dGPU requests have an obvious impact on autonomy

Imho, that's something MS and/or Nvidia should address, for example by restricting dGPU access to only approved programs.

NovHak said:

(Late) Thanks for your reply !

I generally prefer to remain vanilla, and do some changes myself, knowingly, instead of relying on a magic program. Moreover, according to what you said, it doesn't seem to really solve the problem...

From what I understand, except for explicit requests made by some apps, GPU autoselection on MS Hybrid Graphics systems is made through a so-called dList dll that's provided with the driver. In the case of Nvidia, it's that dList that interrogates the Nvidia database and decides if the dGPU shall be used or not. The dList itself can be overriden per-app in the Windows Graphics Parameters.

So according to this, I removed the dList-related entries in the registry (there are two of them, one for native programs and one for programs running through the Windows-on-Windows subsystem, i.e. 32-bit programs I suppose), and indeed it worked somehow, since selections configured through the Nvidia control panel are now ignored and if I want a program to run on the dGPU I have to explicitly ask for it in the Graphics Parameters... but unfortunately I'm not quite sure it has reduced the amount of unwanted dGPU solicitations.

(For those interested, in my case at least, the registry values are UserModeDListDriverName and UserModeDListDriverNameWow, and located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{353857C8-8C08-11EB-B0B1-806E6F6E6963}\0000. There are other keys seemingly containing the same values, such as 0001, 0002 and 0003 in my case, but deleting the values in 0000 triggered removal in the other registry keys as well. While the registry keys may be different for you, the values to look for are the same since they are part of the Hybrid system DDI.)

My conclusion is that some system programs explicitly make requests to the dGPU, and possibly Nvidia programs too. This situation causes two problems :

1. It reduces hardware durability with useless requests
2. When on battery, dGPU requests have an obvious impact on autonomy

Imho, that's something MS and/or Nvidia should address, for example by restricting dGPU access to only approved programs.

Basically you just did take the hint about programs set to run on high performance profile firing autonomously and decided to remove all their profiles but through registry and not through the legit route of windows apps gpu profile or nvidia control panel which is good .

However here is an extra hint , MS doesn't share your opinion about giving users superior control over accessing hardware , as a matter of fact by the introduction of DX12 it included APIs that may allow programs to direct access hardware specifically GPU . You may wonder about the reason as Windows used to be the most convenient platform among the OS bunch when it comes to hardware control , but apparently its not becoming the case anymore , see per requests of corporates they are moving towards giving exclusive rights between software and hardware so to achieve maximum performance so the OS doesn't become a bottleneck now with the introduction of NVMe , 24+ Cored CPUs and super buses and rams that kind of clears out the majority of earlier known bottlenecks .

So it is expected that the future holds less control over your hardware as more developers start moving forward towards DX12+ , but bright side is users end up with overly priced rigs capable of gaming consoles performance and even a bit more .