Precision 7560 & 7760 Owners' Thread

Just spent the last couple of days installing Arch Linux. I haven't installed any optimisations per se, and I am already getting incredible battery life. I have KDE Plasma on Xorg, and I get around 8% discharge per hour. This is proof that Optimus is working very, very well, as is the new Ampere power management.

 

I think the problem with Optimus on Windows arises in case when power is switched from AC to battery while some applications are already running and using dGPU. They, or the whole system, need to be manually restarted to revert to iGPU use.

 

No... On Windows anyway, there is no case where the system decides to use the dGPU for some application when the system is on AC power and the iGPU when the system is on battery power. The power source is not taken into account when deciding which GPU to use for a specific app.

Now, if you dock or connect external displays, you will get this issue with apps getting "stuck" on the dGPU until they are restarted, unless the external displays are also attached to the iGPU. (Displays through USB-C only and "discrete graphics output mode" off in the BIOS.)

The issue that we are seeing is everything reporting that there are no apps running on the dGPU, and yet the dGPU still does not power off. This has been an issue for multiple Precision generations now. In some cases you can "trick" the system into shutting the dGPU off (i.e. start Lightroom and leave it minimized).

 

What was the power for GPU ?

 

Except there is one, for instance with web browsers, such as Brave and Opera. Just retested it.
1. Nvidia CP GPU preference for the browser is set to force Integrated graphics (in fact so is the system default)
2.Plug the AC adapter in
3. Start Brave - NVIDIA GPU activity shows Brave
4. Unplug - NVIDIA GPU activity still shows Brave, battery still discharging at north of 17W
5. Restart Brave - NVIDIA GPU activity no longer shows Brave, battery discharging at 10-11W as expected on battery

It's possible that this is due how the applications where coded- clearly the GPU preference setting in Nvidia CP is ignored, however, it's obvious that whether dGPU is used or not depends on whether the system is running on AC power or not.
Now, NVIDIA GPU Activity widget is not entirely comprehensive either. For example MSI Afterburner keeps the dGPU awake, yet it doesn't show up as an "activity".

Agree that plugging the laptop into an external display tends to cause further issues, including several processes, Windows Explorer amongst them, using dGPU. I find rebooting is often the only way to get rid of all the resulting dGPU activities and restore optimal battery power utilisation.

 

Hmm, yes, applications can override the system behavior and technically use whatever rules to run whichever GPU they want. Though I would argue that it is "inappropriate" if Brave is using the dGPU when system configuration is set to have it use the iGPU. You don't really need dGPU power for a web browser.

When using Optimus with Chrome/Edge, and NVIDIA control panel set to use integrated graphics for all apps by default (which is how I always set it), I've never seen the browser using the dGPU (battery power or AC power) unless an external display was connected.

 

Just checked and Edge is particularly insidious. When launched with Hardware Acceleration enabled (the case by default), and Optimus set to Auto-select, while on AC power, it doesn't actually show up in NVIDIA GPU Activity, but you can see the tray icon flashing green from time to time and power utilisation on battery is consistent with the dGPU being awake.... Restarting while on battery solves the problem. Hope that solves your Optimus stealth GPU use mystery.

 

Wonder if this is an issue with all Chromium-based browsers? That'd be a pretty wide swath of the users here.
(I don't use the system with Optimus enabled anymore myself, I did use it for several years but since I don't use the system much on battery these days it is just more trouble than its worth to me.)

 

So, interesting problem.

I bricked my 7560 (2 amber, 7 white LED flashes).

I wanted a fully-secure boot process, so I generated my own keys, signed systemd-boot and the Windows bootloader, and enrolled the keys into the firmware, specifically, the Platform Key. Even set up LUKS encryption to trip if the firmware setup was changed, just like BitLocker. Enabled Secure Boot, and booted freely between Linux and Windows, both encrypted. Everything fine and dandy.

Today I wanted to run some benchmarks, and switched off hybrid graphics, rebooted... Bam, bricked.

I was warned about this in the Arch wiki on Secure Boot, that notebooks could be bricked if the Microsoft keys were missing, because peripherals are only signed with Microsoft keys. Well, lesson learnt, I guess. I need to find a way to clear the CMOS or the EFI variables without booting—I've already tried disconnecting the battery and holding down the power button for 30 seconds (no dice).

This must be a new record for fastest self-brick after new arrival.

That said, the fact that even in 2021, a software encryption setting can brick a machine such that it doesn't even POST, is ridiculous.

 

That stinks. Out of curiosity I looked at the service manual page 133 notes that 2 amber and 7 white is an LCD Failure (maybe this is just if you run diagnostics via F12). Any chance hooking an external display to the HDMI or mDP will let you get into the bios? Just a thought.