Interview: AMD Mac Graphics Division Talks Apple and Graphics Progress

As part of this special series we have had the pleasure of speaking to the CAD and 3D industries’ brightest leaders on the software side of the fence. Now we turn our attention to a critical leader on the hardware side: Chris Bentley, the division team leader of Macintosh graphics at AMD.

In the past Chris has spoken to Architosh about the detailed relationship between Apple hardware engineering and AMD/ATi, and the various details that shape the decision-making process in hardware design and the resultant performance realities for users. Our “state of the union” style series wouldn’t be complete without a serious fireside chat with Chris Bentley. He has been on the extreme inside tract of Apple’s Mac hardware engineering like no other outside Apple for many years.

So let’s get in real close and talk about Mac graphics!

AFR: (Anthony Frausto-Robledo): In your role you are on the inside track of hardware development. Can you describe to me briefly the importance AMD/ATi plays in supporting Apple’s Mac graphics hardware advances? To what degree is AMD/ATi an influence on Apple’s decisions?

CB: (Chris Bentley): Apple is relentlessly innovative both in software and hardware, and especially in the combination of the two.  I looked back over the interview we did in January 2007;  apart from being a good read, I am struck by the fact that it came out just on the cusp of Apple introducing the first iPhone.  Since then Apple has shipped multiple generations of the iPhone, the iPod Touch, the iPad, the iPad 2, the MacBook Air, and numerous laptop and desktop systems.  All of these devices are powered by OpenGL or OpenGL ES graphics.  I think it’s fairly well accepted that Apple has shipped more OpenGL accelerated devices than any one else on the planet.

AMD works closely with Apple on both the software and hardware sides.  The software we write for Apple is entirely customized for Mac OS X.  Since 2007 we have added support for the Radeon HD 2xxx, 3xxx, 4xxx, 5xxx, 6xxx chip families, and added support for OpenGL 3.0, 3.1, 3.2, encompassing over 30 new features and extensions, as well as OpenCL 1.0, 1.1, and hardware accelerated H.264 decode support in Lion.  Delivering OpenGL 3.2 and the other features in Lion required Apple and AMD engineers to work hand-in-glove for months.  On the hardware side, Apple receives regular presentations on our hardware roadmap, and for every Apple program using AMD GPUs, our hardware engineers work closely with Apple throughout the bringup and production phases.

So, I would say that we are deeply invested in supporting Apple’s innovation in graphics software and hardware.  I think the relationship is more about working together, and less about our influencing them.

AFR: For years many Mac pros have lamented the lack of GPU options and specific pro-level cards. But over the past several years Apple has done much better. What do you feel are some of the decisive factors affecting Apple’s decisions in what GPU cards to support? And how much better would you describe the situation today than say seven or ten years ago?

next page: Pro Apps and OpenGL Performance

CB: Since Apple is such a heavy user of the GPU in their own Pro apps and in Mac OS X, they are keenly aware of the power that GPUs bring to the table, and have been putting more and more GPU muscle into all their machines.  Apple’s lineup the past two years has been particularly strong.  For example this year Apple is shipping Mac Pros, iMacs, MacBook Pros and Mac Minis powered by AMD Radeon HD 5xxx and 6xxx generation GPUs.  For all these products Apple has reported 2x – 3x speedups in graphic performance over the previous models.  Review after review has commented on how strong these machines are in games and Pro app performance.  Of particular relevance to Mac professional users, several reviews benchmarking Pro apps have shown that the current high end AMD Radeon HD 5870 holds its own against bigger and considerably more expensive competitors. (see image on title graphic and below)

AFR: Yes, I have read some excellent reviews of the latest AMD Radeon cards and they are impressive in many areas. I can also see that in the latest machines (in particular the iMacs) you can now get Radeon’s with up to 2 GB of video memory…which addresses some of the issues in the reviews.

I would like to switch gears here a bit and talk about OpenGL. In the past we have spoken about Apple’s influence on OpenGL development. At that time you gave us technical examples of how they used their Pro apps to push the envelope. Do you still feel today that Apple is driving the boundaries of OpenGL or have things changed?

CB: I have recently been thinking that OpenGL is a little like the elephant in the parable about the six blind men:  OpenGL is so big and encompasses so many parts, that it’s hard to get the measure of all of it, and people who only experience part of it will give wildly divergent descriptions. Is it an API for high throughput geometry processing? Yes. Is it a games API? Yes. Is it an API for video effects? Yes. Is it a 2D compositing API? Yes. Is it a hardware access layer? Yes. Is it a hardware abstraction layer? Yes. It is all of these things.  Also, OpenGL is so rich that the possible permutations of API calls is essentially unbounded.  We run literally hundreds of thousands of test cases every day to make sure our code changes don’t break anything.  I say all this because there is simply an infinite amount of work required to achieve the Platonic ideal of the perfect OpenGL driver.  It’s not just at the boundary that there’s work to be done, but everywhere within the envelope as well.

Over the past couple of years Apple has been strengthening and refining the OpenGL implementation on the Mac and inventing new ways to leverage OpenGL in Mac OS X, and in their iApps and Pro apps.  For example, in Snow Leopard Apple created the IOSurface Framework to allow efficient sharing of graphics content between different programs.  For Lion Apple extended IOSurface to enable Launchpad and Mission Control, and also released OpenGL 3.2 support.  Another example of this kind of internal strengthening of AMD’s Mac drivers are the very large speed boosts that we delivered in the Snow Leopard Graphics Update 1.0 released in August 2010.

