2017 iMac i7 Throttling

[jawatkin]

Just upgraded from a 2013 i7/780m to a 2017 i7/580 and am finding that this machine is actually noticeably slower on both Compressor and FCP X renders/exports due to thermal throttling of the iGPU.

I have iStat Menus for temperature monitoring and fan control and Intel Power Gadget to monitor the frequencies and further temperature monitoring. I even have installed Turbo Boost Switcher to disable turbo boost and keep the CPU at 4.2GHz to try and keep temps down and prevent iGPU throttling.

Even if I max the fans out, the render/export starts out blazing fast, running the iGPU (GT) at 1.1GHz. After around 3 minutes, once temperature reaches 80C with fans manually set at max, it drops GT to 0.5GHz and after 15 minutes, drops it down to 0.3GHz. During this process, the temp runs around 73-75C and the iGPU never recovers to its original clock speed.

For me to render a 30:00 1080p60 H.264 in Compressor at 15,000 Kbps, it's taking 25 minutes -- whereas on my 2013 it takes 15 minutes.

What I'm wondering is: would the i5/3.8 be immune to the iGPU throttling, as others have reported it runs much cooler?

I love the retina screen, but with as many videos as I export during a day (I make videos for a living) this translates into up to an hour of extra processing time as compared to a 4-year-old machine!

 

[EugW]

Very interesting observation. So even Quick Sync encoding is causing the iGPU to overheat?

Is there a standard project that one can download from somewhere to do comparative testing of rendering speeds, with say the trial version of FCPX?

 

[jawatkin]

Very interesting observation. So even Quick Sync encoding is causing the iGPU to overheat?

Is there a standard project that one can download from somewhere to do comparative testing of rendering speeds, with say the trial version of FCPX?

Yep, the Quick Sync encoding is causing the overheating on iGPU and I would actually be happy to throttle down the CPU frequency if it meant keeping the iGPU at full board.

Not sure about a standard project, but that's a really good idea, anyone know? I should also add that it throttles down whether I use Compressor or simply "Share" within FCP X.

EDIT: I might also add, I've fallen in love with the Retina display and don't wanna go back to my 2013 display -- if the i5's suffer the same fate, anyone know about the 2015 models?

 

[Ethosik]

Do you mean CPU? Getting the iMac with the AMD 580 does not have an integrated GPU, or iGPU.

 

[jlseattle]

Yep, the Quick Sync encoding is causing the overheating on iGPU and I would actually be happy to throttle down the CPU frequency if it meant keeping the iGPU at full board.

Not sure about a standard project, but that's a really good idea, anyone know? I should also add that it throttles down whether I use Compressor or simply "Share" within FCP X.

EDIT: I might also add, I've fallen in love with the Retina display and don't wanna go back to my 2013 display -- if the i5's suffer the same fate, anyone know about the 2015 models?

I wouldn't jump off the train of the 2017 iMac just as of yet. My vote is to speak with Apple and give them your results. I bet anything that this is either a known issue or something that they will fix. I can't imagine they would let the computer perform poorly and not fix it.

 

[EugW]

Do you mean CPU? Getting the iMac with the AMD 580 does not have an integrated GPU, or iGPU.

Yes it does. All of the iMacs have Intel GPUs.

The OP actually referenced its name in the original post. The post says "GT", but to be specific, it is GT2, HD Graphics 630.

 

[tipoo]

Do you mean CPU? Getting the iMac with the AMD 580 does not have an integrated GPU, or iGPU.

Yes it does. Any Intel i series processor comes with a tacked on GPU. OP is using his for Quicksync, which is still faster (or at least more supported) than the encoder on the dGPU.



OP, thinking out loud here, but those temps don't seem that high (my rMBP 15 2015 will chug along at 99C forever), perhaps it's because the iGPU does not detect a load that it starts to reduce its own clocks, rather than thermals? What happens if you throw up a small GPU load (like an infinite browser test, IE Fish Tank for instance) and then try?

 

