Apple's recent release of Mac OS X 10.6 Snow Leopard sees some of the operating system's most significant updates to 3D functionality in years, with extended 64-bit support, pervasive multi-threading via Grand Central Dispatch and a wider role for GPUs via OpenCL among the new features. Here, independent developer Chilton Webb tells 3D World what these changes mean for 3D artists and software publishers alike.

Read more on Snow Leopard‘s impact on 3D in 3D World issue 122. To order your copy, visit www.myfavouritemagazines.co.uk

3D WORLD: What do you think of Mac OS X Snow Leopard in terms of 64-bit memory addressing, Grand Central Dispatch and OpenCL?

CHILTON WEBB: Snow Leopard is the first real incarnation of a series of ideas that Apple had originally tossed around during the early days of Leopard. Many of the really huge things in Snow Leopard, like pervasive OpenCL processing and Grand Central Dispatch, were present [in Leopard developer briefings] as far back as 2006. The problem was that to get developers and their apps to the point where Snow Leopard even made sense, a ton of other things had to come first.

They had to create the basic 64-bit architecture upon which they could build their threading architecture. They had to create an efficient way to handle threading and memory management simultaneously. They had to create an architecture that allowed GPUs and CPUs to talk. And, most importantly, they had to do this in a way that would entice developers to buy into it. They had to dangle a carrot, so to speak.

In the olden days, if a developer did anything with threads, you were probably going to end up using pthreads. So you‘d go out and buy these crufty old books from used book stores, and learn as much as you could. If you were going to use massive chunks of memory, you‘d better get comfortable with malloc and its cronies, and yet more really old programming books. You see, the lower level technology really has not changed in the last 10 years at least. Apple realised that to push the threading architecture and the memory architecture to the point where they can do some really fancy tricks under the hood, they had to convince developers to stay out of that lower-level code.

That‘s what we‘re looking at with NSOperation in Leopard. It‘s a higher-level abstraction of threading, and it‘s easy to implement. You get a highly efficient threading architecture, great memory management, and it fits Cocoa design patterns like a glove. Maybe it‘s not as fast as you could get it with pthreads and a lot of effort, but it‘s fast enough. So who would want to write pthread code when NSOperation is so much easier, and so much more straightforward? And there it is: that dangling carrot.

As a developer, I‘ve just decreased the amount of effort I had to expend to get a robust, straightforward threading architecture, but it requires Leopard. Then, without any modification to my code, Leopard users who upgrade to Snow Leopard will see a potentially massive speed increase. Win-win, the kids call it.

3DW: How will they benefit end users?

CW: Snow Leopard will be the single most important release of Mac OS X so far, for Mac users in the 3D industry. Put another way, if you have a brand-new Mac, and you routinely find yourself waiting for something to finish, then you will want Snow Leopard. It won‘t make everything happen in real time, but it‘s the absolute best investment you can make, outside of buying a faster Mac. Plus, it‘s dirt cheap.

Of course, I‘m biased, right? The only people who drink more Apple Kool-Aid than Mac fanboys are Mac developers.

3DW: Grand Central allocates threads across multi-core machines. Most 3D apps are already multi-processor aware, so does GC make development easier, and do we get performance gains by having an efficient dispatch system built into the OS? How does this compare with writing your own multithreading software – will developers use it?

CW: Writing a multi-processor aware app was never hard. Writing a multi-processor aware app that is fast and stable: that‘s hard. Writing a multi-processor aware app that elegantly scales upward on hardware you‘ve never seen: that‘s ridiculous.

If you owned a bakery, and you wanted to sell more bread, you could hire more chefs. But if you still only bake one loaf at a time, no matter how many chefs you have, your throughput is the same. Claiming your app was multi-processor aware, for many apps in the industry, was exactly this. Any speed benefit was probably due to the fancy new hardware you bought to support the fancy new app, which was now ‘multi-processor aware‘.

To see any kind of real performance gain, as a developer, you‘d spend a lot of time in performance-testing tools. And you‘d spend a lot of time debugging, when things went south. Instead of one cook handling one loaf at a time, you were now instructing two, four or eight cooks who all want materials, cutting boards and the oven at the same time.

What Apple did with NSOperation and Snow Leopard was (to stretch the analogy) tell you that they would take over the bakery, and fill it with as many chefs as they could find. All you have to do is tell them how many loafs you want, and what you want them to be made of. They‘ll handle the rest.

