The Mac Pro Review (Late 2013)

GPU Choices

The modern Apple is a big fan of GPU power. This is true regardless of whether we’re talking about phones, tablets, notebooks or, more recently, desktops. The new Mac Pro is no exception as it is the first Mac in Apple history to ship with two GPUs by default.

AMD won the contract this time around. The new Mac Pro comes outfitted with a pair of identical Pitcairn, Tahiti LE or Tahiti XT derived FirePro branded GPUs. These are 28nm Graphics Core Next 1.0 based GPUs, so not the absolute latest tech from AMD but the latest of what you’d find carrying a FirePro name.

The model numbers are unique to Apple. FirePro D300, D500 and D700 are the only three options available on the new Mac Pro. The D300 is Pitcairn based, D500 appears to use a Tahiti LE with a wider 384-bit memory bus while D700 is a full blown Tahiti XT. I’ve tossed the specs into the table below:

Despite the FirePro brand, these GPUs have at least some features in common with their desktop Radeon counterparts. FirePro GPUs ship with ECC memory, however in the case of the FirePro D300/D500/D700, ECC isn’t enabled on the GPU memories. Similarly, CrossFire X isn’t supported by FirePro (instead you get CrossFire Pro) but in the case of the Dx00 cards you do get CrossFire X support under Windows. 

Each GPU gets a full PCIe 3.0 x16 interface to the Xeon CPU via a custom high density connector and flex cable on the bottom of each GPU card in the Mac Pro. I believe Apple also integrated CrossFire X bridge support over this cable. 

With two GPUs standard in every Mac Pro configuration, there’s obviously OS support for the configuration. Under Windows, that amounts to basic CrossFire X support. Apple’s Boot Camp drivers ship with CFX support, and you can download the latest Catalyst drivers directly from AMD and enable CFX under Windows as well. I did the latter and found that despite the option being there I couldn’t actually disable CrossFire X under Windows. Disabling CFX would drop power consumption, but I didn't always see a corresponding decrease in performance.

Under OS X the situation is a bit more complicated. There is no system-wide CrossFire X equivalent that will automatically split up rendering tasks across both GPUs. By default, one GPU is setup for display duties while the other is used exclusively for GPU compute workloads. GPUs are notoriously bad at context switching, which can severely limit compute performance if the GPU also has to deal with the rendering workloads associated with display in a modern OS. NVIDIA sought to address a similar problem with their Maximus technology, combining Quadro and Tesla cards into a single system for display and compute.

Due to the nature of the default GPU division under OS X, all games by default will only use a single GPU. It is up to the game developer to recognize and split rendering across both GPUs, which no one is doing at present. Unfortunately firing up two instances of a 3D workload won’t load balance across the two GPUs by default. I ran Unigine Heaven and Valley benchmarks in parallel, unfortunately both were scheduled on the display GPU leaving the compute GPU completely idle.

The same is true for professional applications. By default you will see only one GPU used for compute workloads. Just like the gaming example however, applications may be written to spread compute workloads out across both GPUs if they need the horsepower. The latest update to Final Cut Pro (10.1) is one example of an app that has been specifically written to take advantage of both GPUs in compute tasks.

The question of which GPU to choose is a difficult one. There are substantial differences in performance between all of the options. The D700 for example offers 75% more single precision compute than the D300 and 56% more than the D500. All of the GPUs have the same number of render backends however, so all of them should be equally capable of driving a 4K display. In many professional apps, the bigger driver for the higher end GPU options will likely be the larger VRAM configurations.

I was particularly surprised by how much video memory Final Cut Pro appeared to take up on the primary (non-compute) GPU. I measured over 3GB of video memory usage while on a 1080p display, editing 4K content. The D700 is the only configuration Apple offers with more than 3GB of video memory. I’m not exactly sure how the experience would degrade if you had less, but throwing more VRAM at the problem doesn’t seem to be a bad idea. The compute GPU’s memory usage is very limited (obviously) until the GPU is actually in use. OS X reported ~8GB of usage when idle, which I can only assume is a bug and a backwards way of saying that none of the memory was in use. Under a GPU compute load (effects rendering in FCP), I saw around 2GB of memory usage on the compute GPU.

Since Final Cut Pro 10.1 appears to be a flagship app for the Mac Pro’s CPU + GPU configuration, I did some poking around to see how the three separate processors are used in the application. Basic rendering still happens on the CPU. With 4K content and the right effects I see 20 - 21 threads in use, maxing out nearly all available cores and threads. I still believe the 8-core version may be a slightly better choice if you're concerned about cost, but that's a guess on my part since I don't have a ton of 4K FCP 10.1 projects to profile. The obvious benefit to the 12-core version is you get more performance when the workload allows it, and when it doesn't you get a more responsive system.

Live preview of content that has yet to be rendered is also CPU bound. I don’t see substantial GPU compute use here, and the same is actually true for the CPU. Scrubbing through and playing back non-rendered content seems to use between 1 - 3 CPU cores. Even if you apply video effects to the project, prior to rendering this ends up being a predominantly CPU workload with the non-compute (display) GPU spending some cycles.

It’s when you actually go to render visual effects that the compute GPU kicks in. Video rendering/transcoding, as I mentioned earlier, is still a CPU bound affair but all effects rendering takes place on the GPUs. The GPU workload increases depending on the number of effects layered upon one another. Effects rendering appears to be spread over both GPUs, with the compute GPU taking the brunt of the workload in some cases and in others the two appear more balanced.

GPU load while running my 4K CPU+GPU FCP 10.1 workload

Final Cut Pro’s division of labor between CPU and GPUs exemplifies what you’ll need to see happen across the board if you want big performance gains going forward. If you’re not bound by storage performance and want more than double digit increases in performance, your applications will have to take advantage of GPU computing to get significant speedups. There are some exceptions (e.g. leveraging AVX hardware in the CPU cores), but for the most part this heterogeneous approach is what needs to happen. What we’ve seen from FCP shows us that the solution won’t come in the form of CPU performance no longer mattering and GPU performance being all we care about. A huge portion of my workflow in Final Cut Pro is still CPU bound, the GPU is used to accelerate certain components within the application. You need the best of both to build good, high performance systems going forward.