[joema2]

Just upgraded from a 2013 i7/780m to a 2017 i7/580 and am finding that this machine is actually noticeably slower on both Compressor and FCP X renders/exports due to thermal throttling of the iGPU....For me to render a 30:00 1080p60 H.264 in Compressor at 15,000 Kbps, it's taking 25 minutes -- whereas on my 2013 it takes 15 minutes.... it throttles down whether I use Compressor or simply "Share" within FCP X...

I own the 2013 i7/780m, the 2015 i7/M395X and 2017 i7/580 and edit professionally with them. I loaned the 2013 to another editor so I can't re-test on that easily but I have both 2015 and 2017 on my desk right now.

In general the 2015 would export from FCPX to single-pass 1080p/H264 at 3x real time rate, or 10 min to export 30 min of material. We've shot only 4k for the last two years so I don't even have that much 1080p content laying around, but I'll dig some up and test the 2015 vs 2017.

My 2017 iMac i7 exports 4k H264 long GOP material to 4k H264 at roughly 1.6x real time rate or 18.75 minutes to export 30 min of 4k material. That is roughly 3x slower than 1080p but it's 4x the data. This export rate is 3.7x faster than exporting the same content via Premiere Pro CC on the same machine because Premiere doesn't use Quick Sync on Mac.

When transcoding a terabyte of H264 4k long GOP to ProRes proxy, the 2017 is generally about 2x faster than the 2015, and 3.5x faster than a 12-core Mac Pro D700, all running FCPX 10.3.4.

Since the 2017 is so much faster in my FCPX tests, I haven't yet bothered to check for thermal throttling, but I can do that.

I suspect there's either something wrong with your machine or your test conditions have somehow changed.

In general I'd suggest you first test just with FCPX not Compressor, because Compressor has so many dials and levers to turn. The fastest way to export to H264 from FCPX is using these steps:

(1) File>Share>Master File>Settings
(2) Format: Computer
(3) Video codec: H.264 Faster Encode
(4) Resolution 1080p

 

[Ethosik]

Yes it does. All of the iMacs have Intel GPUs..

Yes it does. Any Intel i series processor comes with a tacked on GPU. OP is using his for Quicksync, which is still faster (or at least more supported) than the encoder on the dGPU

Huh. I didn't know the iMac still was using the iGPU. For example, my custom built computer has an i7 but the iGPU is disabled in the BIOS since it has a dGPU. Is there a way to disable auto-switching so it always uses the dGPU like the laptops?

 

[EugW]

Huh. I didn't know the iMac still was using the iGPU. For example, my custom built computer has an i7 but the iGPU is disabled in the BIOS since it has a dGPU. Is there a way to disable auto-switching so it always uses the dGPU like the laptops?

I presume Apple is just using it in the iMacs for Quick Sync and not much else.

And in the laptops, I'm no expert but AFAIK, the "disabled" Intel iGPU is still being used for Quick Sync.

https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

 

[Ethosik]

I presume Apple is just using it in the iMacs for Quick Sync and not much else.

And in the laptops, I'm no expert but AFAIK, the "disabled" Intel iGPU is still being used for Quick Sync.

https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

Odd. So does the iMac act like the laptops and uses the iGPU until more power is needed then switches to the 580? Is it an Iris Pro iGPU?

 

[tipoo]

Odd. So does the iMac act like the laptops and uses the iGPU until more power is needed then switches to the 580? Is it an Iris Pro iGPU?

It uses the HD Graphics 630

https://ark.intel.com/products/97144/Intel-Core-i5-7600K-Processor-6M-Cache-up-to-4_20-GHz

As EugW said, on their desktops it seems the IGP is tapped into only for QuickSync, while the dedicated GPU stays on for everything else, unlike the laptops that switch.

 

[joema2]

....I don't even have that much 1080p content laying around, but I'll dig some up and test the 2015 vs 2017....