In Snow Leopard, if you‘re already using NSOperation, your app will instantly scale across multiple CPUs and GPUs. That means I can write an app on a dual-core MacBook and be reasonably sure that the end user, with their multi-core, multi-CPU, multi-GPU Snow Leopard beast, will see far better results than anything I could possibly come up with, short of trying to write the CUDA, threading, and memory management code myself.

If I were writing a 3D app right now (and I might be), I can tell you that I‘d put zero time into any of that stuff myself. As I was told by an Apple engineer at WWDC a few years ago: “Whenever possible, lean heavily on the Cocoa frameworks. There are smarter people than you or I, working on these problems, night and day.”

3DW: OpenCL is Apple‘s take on GPGPU, a standardised approach to parallel processing using GPUs. Everyone is jumping on the CUDA bandwagon with real-time raytracers and so on, but what kind of operations will it be used for in 3D?

CW: It‘s hard to say how it‘s actually going to be used in 3D. We‘ve all seen these tech demos from years ago, where some video card manufacturer would make some tiny app that would generate an entire world, with rain, in 3D, and fly through it, in real time, with shadows, mip maps, radiosity, buzzword x, buzzword y, and buzzword z. Then, stoked on the potential of what was obviously a reality now, we‘d go out and buy some high-end 3D app, and find a few months down the road that it would start choking on a scene that a first-gen XBox could handle.

The potential to see some amazing CUDA / OpenCL apps is certainly there. And it‘s never been easier for developers to adopt this technology, especially with OpenCL being managed by the Khronos Group. If we see the same widespread adoption for OpenCL that we‘re seeing for OpenGL and OpenAL, it‘s going to be amazing. Simply amazing.

OpenCL is really easy to incorporate. And its potential is outstanding. GPUs cost a fraction of CPUs, and they can perform some functions ridiculously faster than CPUs. This is like finding a button in your car that makes it run on happy thoughts. The ability to go to the store, pick up a new GPU and add it to the stack I already have, for an additional computation boost… wow.

Even if it was incredibly difficult to add, it would be worth it, from a development standpoint. But it‘s actually quite easy.

As Apple is showing in Snow Leopard, OpenCL is not just for typical 3D tasks: it can be used for a whole host of other types of normally CPU-bound processes. I think there will be a day soon when a person can double or triple the power of their desktop machine by going out and buying more video cards. If an app came out within a year that features real-time photorealistic rendering, it wouldn‘t surprise me one bit. If such an app did not come out within a year… now that would actually surprise me.

Some time next year, as we developers get older, we‘re going to start pining for the olden days, when you could do things like click a render button and go get coffee, or a meal, or just pace around for hours on end, watching a progress bar. And we‘re probably going to start making some ‘retro‘ 3D apps, that will take forever to do things like update viewports, regardless of the speed of your machine. That‘s going to be a really crappy year for 3D.

But, for at least this next year… this will be a great year for 3D.

3DW: Does Snow Leopard have the potential to affect performance of your apps compared to previous versions?

CW: It can absolutely affect performance, and in a very good way! Any moderately complex Cocoa app made just for Leopard probably uses NSOperation if it uses threading at all. It would be a little silly not to, since it‘s so easy to use. And for the user who upgrades to Snow Leopard, that will mean an instant, glorious, speed boost. All of the iLife ‘09 apps supposedly already use NSOperation. So if you‘re running one of those apps, things will be much snappier in Snow Leopard than in Leopard. And if you have a fancy video card, it will be even faster. The same holds for 3D apps that were written in Cocoa.

Additionally, there‘s a memory performance issue to keep in mind. Let‘s assume for a moment that everyone wants 64-bit apps, even if you only have a few GB of actual RAM. Being able to finish a render, even if it‘s a little slow, beats the heck out of running out of memory and crashing, right?

All of the basic apps in Snow Leopard are already 64-bit capable. And in Snow Leopard, the 64-bit versions of common frameworks are loaded first, and 32-bit versions are only loaded later, when they‘re needed. That in itself is a tiny speed boost. But it means that there are fewer actual resources being shared across essentially duplicate sets of frameworks. So even if you aren‘t running on the latest hardware, with the memory fully maxed out, you‘ll still see a performance benefit with Snow Leopard, by staying out of virtual memory paging, if you stick with 64-bit apps.

Download Conjure and Chilton Webb's other Mac apps here