hi list,
out of curiosity why the battery live of a macbook pro is so different sometimes i investigated if the graphics card may be the culprit and i installed this nice tiny tool to tell me when which of the two graphics cards is actually used http://gfx.io/ it turned out that my suspicion was correct and it is quite interesting to see which programs cause to use the ati card (discreet) over the energy savy intel (integrated) one. For instance current Opera is forcing the descreete card, so just leaving Opera on in the background causes the battery to drain even though the processor is idle.
So i tried this for Pd and found that it is not affecting the graphics card switch until the moment you are loading Gem. So if you are patching with Gem loaded even without the window open the discreete card is used.
That's certainly not a really big issue, but i thought it might be interesting enough to share this observation here. It would be desirable to make Gem only switch the graphics card when rendering to the Gemwin is turned on instead of on loading the library.
I don't know if that could be an issue on other platforms and hardware as well.
max
Quoting Max abonnements@revolwear.com:
So i tried this for Pd and found that it is not affecting the graphics card switch until the moment you are loading Gem. So if you are patching with Gem loaded even without the window open the discreete card is used.
i think the logic behind automatically disabling the internal gfx-card is very simple: as soon as an application loads the libGL dylib, power-save mode is deactivated. if no application references libGL anymore, powersave mode is disabled.
now Gem is dynamically linked against libGL, which means that libGL is loaded as soon as Gem is loaded (opera is probably linked against libGL too, so as soon as you start opera, power-save mode is disabled). deferring the loading of libGL until Gem is used, might turn out to be quite tricky (note to myself: though it really might be possible, given that Gem uses glew to wrap around GL). it's not high on the priority list though.
fgmadsr IOhannes
Am 26.10.2012 um 11:13 schrieb zmoelnig@iem.at:
Quoting Max abonnements@revolwear.com:
So i tried this for Pd and found that it is not affecting the graphics card switch until the moment you are loading Gem. So if you are patching with Gem loaded even without the window open the discreete card is used.
i think the logic behind automatically disabling the internal gfx-card is very simple: as soon as an application loads the libGL dylib, power-save mode is deactivated. if no application references libGL anymore, powersave mode is disabled.
now Gem is dynamically linked against libGL, which means that libGL is loaded as soon as Gem is loaded (opera is probably linked against libGL too, so as soon as you start opera, power-save mode is disabled). deferring the loading of libGL until Gem is used, might turn out to be quite tricky (note to myself: though it really might be possible, given that Gem uses glew to wrap around GL).
i've asked the programmer of gfxcardstatus, cody krieger, if that is how it works, and he replied:
That's not quite right, but it's close.
It's not linking against any particular library or framework that's the issue - it's when you actually use anything OpenGL-related in practice. For example, as soon as you lay down a CALayer in a Cocoa application, the discrete GPU will power up in 10.7 and below (because CALayers are OpenGL-backed). In 10.8, this behavior changed a little, and just using CALayers (or anything from Core Animation) will no longer cause the discrete GPU to turn on, but direct use of OpenGL, among other things, will.
Hope that helps! :)
Cody
so IOhannes, it's not something what's particularly bugging me or what I find über important. It's a mere observation which I wanted to share.
max
-
Max -
zmoelnig＠iem.at