OK I imported 30 min of H264 1080p/29.97 material from a Canon 5D Mark III, then exported it from FCPX 10.3.4 as single-pass H264 1080p/29.97 at 20 megabits/sec. I tested both 2015 and 2017 iMac 27 i7:

2015 iMac 27, 4Ghz i7-7600K, 32GB, 1TB SSD, M395x: 5 min 40 sec. Peak CPU temp: 93C, peak fan speed: 2400 rpm

2017 iMac 27, 4.2Ghz i7-7700K, 32GB, 2TB SSD, RP 580: 4 min 49 sec. Peak CPU temp: 92C, peak fan speed: 1700 rpm

So the 2017 exported 1800 seconds of H264 1080p material in 289 seconds, which is 6.2x faster than real time. It was definitely quieter and significantly faster than the 2015 model for this test.

However it's not quiet all the time. I just finished transcoding a terabyte of 4k H264 material to ProRes proxy. This took several hours and it was at about 2700 rpm almost the whole time. The 12-core Mac Pro D700 I tested would have done that very quietly but it would have taken much longer since it doesn't have Quick Sync.

 

[jawatkin]

I suspect there's either something wrong with your machine or your test conditions have somehow changed.

In general I'd suggest you first test just with FCPX not Compressor, because Compressor has so many dials and levers to turn. The fastest way to export to H264 from FCPX is using these steps:

(1) File>Share>Master File>Settings
(2) Format: Computer
(3) Video codec: H.264 Faster Encode
(4) Resolution 1080p

Thank you for all the details and your experiences. I just exported a 20:00 1080p/60 video using these exact settings in FCP X and it took a little over 14 minutes. It really does fly for the first 70% and then when the throttling hits, really slows down.

I think, if it had been a longer video, it would've "stepped down" again, but in this case it "only" cut the IGP frequency down to 50%, which, since we're using QS, means 50% slower.

Here's a link to an imgur gallery showing the behavior. It's chronologically backwards, so the encode starts at the bottom and finishes at the top: http://imgur.com/a/r6sN3

 

[joema2]

Thank you for all the details and your experiences. I just exported a 20:00 1080p/60 video using these exact settings in FCP X and it took a little over 14 minutes. It really does fly for the first 70% and then when the throttling hits, really slows down...

There is either something wrong with your computer, or you have some computationally intensive effects, or the codec itself is somehow computationally difficult. Although we commonly speak of "H264" there are many variations, each with varying CPU demands. It is 60 fps but that seems unlikely to account for your machine exporting 1080p material 4.4x slower than mine.

What kind of camera is this material from? Can you post some sample material on DropBox?

 

[jawatkin]

There is either something wrong with your computer, or you have some computationally intensive effects, or the codec itself is somehow computationally difficult. Although we commonly speak of "H264" there are many variations, each with varying CPU demands. It is 60 fps but that seems unlikely to account for your machine exporting 1080p material 4.4x slower than mine.

What kind of camera is this material from? Can you post some sample material on DropBox?

So, I've done some more testing and I think I've figured out what's happening. Remember, it happens both in Compressor and FCP X Share, so it must have something to do with a bug at OS level.

The material is H.264-encoded via an Elgato HD60, it's gaming footage. Generally these gaming session can last quite a long time and then I edit them usually with simple jump cuts when there's action and cut out the dead space and boring stuff. No effects at all.

I recorded a 35-minute segment and did some random jump cuts and cut it down to exactly 30 minutes today. Rendered perfectly with full IGP power in a shade over 9 minutes, which is what I was expecting.

Went back to the project giving me an issue [a 2.5-hour single H264 source file, cut down to ~28:00] and at the 20% mark, it cuts the IGP power every time and it turns out that it has something to do with the length of the jump cuts. In the beginning of the footage, the jump cuts are quite close together and then there's a good 20-minute gap where I've cut completely out and then a few minutes I keep and then another 30-minute gap cut out and that seems to be where it 'sticks' and never recovers.

