HandBrake GPU dependency?

I doubt it makes a difference as far as heat and noise are concerned. You could force the integrated GPU and see if it makes a difference. As long as there is no load on the GPU, it will not generate a notable amount of heat.

As to why it activates the dedicated GPU, I don't know. In the end it is OSX that decides which GPU to use, but I don't understand how it makes this decision.

 

It seems like any time the integrated GPU is use more than 5% lol.

 

Random programs call API's in the OSX system that cause it to turn the dedicated GPU on. many programs do it that don't need it (see picture: )



Basically, if you don't want the dedicated GPU on, force integrated. Just about everything works fine w/ just the integrated (i only turn it on for gaming).

----------

my MBP always runs 5-10C hotter (yes, even on the CPU) when I have the dedicated chipset on... I attribute it to the shared heatsink.

 

You're right. I just checked the idle-idle test, I forced the dedicated GPU while browsing. Power consumption goes up by some 5 W, and the CPU temperature also increased by about 5C.

Under load this should be different. If the GPU remains idle, while the CPU is fully loaded, the temperature difference should be small, but maybe still measurable. In that case usually the CPU heats up the GPU through the heatsink. Finally, when both are under load, I guess the CPU temp will be a bit higher again, due to the shared heatsink, as you pointed out.

 

I keep my dGPU turned off 95% of the time, i tell gfxCardStatus to stay in iGPU. I have ripped numerous DVD's using handbrake in iGPU and not seen any issues while ripping or playing the encoded movie.

 

It is not handbrake that turns the GPU on. OSX is does it when APIs that make use of the GPU are in use by the app.

It is not a perfect system. Use GFXCardStatus to manually turn the discrete GPU on and off.

 

That's what most of us do. However, I take issue with the term "unreliable." IMHO it's completely reliable. When a program calls an API that OSX tags to turn on the dGPU, that GPU turns on. it's done on the "err on the side of safety" method, probably, to make sure there's always enough power to run what the user needs.

 

The chrome browser had this issue that it would immediately trigger a switch to the dedicated GPU. A recent update fixed this issue.

It's hard to point a finger and blame someone. Handbrake is probably written such that it makes best use of the available resources. For Chrome it was a big issue since it reduces battery life compared to Safari. I'm not sure if the handbrake devs will care enough about this to modify the program.

 

whoa you're right. i just realized that chrome doesn't swap me to the dedicated GPU anymore. however, sparrow, etc. still do

 

Handbrake works the way it works. The real question is why Apple decided that those particular APIs required the DGPU. I'm sure they had their reasons but the issues seems to be present across many apps so this method of GPU switching definitely needs some work.

At this point, I'm thinking the NVidia Optimus of saving application profiles would be nice for those users willing to tinker a bit.

 

I did a bit of digging into google chrome, to find out how they managed to improve the behavior. It seems in the end they did need help from Apple to get rid of this issue. They probably told google which OpenGL functions not to call.

In the end I think the current implementation of the automated graphics switching is too aggressive, at least for laptops.

I recently played a bit with GUI programming using kivy, a platform independent python GUI framework. It is based on OpenGL, and of course, even the dumbest "hello, world" application will fire up the dedicated GPU. I'll probably look a bit more into cocoa/objC next...

 

if you like that idea, you're welcome to reach out to the developer of the program. I've emailed him; I know he will reply and tell you what he thinks of his idea.

 

I hope that eventually Apple will optimize the switching behavior. The net effect of the current state is a reduced battery life for most users. The forum community is a small subset that has a much deeper understanding of what is going on with their machine.

Apple advertises 7 hours of wireless web browsing, which for most people does include watching a youtube video here and there. If that brings the overall lifetime down to 4-5 hours, this is clearly not satisfactory.

On the other hand, it should also give software developers some thinking. Using all available system resources might not be optimal for something as simple as a web browser. And I would be happy if games would implement a maximal frame rate setting - I'm perfectly happy with 30 fps, and I would be happy to get less fan noise while playing.