After spending too much time waiting for effects to render on my new AddOhms Tutorialcast, I decided it was time to upgrade computers. When I went to capture a quick EAGLE video on my new MacBook Pro with Retina screen, I realized a problem with the Mac’s auto graphics chip switch. Quicktime recorded only a green Screen.
Architecture
The MacBook Pro Retina has two graphics processors. One is built-in to the Intel CPU while the other is an external chip with significantly more processing power. When on battery, I usually let the computer decide which need it needs to (hopefully) maximize battery life.
Note that I am using the phrase “graphics chip.” It really bugs me when people refer to discrete GPUs as “graphics cards.” They aren’t cards. They’re chips.
The Problem
As it turns out, certain applications (like Quicktime–a video focused application) forces the external chip into use. Which is unfortunate because using the QuickTime “Screen Capture” feature means that your screen captures turn out like the image above: a blank Green Screen. (Note: I tried a couple of versions of the third party app iShowU and it had the same issue.)
FYI, iShowU is what I generally use for capturing video for my tutorials.
The Solution
While looking at a couple of web forums, two things stuck me: 1) others have the same problem and 2) nobody had found a solution. Fortunately the few minutes you can’t use electronics during a plane’s take-off gave me time to think about what could be causing the problem. I wondered if it might be related to this switchable graphic chip stuff.
Once I was able to turn on in-flight WiFi, I downloaded “gfxCardStatus” from gfx.io. This menubar utility has two main functions. First it gives you a nice Menubar icon to let you know which chip is currently being used. It also allows you to force which chip is use. Despite Apple’s recommendations, I decided to give it a shot.
Forcing my MBP-Retina to use the internal chip (in my case Intel HD GPU 4000) I was finally able to record video.
12 Comments
I dont know how or what, but you done did it!! I actually got a green screen in my video editing software ScreenFlow after trying to load it back up, probably because the GB usage was enormous (40GB) and it was too much to handle graphically? RAM gave out?
Usually stuff like this never works, but you really helped me out, I was freaking hard…
Thank you James (I’ll keep you updated if anything else happens),
Julien
Thank you! I’ll try it.
You’re a genius and I thank you!
Thanks! This really helps.
Also: people refer to them as graphics cards because they are separate cards on (most) desktop computers. It’s pretty recent (and pretty unusual) to have two graphics chips on a single motherboard- before that if you had two graphics processors, one of them was on a separate card. Although it’s not correct in some situations, it still is correct in many situations, so I think you’ll find you’re swimming uphill on that one. 🙂
There are only a very few number of notebook computers which had graphic “cards.” They have always had discrete chips. This post was focused on notebooks.
I also hear the reference for tablets and smartphones, which don’t even have discrete chips, they are generally in the same package as the CPU.
I had the same issue. I fixed it by turning off ‘Automatic graphics switching’ under
System Prefs > Energy Saver > Power Adapter
cheers
Interesting.
What’s odd is that this same thing *should* be happening automatically in iShowU.
Any app that accesses (for example) OpenGL, while it remains open, will force the OS to select the high performance GPU. Thus, the “solution” (well, I thought it was at the time) was to have iShowU access OpenGL upon start.
You can see this in action by looking at System Information | Graphics. On a fresh boot without iShowU running, you’ll see the lower-power-integrated GPU is in use. If you start iShowU, then use CMD-R to refresh System Info, you’ll see that the high performance discrete GPU is now in use.
So I’m not sure if the above is really the solution or not (since in theory we do this in the app already – and we’ve still people who get the occasional green screen). But very keen to hear if you’ve any other insights or comments on it.
Neil I think there’s a misunderstanding here. The *problem* is that when the high performance GPU is enabled, that is when applications like iShowU only records a green screen.
So the solution above is to force the integrated GPU to be used. The fact that iShowU enables the high performance GPU is the “problem”. Maybe, “issue” is better because I don’t want to imply there is a fault with iShowU.
This is clearly a system level problem.
Now the EXACT cause is beyond me. I just know that Integrated GPU: No Green Screen. High Performance GPU: Green Screen.
Hey James!
Ah, I understand better now. Perhaps my brain wasn’t working yesterday.
Interesting. So do you get green screen *every time* you enable the discrete GPU? Not just after some elapsed time? Because here, I’ve only ever had it when the machine has a uptime of “lots”, with many other GPU intensive apps open (such as FCPX). Rebooting it fixed it (annoyingly), even though I was still using high perf GPU.
I agree that it’s a system level thing.
If you are able to reproduce this by using the high performance GPU, I’d love to get some info from you / or hook up over Skype. I have written a “munged frame” detector, which is in the product, but it’s incomplete.
The idea is that it will be able to detect this situation and abort recording; warning the user. Not ideal, but better than doing a 30m recording to find it’s green.
What it does is scan the first 50 frames of a recording to see if they are … “munged”. What I don’t know is, in the situation of green screen, if the pixels are black and being encoded as green, or if they are green, exactly what green they are.
So, if you’re magically able to make this green screen happen, I’d like to get in touch and try a couple of things on your machine (with your permission!). Possible you think?
Awesome!!!! This did the trick. Thanks a bunch.
Unfortunately, in the latest version of gfxCardStatus they have removed the ability to force to integrated mode when QuickTIme is running. For more details, see the heading “ii. integrated only mode limitations.” on this site: http://gfx.io/switching.html#power-source-based-switching (if that link doesn’t show, it’s gfx dot io then to help, and power source based switching)
Any suggestions given that revelation?
I’m not sure that this is a “new” feature. gfxCardStatus has always worked like that for me. Simply quit QuickTime (and any other dependencies), then switch to Integrated Only. To be honest, I wouldn’t have trusted switching while a application was using the discrete GPU. That would have definitely caused stability problems.