Bug: Logos draining battery on MacBook Pro by requiring High Performance GPU
Comments
-
Stephen Steele said:
It should be an easy fix - as John posted back in January:
John Goodman said:This might be helpful?
https://developer.apple.com/library/content/qa/qa1734/_index.html
It outlines how to ensure the integrated graphics is used instead of the discreet graphics.
The current Logos application already has that setting, so that's why it's apparently not a simple fix. Given how many people use Mac, I would hope that Logos is putting a high priority on this.
You have to remember that Logos isn't really developed for a Mac. It's developed for Windows and then they use Mono software to make it run on a Mac. I can't speak for Logos and I'm not a software developer, but I wouldn't be surprised if the but is somewhere deeper than Logos and probably in the Mono software layer that Logos is using to make what is essentially a windows application run on the Mac.
I dream of a day when Logos rewrites the software to have a Mac native version
I bet there would be better performance and it would look a bit better if it used some native Mac controls.0 -
Samuel said:
I dream of a day when Logos rewrites the software to have a Mac native version
I bet there would be better performance and it would look a bit better if it used some native Mac controls.Thankful for Phil Gons (Faithlife) creating a survey => 10-question survey and thread => How do you use Logos? How can we improve it? where replies could be added with user interface control improvement(s). Also, please elaborate in Phil's thread about performance issues that affect work flow, especially item(s) that interrupt or slow down work flow.
Logos is a resource intensive application on Windows and Mac, which has a shared code base with native graphical user interface code. The shared code base uses .NET Framework on Windows and Microsoft's Mono on Mac. Microsoft purchased Xamarin (and now employs many developers of Mono) => https://www.xamarin.com/microsoft For user interaction, Windows application uses Windows Presentation Foundation (WPF) while Mac application uses native Mac Cocoa coding. Logos user interface is a bit different than Windows and Mac conventions while being easy to switch platforms as desired.
Keep Smiling [:)]
0 -
I'm getting this on my MacBook Pro 2016 15 w/ touchbar
How can I force Logos to not use high performance GPU?
0 -
Logos is high-performance software. I find that, on my new MacBook Pro, sometimes it uses HP and sometimes the integrated GP. Sometime it helps to close other apps down. Sometimes it helps to shut down Logos and open it again.
Mostly I'm just resigned to knowing my battery won't last as long when running Logos. I dim and bear it, if you will. It's worth it and I don't expect miracles.
0 -
Randall, so you're saying there's no way to turn off HP GPU on MacBook Pro for Logos 7? Logos 7 is clearly "high performance", no need to sell that point - I own it
.I just want to turn off dependency on the battery draining hP GPU usage.
0 -
Randall McRoberts said:
Logos is high-performance software. I find that, on my new MacBook Pro, sometimes it uses HP and sometimes the integrated GP. Sometime it helps to close other apps down. Sometimes it helps to shut down Logos and open it again.
Mostly I'm just resigned to knowing my battery won't last as long when running Logos. I dim and bear it, if you will. It's worth it and I don't expect miracles.
However, this is clearly a Logos bug. The way normal Mac apps work is that they use the high performance GPU when they need it and then switch to the integrated one when they no longer need it. This is they way the Logos app should work, but in Logos' case, once it uses the high performance GPU, it never goes back to the integrated one without restarting Logos. I've just learned if I use any Logos tools I have to restart Logos unless I want my battery drained. The difference in battery performance is pretty significant.
0 -
yes I took my new MBP to the Genius Bar because the battery drain was so bad. They identified Logos 7 as the culprit. I get 4 hours with Logos 7 running. Without Logos 7 I get 10 hours+
I agree this is totally a bug.
0 -
I don't see it as a bug. The app works fine. But there is certainly an opportunity for improvement there, and I'd bet they are already working on it.
0 -
Randall McRoberts said:
I don't see it as a bug. The app works fine. But there is certainly an opportunity for improvement there, and I'd bet they are already working on it.
Not to belabor the point, but it is a bug. Mac applications default to the integrated GPU when the high performance GPU is not needed. Apple added this feature several versions ago to prevent this problem. Logos fails to switch back to the integrated CPU once it uses the high performance GPU for a function. Apple created this functionality to prevent this problem and it is normal for Mac applications to switch between GPUs as needed. Logos is failing to function properly in this respect.
I'm sure they are looking at it and that's why we are all eager for a fix.
0 -
Does logos have a bug database to look up already discovered issues? Rather than assume they are "working on it" is there a way to know for sure if an upcoming release will fix this bug? (yes it is a bug)
0 -
Patrick Lacson said:
Does logos have a bug database to look up already discovered issues? Rather than assume they are "working on it" is there a way to know for sure if an upcoming release will fix this bug? (yes it is a bug)
Hi Patrick,
We do have a bug case open for this issue.
0 -
Philana R. Crouch said:Patrick Lacson said:
Does logos have a bug database to look up already discovered issues? Rather than assume they are "working on it" is there a way to know for sure if an upcoming release will fix this bug? (yes it is a bug)
Hi Patrick,
We do have a bug case open for this issue.
Thank you, Philana. Is that bug database open to the public so we don't waste time complaining in community forums [:D] Also to help us know when it will be fixed?
0 -
Patrick Lacson said:
Is that bug database open to the public so we don't waste time complaining in community forums
No this is not shared outside of Faithlife.
0 -
Patrick Lacson said:Philana R. Crouch said:Patrick Lacson said:
Does logos have a bug database to look up already discovered issues? Rather than assume they are "working on it" is there a way to know for sure if an upcoming release will fix this bug? (yes it is a bug)
Hi Patrick,
We do have a bug case open for this issue.
Thank you, Philana. Is that bug database open to the public so we don't waste time complaining in community forums
Also to help us know when it will be fixed?No this is not a public database, we will update this thread and also include an announcement in the release notes. We hope to have a fix available soon.
0 -
Samuel said:
It would be awesome if this could be fixed. With Logos even running in the background I can just watch my battery drop and it would really slow my workflow down to have to quit Logos and reopen it constantly just to keep it from running in the background and draining battery...
Samuel, this should be improved in 7.6 SR-1.
0 -
Philana R. Crouch said:
Samuel, this should be improved in 7.6 SR-1.
That's great news - I look forward to the update.
0 -
I just upgraded to
Logos Bible Software 7.6 SR-1
7.6.0.0037
I still see 'Requires High Perf GPU' in my Activity Monitor for the Logos always set to 'Yes'
0 -
For the time being, this is my workaround:
Do not start Logos with the Home Page, which triggers switch to discrete GPU.
- I start with a blank Layout
- or Start with a Layouts that do not trigger the GPU switch (I find most of my layouts do not trigger the switch)
JK
MacBookPro 14" (2021) RAM:16GB SSD:1TB macOS Sequoia 15.2 | iPhone Xs Max iOS 18.2 | Logos Pro 38.1.002
0 -
Thank you LimJK! I reduced my layouts and wow, Logos 7 is finally not use the high performance GPU! Hopefully this will take my new MacBook Pro 2016 beyond 4 hours with Logos running.
0 -
Philana R. Crouch said:
Samuel, this should be improved in 7.6 SR-1.
I just installed the new release and unfortunately it does not seem to be fixed. Just visiting the home page once triggered Logos to use the high powered GPU until I stopped it and restarted it.
0 -
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.2 | iPhone Xs Max iOS 18.2 | Logos Pro 38.1.002
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.
cBook Pro (15-inch 2018) | 2.9 GHz i9 6 core | 32GB RAM | Radeon Pro Vega 20 4 GB | 1TB SSD💻
💾 MacOS Big Sur 11.0 Beta💾
🎁Logos 7 Portfolio🎁 Logos 9 Reformed Silver🎁
⌨Logos 9 Full Feature Upgrade⌨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.
cBook Pro (15-inch 2018) | 2.9 GHz i9 6 core | 32GB RAM | Radeon Pro Vega 20 4 GB | 1TB SSD💻
💾 MacOS Big Sur 11.0 Beta💾
🎁Logos 7 Portfolio🎁 Logos 9 Reformed Silver🎁
⌨Logos 9 Full Feature Upgrade⌨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