If I take the same source and just stretch it out to 30 minutes, cutting off the last 2 hours, leaving the dead space in, the render is rock-solid with no slowdowns.

Here's how the footage looks uncut and cut (well the first hour of the raw footage, recording itself is 2hr+): http://imgur.com/a/Y1Khd

I'm not using any proxy or optimized media, but the footage is stored on a pair of external SSDs running in RAID0.

EDIT: Since I've got both the project and source files on my external SSD array, I plugged it into my 2013 and gave the same project a run [the 2.5 hour -> ~30:00 project] and it had the exact same behavior. I tried putting it into a new Library and Project, same deal. The 2013 cuts power (although frequency stays the same, I think that's just a function of the 4771 vs 7700) at the same point(s) during the render. On the 2013, it took 31:27 to render and on the 2017 it took 23:17. So the new one is definitely faster than the 2013.

I realize that I am probably an edge-case, but I think this is something I should report to Apple?

 

[joema2]

....The material is H.264-encoded via an Elgato HD60...these gaming session can last quite a long time and then I edit them...with simple jump cuts...cut out the dead space and boring stuff. No effects at all....back to the project giving me an issue [a 2.5-hour single H264 source file, cut down to ~28:00] and at the 20% mark, it cuts the IGP power every time....has something to do with the length of the jump cuts. In the beginning of the footage, the jump cuts are quite close together and then there's a good 20-minute gap where I've cut completely out and then a few minutes I keep and then another 30-minute gap cut out and that seems to be where it 'sticks' and never recovers....If I take the same source and just stretch it out to 30 minutes, cutting off the last 2 hours, leaving the dead space in, the render is rock-solid with no slowdowns.....I plugged it into my 2013 and gave the same project a run [the 2.5 hour -> ~30:00 project] and it had the exact same behavior. I tried putting it into a new Library and Project, same deal. The 2013 cuts power (although frequency stays the same, I think that's just a function of the 4771 vs 7700) at the same point(s) during the render. On the 2013, it took 31:27 to render and on the 2017 it took 23:17. So the new one is definitely faster than the 2013....I realize that I am probably an edge-case, but I think this is something I should report to Apple?

Your 2017 is about 1.5x faster than your 2015, so at least that's good. As you said it's nothing unique to the 2017 model.

I dug up 1 hour of 1080p/60 (actually 59.94 fps) H264 material from a Canon XA25 and exported that from a 1080p/59.94 timeline to single-pass 1080p H264. This was four 15 minute clips. That exported in 18 min 24 sec, which is slower than my 1080p/29.97 test but still 3.3x faster than real time. Max fan speed was about 1800 rpm and max CPU temp was about 90C.

I then took five 15 min clips and added many cuts (probably 50) to bring the total timeline down to 30 min. The timeline looked similar to yours, but with more cuts. That exported to single-pass H264 in 9 min 10 sec, exactly the same rate as the 60 min timeline with no cuts, just four clips. Both of those are about 3.3x faster than real time, whereas your problem case was only 1.3x faster than real time.

There seems to be some anomaly about the Elgato-encoded material that in combination with certain edits makes this happen. It would be good to inform Apple, but they (and any software developer) prefer a portable replication scenario.

If you could somehow reproduce it with a little Elgato clip that you then duplicated in the timeline to reach 30 min that would be better. At least that could possibly be uploaded somewhere.

I don't know about the HD60 but some Elgato units have many different H264 encoding options. It's possible the resultant material does not adhere to some H264 standard and it's triggering a bug in FCPX. There are many different internal encoding parameters for interframe H264, such as GOP length, number of I, P and B frames, type of entropy encoding, etc.

For performance reasons video software usually cannot do extensive validity checks on material and must simply assume it's correct. This in turn can expose bugs or anomalies in the software if the material is somehow subtly malformed.

Another possibility is the combination of H264 encoding parameters plus the edits are just naturally computationally difficult and it would be slow in HandBrake, Premiere Pro or anything else. If you could somehow devise a portable replication scenario I could test those.