Skip to main content

Can OpenGL And OpenCL Overhaul Your Photo Editing Experience?

Q&A: Under The Hood With Adobe

No vendor commands more respect or has a longer pedigree in the photo editing world than Adobe, so we felt it important to get an in-depth developer’s look at OpenCL from someone with extensive knowledge of how the Photoshop is designed and how it evolves across versions. Russell Williams is the principal scientist and architect on Adobe’s Photoshop team. Look closely and you’ll see that his is the third name listed on the Photoshop CS6 splash screen. His job is to handle the program’s technical direction and make decisions on which technologies should be used, how much focus should be put on them, and how the team is going to make it happen.

Tom's Hardware: From dual-thread support to OpenGL, Photoshop has a long history of adopting new acceleration optimizations. But you can’t adopt everything. What decision process do you use when weighing new acceleration options?

Russell Williams: We don't have a single process. One important thing is that we have a fixed amount of resources. We have a certain amount of time. The team is a certain size. Each time we go through what will be in the next version, performance is one of the things that has to be traded off. Just like any new feature, we evaluate how much bang for the buck we can get. For instance, improving start-up time is not a sexy performance issue, but it affects every user and has a huge impact on perceptions of how fast Photoshop is. It also affects productivity—you don't need to have a break in your thought process while waiting for the app to launch.

Tom's Hardware: With CS 6, we’re seeing the first bits of OpenCL creeping into Photoshop. From the development side, how long did it take to integrate that support? Hasn’t OpenCL been around long enough for it to have at least started in 5.5?

Russell Williams: We usually don’t implement major new features or functions in most dot releases (such as CS 5.5). So, if you go back to CS5, that was shipping in spring 2010, but that means we were designing and implementing features starting in late 2008. OpenCL wasn't maturing and didn't have cross-platform drivers until at least late 2009, when we were already locking down into final testing mode. Thus CS6 is really the first opportunity we had to implement it.

Tom's Hardware: You have several APIs to choose from for accelerating features. Why pick OpenCL?

Russell Williams: One, it's an open standard and an alternative to other GPU-compute technologies like CUDA or DX Compute. The significance is that open standards work on all platforms. In particular, on Windows, you have the choice to buy one card or another card in many cases. But laptops typically don't offer that flexibility. I don't like leaving platforms behind, and it’s not feasible to rewrite each feature for each platform. If we wrote a feature in CUDA, we'd get only Nvidia cards. If we did DX Compute, we'd only get Windows and not Macs, and even both combined would still miss a big chunk of customers. So cross-platform support for both OS and graphics platforms is very important to us.

The other reason why we’d choose OpenCL and not OpenGL is—well, there's two reasons. With GPU compute languages like OpenCL, they unlock or permit the use of some parts of the hardware’s functionality, such as low-level algorithmic compute capabilities that aren't accessible through OpenGL. And secondly, OpenGL and DirectX are very much designed to do a certain thing: render 3D graphics scenes. And if you want to do anything other than render 3D graphics scenes, you sort of have to think of your problem as "how can I make this look like rendering a 3D graphics scene?" You have to do a lot of graphics setup for that. For programmers trying to accelerate some algorithm on the GPU, trying to make something like CS6’s blur feature (like PS CS6), or any arbitrary function that will go faster with GPU, the people writing those things don't have experience working with 3D graphics rendering. They aren't thinking of their problems in that way, so it's a lot more of a hurdle to use OpenGL. OpenCL gives us the promise of more widespread adoption of GPU technologies across our developers.

Tom's Hardware: There are a bunch of new features and optimizations in CS6, but only one OpenCL-enhanced feature: Blur Gallery. Not to be tactless, but why only one? Is this just a toe in the water? Or are other factors involved?

Russell Williams: You have to start somewhere. The OpenCL ecosystem is just getting there, and we don't have historical expertise in this. OpenCL availability and maturity has only recently become a reality. We intend to do a lot more with it in CS7. Also, we pay close attention to relative returns when looking for features to accelerate. Like, the eye dropper is already fast enough. You have to speed up features that really are disruptively slow to common workflows. You want to make an impact to users, not just speed uncommon things up simply because they're there.

I should add that it's not just us at the beginning of the OpenCL path. The whole industry is at the beginning of having and working with drivers that support OpenCL. When we began CS6, that support was still quite limited. 

  • ilysaml
    Now Adobe uses both CUDA and OpenCL that's superb.
    Reply
  • alphaalphaalpha1
    Tahiti is pretty darned fast for compute, especially for the price of the 7900 cards, and if too many applications get proper OpenCL support, then Nvidia might be left behind for a lot of professional GPGPU work if they don't offer similar performance at a similar price point or some other incentive.

    With the 7970 meeting or beating much of the far more expensive Quadro line, Nvidia will have to step up. Maybe a GK114 or a cut-down GK110 will be put into use to counter 7900. I've already seen several forum threads talking about the 7970 being incredible in Maya and some other programs, but since I'm not a GPGPU compute expert, I guess I'm not in the best position to consider this topic on a very advanced level. Would anyone care to comment (or correct me if I made a mistake) about this?
    Reply
  • A Bad Day
    How many CPUs would it take to match the tested GPUs?
    Reply
  • blazorthon
    A Bad DayHow many CPUs would it take to match the tested GPUs?
    That would depend on the CPU.
    Reply
  • esrever
    Would be interesting to compare the i7 ivybridge against trinity in openCL
    Reply
  • mayankleoboy1
    why no nvidia cards here?
    Reply
  • mayankleoboy1
    any CUDA vs OpenCL benchmarks?
    Reply
  • de5_Roy
    can you test like these combos:
    core i5 + 7970
    core i5 hd4000
    trinity + 7970
    trinity apu
    core i7 + 7970
    and core i7 hd 4000, and compare against fx8150 (or piledriver) + 7970.
    it seemed to me as if the apu bottlenecks the 7970 and the 7970 could work better with an intel i5/i7 cpu on the graphical processing workloads.
    Reply
  • vitornob
    Nvidia cards test please. People needs to know if it's better/faster to go OpenCL or CUDA.
    Reply
  • bgaimur
    vitornobNvidia cards test please. People needs to know if it's better/faster to go OpenCL or CUDA.
    http://www.streamcomputing.eu/blog/2011-06-22/opencl-vs-cuda-misconceptions/
    CUDA is a dying breed.
    Reply