Bug: Logos draining battery on MacBook Pro by requiring High Performance GPU
Comments
-
I, also, just installed the latest beta and the issue is not resolved. The half-way fix would be that the discreet GPU would be released once the offending resource was closed. The ideal solution is that the discreet GPU would never be engaged.
0 -
It seems like there is some misinformation/understanding about what is causing increased battery drain in Logos. Please allow me to elaborate on some of the improvements that were made.
First, a note on when the OS uses the discrete graphics card:
The OS will switch to using the discrete graphics card when the OS determines a system api would be better serviced by (or require) the discrete card. This is possibly because the performance rendering to the screen might otherwise be chunky/laggy and overwork the CPU when using the integrated graphics card. "High perf" in this case refers to "performant" not "powered". The OS will not switch back to the integrated card after switching to the discrete card. We enable a setting that says, "Yes, allow the app to NOT always switch to the discrete card" (NSSupportsAutomaticGraphicsSwitching). If you're technically inclined, you can read a few more details here: http://supermegaultragroovy.com/2016/12/10/auto-graphics-switching/ However, be aware that parts of the article imply Logos should be able to avoid requiring the dGPU. We have experimented with the suggestions regarding NSOpenGLPFAAllowOfflineRenderers and audited calls to IOServiceOpen. If we find a way to minimize switching to the dGPU, we will.
Second, to (hopefully) dispel myths:
Yes, the discrete card consumes more power. This should not have a significant effect on energy consumption, relatively speaking. Relative being the keyword and depending a lot on battery health, battery model, machine model, cpu, rendering tasks, other applications, etc.
Third, to elaborate on some of the changes made:
In our testing to narrow down the issue, we discovered that all web-based panels (and homepage) would drain the battery (of the test machine) 1% over 30 minutes. Except, Media Tool in the default browse mode would drain 15%. Not by coincidence, the CPU was spiked to 70% indefinitely. This lined up with other reports about CPU usage in Media Tool, and investigation resulted in discovering the bug causing this spike. Fixing the CPU usage solved the battery drain issue for the scope of when Media Tool is open in browse mode.
Additionally, we were able to track down a bug affecting Notes split view under certain combinations of program scaling and/or window size. Fixing this eliminated another indefinite CPU spike that also would attribute to heavy battery drain.
In summary
Bugs that cause increased CPU usage will lead to battery drain. App usage that leverages multiple cores (like searching, Visual Filters that execute searches, etc) will cause increased CPU and therefore have an energy impact. It is possible that there are other existing bugs affecting CPU and battery that we have not discovered.
So, if you see the "High Perf" graphics card being used when looking at Activity Monitor, don't be alarmed, this is most likely not having a significant effect on battery lifetime. If you are still experiencing actual battery issues with Logos, specifically, check the CPU activity (%, time, wake ups, etc) and try to narrow the activity down to certain panels and view configurations.
I do want to apologize for not being able to fix the problem in Media Tool and Notes sooner. I hope that these fixes will solve the issues you have experienced.
Additionally
Consider the following screenshot of a high-level-overview of energy consumption for Logos after launching to a blank layout and then opening the homepage (which will trigger "Requires High Perf GPU"). We are always working to fix issues and improve application performance and usability. If you are experiencing issues, please report them with as many details as possible. Just, note that GPU usage is not always directly correlated with battery and performance issues.
0 -
The bugs still remains because the flag NSSupportsAutomaticGraphicsSwitching was created by Apple to allow applications to switch back and forth. It used to be that once an application used the discrete GPU it would not go back until the application was closed. However, with the new flag Mac applications can switch back and forth. I might reboot my machine once a month to install an update and Logos is the only application I have that won't let the discrete GPU go after it's used it. Every other app switches back and forth as needed.Matt Preucil said:The OS will not switch back to the integrated card after switching to the discrete card.
I'm really grateful for the CPU savings, but enabling that discrete GPU still has a pretty big battery hit at least on my machine and I almost never use features like Media Browser, etc. My workaround is to not use all of Logos' features or restart Logos if I use one of the features that triggers the GPU, but it would be awesome to have this fixed in a future release.
If I use something in Logos that triggers it to use the discrete card my battery life is maybe 4 hours on a 15" MBP. If I use the basics in Logos and don't trigger the discrete GPU I can get at least 6-7 hours of battery easily using other apps the entire time, so it is a pretty significant difference. I bet if I really tracked it it cuts the battery almost in half.0 -
Matt,
Thank you for working on improving the Battery drain. I am one of those who reported draining since Logos 4, so really appreciate you effort[:)] I spent 2+ hours to hopefully provide you with some additional objective data points. My Layout has 8 Logos produced Chinese Bibles, 1 ESV, 1 Program Settings.
(1) Layout Loaded WITHOUT Discrete GPU ("i" on my Menu bar)
I observed it for quite a while in a somewhat steady state, the Energy Impact: Average about 4 (actually varying from 4.0 - 4.5 during this period)
(1) Layout Loaded WITH Discrete GPU ("n" on my Menu bar)
I load the Home Page (with NO contents, so that we can have meaningful comparison) only for the purpose to trigger the GPU Switch, once done, I bring the same Layout to the foreground.
I observed it for quite a while in a somewhat steady state, the Energy Impact: average about 7 (actually varying from 4-10 during this period)
Therefore, there is some impact with Discrete GPU with my Layout.
(3) Interestingly, I observed that if I have Home Page on the foreground with zero contents, at a steady state, the Energy Impact number can be zero (which supports your point that switching to Discrete GPU does not necessary mean more Energy Impact). But, then no one in a normal scenario would load the Home Page with zero contents :-)
Hopefully, you find the observation useful for you to help us further reduced battery draining on MacBookPro. Let me know if you need additional information. Oops, I am on Logos Bible Software 7.7 Beta 3 (7.7.0.0007)
PS: How did you produced your Energy Impact Report which looks very nice [:)]
JK
MacBookPro 14" (2021) RAM:16GB SSD:1TB macOS Sequoia 15.4 | iPhone Xs Max iOS 18.4 | Logos Pro 40.2.4
0 -
Matt Preucil said:
It seems like there is some misinformation/understanding about what is causing increased battery drain in Logos. Please allow me to elaborate on some of the improvements that were made.
Thanks for your hard work and the great explanation. But, my real world experience has not changed.
With everything idle (not interacting with the computer) and Logos running with dGPU enabled, I get half the battery life versus Logos running without the dGPU enabled. It is not a CPU problem. There are no spikes or increases in CPU usage during this time of testing.
0 -
Please fix this bug, Logos is the only program that drains my battery on my Macbook =[
Keith Pang, PhD Check out my blog @ https://keithkpang.wixsite.com/magnifyingjesus
0 -
I agree. I, too, am having this issue. Logos is vital to my workflow, and I like to be mobile, but with my battery lasting a maximum of 4 hours doing any amount of work in it, my options are limited for how long I can actually work away from the office.
💻 M2 MacBook Air (13-inch 2022) | 24GB RAM | Apple M2 GPU 10 Core + Metal | 2TB SSD💻
💾 MacOS Sequoia 💾
🎁Logos 10 Gold 🎁 Logos 10 Reformed Platinum🎁
⌨ Logos Max ⌨0 -
Andrew Zoll said:
I agree. I, too, am having this issue. Logos is vital to my workflow, and I like to be mobile, but with my battery lasting a maximum of 4 hours doing any amount of work in it, my options are limited for how long I can actually work away from the office.
For me, I did some testing and discovered that this issue manifests itself on the Home Page, but ALSO when I open a sermon document. I didn't expect that.
💻 M2 MacBook Air (13-inch 2022) | 24GB RAM | Apple M2 GPU 10 Core + Metal | 2TB SSD💻
💾 MacOS Sequoia 💾
🎁Logos 10 Gold 🎁 Logos 10 Reformed Platinum🎁
⌨ Logos Max ⌨0 -
Matt Preucil said:
However, be aware that parts of the article imply Logos should be able to avoid requiring the dGPU. We have experimented with the suggestions regarding NSOpenGLPFAAllowOfflineRenderers and audited calls to IOServiceOpen. If we find a way to minimize switching to the dGPU, we will.
Isn't there a way to simply avoid using the dGPU at all, ever?
0