Those driver changes bumped us up to a higher plateau of performance, so that when Portal 2 shipped on the Mac in April 2011 it was not so surprising that high resolution performance on the Mac was largely on par with performance on Windows 7. Are we on par in every game, or at every resolution?  Not yet… remember the elephant.

As for moving technology forward, Apple continues to be a very active member of the OpenGL ARB, and given their strong position in the handheld space, they are a driving member of the Khronos OpenGL ES working group.  Apple’s pushing the envelope is especially seen in their development of OpenCL, which Apple launched with Snow Leopard.  OpenCL is an open standard, cross platform parallel programming library that developers can use to leverage the GPU for general purpose (i.e. non-graphics-related) compute tasks.  In the recently released Final Cut Pro X, Apple uses OpenCL for some of its operations.  OpenCL represents a major development effort for both Apple and AMD, and is the very definition of cutting edge use of the GPU.  On the 3D side, Lion brings us up to OpenGL 3.2.  We know we have more work to bring the AMD Mac OS X drivers up to the very latest spec.

AFR: What are some technical issues that you feel Apple could address so that its hardware is even more performance-oriented and ideal for CAD and 3D industries? What AMD/ATi technologies exist that Apple may not be employing but if it did Mac performance could go up?

next page: CPU-bound Performance and Driver Tuning

CB: Back to the parable of the elephant… there are numerous distinct paths in an OpenGL driver, and often each has a distinct performance profile, so talking about “driver performance” as if it were a single entity can be misleading.  In addition to the many paths, there are two different types of performance: a) “CPU-bound”, and b) “GPU-bound”.   To understand the “CPU-bound” case, remember that the driver consists of instructions that execute on the CPU, so here we’re interested in how many instructions does the driver need to tell the GPU to do its stuff.  You can measure CPU-bound performance if you tell the driver to draw something trivial (like a tiny flat triangle) over and over using immediate mode (glBegin/glEnd) because you’ll be exercising the entire driver stack repeatedly, without giving the GPU much to do.  The “GPU-bound” case is the reverse, where we send a trivial amount of work for the driver, like drawing one triangle, but that triangle is very large, so the GPU has to exert itself mightily to be ready for the next task.

The reason I spell this out is that, as we saw above with the Portal 2 benchmarks, the GPU-bound case is largely a solved problem for AMD graphics hardware on the Mac.  In the vast majority of the cases we are now setting the GPU up to run optimally.  Where we still have significant room for improvement is in the CPU-bound case.  To fix this we need to work with Apple to tighten up the handshaking between the Apple and AMD layers of the driver stack.  It is this underlying complexity which explains why some CAD apps run fast on the Mac, and others need further optimization:  if a Pro app is largely GPU-bound it should run as fast as possible, but if the Pro app is CPU-bound then it may lag.

AFR: This may explain why, say, Nemetschek’s latest Vectorworks 2012 is supposedly much faster at viewport and screen regeneration since it now taps the GPU for some of this work. I look forward to learning more about this by talking to specific pro CAD/3D app developers. Let’s switch gears a bit. Given the rise of iOS and the popularity of the iPad in particular do you feel that AMD/ATi can serve Apple in its graphics in this hardware area in the future?

CB: You listened to their quarterly report, didn’t you?

AFR: (laughter…) Yes!

AFR: You test lots of professional apps at AMD in addition to numerous games. These days in the graphics world, what market is pushing the performance envelop more, games or pro applications? And if both, how so? Please explain….

CB: You mentioned the magic word: “test”!  Before I answer your question, let me say something about testing… testing is everything!  Someone I worked with once said: “If it’s not tested, it’s broken.”  We run a lab with both manual testing as well as automated tests running around the clock.  The test farm has around 30 Macs representing just about every model that ever shipped with AMD graphics hardware.  Each year we run around 44,000 test runs, where each test run takes 4-6 hours to complete depending on the CPU and GPU.  Last year we ran 7,179,840 game time demos. Currently we try to review all this data manually… I’m really rooting for the rise of the machines. They’ll want to have good Mac OpenGL drivers too…

AFR: So what do you test more of than?

The honest answer to your question is that we test games much more than we test Pro apps, and in general game developers are the earliest adopters of our new features.  We have contacts in the Apple Pro Apps group, and at Adobe, Autodesk, VMWare, Luxology, Nemetschek and lots of other Pro app developers, but we hear from the folks at Valve, Blizzard, Transgaming, Feral, and Aspyr more.  My theory is that this is simply due to the longer product cycles of professional apps versus games.  Maybe this will change as developers start to use the new features exposed by OpenCL 1.1 and OpenGL 3.2 in Lion.

AFR: Well, I for one hope you are right and look forward to seeing how OpenGL 3.2 more widely adopted in pro apps on the Mac. This was another engaging and technically fun conversation. Thanks again for talking to us.

CB: You are welcome and thank you for the opportunity.

To learn more about AMD and its ATI graphics division visit them online here. To read our 2007 interview with Christ Bentley (which includes an excellent explanation of how Apple pushes the limits of OpenGL development as well as graphics differences between Mac OS X and Windows) go here.