Does the nMP really use both GPUs?

[rawweb]

Something that's bugged me since getting a nMP (8 core, maxed) at work a while back. I'm a video editor using two Apple Thunderbolt Displays and a TV for clients to view from a distance. Maybe someone can enlighten.

OK, in system information, the D700 puts all connected displays on one of the GPUs. I have no concept for how OS X handles multiple graphics cards, I've always assumed it just can't. Is that extra D700 just chilling, literally doing nothing? I've seen no great mind blowing boost in Adobe's suite, nor should I. As I understand, Premiere only touches the second card on encoding/exporting. I'm always disappointed while watching stats to see almost no processes taxing the GPU, it's always abundant on CPU. Also, After Effects only reports one of the cards...So, my question: The D700 that's driving all of my displays, is that the card getting used as the primary card in all of these apps? Or is software or OS somehow able to delegate use of the other card while the other guy drives video output? I've searched high and low for support documentation to backup my understanding and have found none.

Thanks!

I'm running a 12c cMP MVC GTX 770 rig at home and to my eye, I'm performing the same or better in most scenarios.

 

[Fl0r!an]

The 2nd D700 will be used only for OpenCL tasks. No CUDA because it's an AMD, no OpenGL because OS X doesn't support Crossfire.

 

[rawweb]

The 2nd D700 will be used only for OpenCL tasks. No CUDA because it's an AMD, no OpenGL because OS X doesn't support Crossfire.

Obviously it doesn't have CUDA, that's NVIDIA technology. I'm under the impression that the video card driving the displays is being used as the primary card in Adobe. Yes, no?

 

[ActionableMango]

Obviously it doesn't have CUDA, that's NVIDIA technology. I'm under the impression that the video card driving the displays is being used as the primary card in Adobe. Yes, no?

I could be mistaken, but I believe OpenGL applications use the first video card only (the ones connected to the video outputs), and OpenCL applications are able to use both.

As for Adobe, they provide a list of specific features that are GPU-accelerated. I believe those features are mostly OpenGL (thus using the first GPU only), however, Photoshop is reported to use OpenCL for some features.

For now, Apple's own software seems to be the main beneficiary of OpenCL dual GPU use. When the nMP was revealed to be an OpenCL powerhouse, some people insisted that OpenCL was the way of the future. Maybe so, but the future still seems to be quite a ways off.

 

[rawweb]

@ActionableMango, some good info, thanks! Think Metal in 'El Cap' will provide any benefit to managing GPU resources? As it stands, seems Premiere is pretty bad with asking the GPU for help outside of encoding or timeline play. My CPU usage is usually through the roof. Speaking of which, on my 12c at home, it doesn't even seem to be all that great at spreading it's wings on multiple cores.

 

[ActionableMango]

Adobe has announced that they will support Metal with their CC applications. What the difference will be in real life remains to be seen of course.

Yes most software seems poorly optimized for multicore CPU use. The only thing I've ever used that hammered all 6 cores 100% is Handbrake.

 

[rawweb]

Adobe has announced that they will support Metal with their CC applications. What the difference will be in real life remains to be seen of course.

Yes most software seems poorly optimized for multicore CPU use. The only thing I've ever used that hammered all 6 cores 100% is Handbrake.

I've been fairly disappointed with app support of multi core as well. I'm starting to think ditching my cMP and grabbing a 5k iMac would be a good idea.

JK

 

[AidenShaw]

I've been fairly disappointed with app support of multi core as well. I'm starting to think ditching my cMP and grabbing a 5k iMac would be a good idea.

It is rather ignorant to blame most apps for "not supporting multi-core".

Many apps have places where calculations depend on earlier calculations. You can't throw cores (CPU or GPU) at the problem and solve it faster.

If your problem is

sum = a1 + b1;
product = sum * c1;​

it cannot run twice as fast on a dual-core system. You can't start to calculate the product before the sum is ready - it is a serial problem that cannot be dramatically parallelized.

Many video (especially encoding tasks) on the other hand, are naturally adaptable to parallel tasks.

Most compressed video formats have the notion of "keyframes". The useful video formats use temporal (time-based) compression as well as static frame based compression (think JPEG compression for a still image). A frame in the stream is usually stored as the delta between earlier (and sometime later) frames and reference frames.

The keyframe (typically a keyframe every small number of seconds) is a static, complete frame. Subsequent frames (until the next keyframe) express the difference between frame A and frame A+1.

Encoding with multiple cores is dead simple. If your video profile has a keyframe every 3 seconds, then you launch a thread for each 3 seconds of input. If you have 16 cores and more than 48 seconds of video - it could run 16x faster.

For decoding, much the same. Do a fast scan for keyframes, and launch each keyframe group as a separate thread.

Anyway, I hope that by giving an example of what's makes it easy to exploit multi-core for an app, people may appreciate that other apps don't scale on multi-core because the algorithms have temporal dependencies - not because the developers are lazy.

There are too many posts here that imply that developers are lazy if the app doesn't run 36 times faster on a 36-core machine. (Ooops, other companies have 36 core workstations - Apple thinks that 12 core is enough.)