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:

Mac Pro (Late 2013) GPU Options
  AMD FirePro D300 AMD FirePro D500 AMD FirePro D700
SPs 1280 1536 2048
GPU Clock (base) 800MHz 650MHz 650MHz
GPU Clock (boost) 850MHz 725MHz 850MHz
Single Precision GFLOPS 2176 GFLOPS 2227 GFLOPS 3481 GFLOPS
Double Precision GFLOPS 136 GFLOPS 556.8 GFLOPS 870.4 GFLOPS
Texture Units 80 96 128
ROPs 32 32 32
Transistor Count 2.8 Billion 4.3 Billion 4.3 Billion
Memory Interface 256-bit GDDR5 384-bit GDDR5 384-bit GDDR5
Memory Datarate 5080MHz 5080MHz 5480MHz
Peak GPU Memory Bandwidth 160 GB/s 240 GB/s 264 GB/s
GPU Memory 2GB 3GB 6GB
Apple Upgrade Cost (Base Config) - +$400 +$1000
Apple Upgrade Cost (High End Config) - - +$600

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.

The PCIe Layout Gaming Performance


View All Comments

  • Ppietra - Friday, January 3, 2014 - link

    An object with black color only implies that it absorbs visible light. Thermal radiation is mostly infrared not visible light, so being black has no consequence since there is nothing emitting visible radiation internally. Externally the surface is very reflective so no problem there either - not that there would be one it wasn’t reflective Reply
  • cosmotic - Tuesday, December 31, 2013 - link

    It would be nice to see storage performance of the Mac Pro SSD against RAID on mechanical disks and SSD disks from a previous Mac Pro model. Reply
  • cosmotic - Tuesday, December 31, 2013 - link

    Including IOPS Reply
  • acrown - Tuesday, December 31, 2013 - link

    The early 2008 Mac Pro does not support hyperthreadimg as your charts indicate. Of course I could just be doing something wrong with mine... Reply
  • acrown - Tuesday, December 31, 2013 - link

    Stupid onscreen keyboard. I meant hyperthreading of course. Reply
  • Anand Lal Shimpi - Tuesday, December 31, 2013 - link

    Whoops, you're right! Fixed :) Reply
  • acrown - Tuesday, December 31, 2013 - link

    Great article by the way. I'm so on the fence about whether to get one to replace my current Mac Pro.

    The read is tempting me more and more though...
  • ananduser - Tuesday, December 31, 2013 - link

    It's actually simple, it's the best OSX workstation for seemingly only Apple software that actually makes full use of the GPU setup.

    If your workflow revolves exclusively around FCX, it is the only workstation you'll need. If you're an average consumer wanting a powerful OSX machine you'd better get a consumer oriented imac.

    PS: No need for me to mention that if you'll need CUDA and Windows then it's a bad buy.
  • akdj - Wednesday, January 1, 2014 - link

    I'd expect OpenCL to become more and more and MORE ubiquitous as time marches on and Moore's law in relation to CPU slows...and more computing can be taken care of via screaming fast GPUs. Again. Early adopters. But CUDA/Windows options are aplenty. Just more expensive and without twin GPUs. Without PCIe storage. And.....oh yeah, their Windows boxes. At least with the MP you can run Windows...and perhaps, as we saw Adobe so quickly do with HiDPI support post rMBP release (along with hundreds of other apps and software companies)---hopefully Windows 8.2/9.x realizes the more significant 'all around' gains utilizing OpenCL (nVidia too?) than the very, VERY select software titles that take advantage of CUDA....and when they do, it's primal in comparison to what OpenCL opens the doors for. Literally. Everything Reply
  • moppop - Wednesday, January 1, 2014 - link

    Considering CUDA is a GPGPU API there's no door that OpenCL opens that CUDA can't fact, you could say that CUDA opens more doors on an Nvidia GPU. Nvidia also supports OpenCL since it was among the parties to help expand the api spec, but make no mistake, their flagship is CUDA.

    Aside from shunning Nvidia to market-segments whose software will be at least CUDA-accelerated (if there's GPU accelaration at all), my main beef with the Mac Pro, however, is that there are artificial limits placed by the design. Namely 1 CPU socket and only 4 DIMM slots.

    For VFX/3DCG pros, the reality is that GPU rendering simply isn't there yet. Your PRMan, Mental Ray, V-Ray (not real-time V-Ray), Arnold, and Mantra renderers are still very much in the CPU world. When professionals buy a machine they need it to work now, and not 5 years from now. While the Mac Pro certainly appeals to portions of the pro market-segment, it was a simply foolish reason to castrate the Mac Pro.

Log in

Don't have an account? Sign up now