Skip to main content

Can OpenGL And OpenCL Overhaul Your Photo Editing Experience?

Q&A: Under The Hood With AMD

One of our core objectives in this series on heterogeneous computing is to get a better understanding of some of the decisions surrounding OpenCL and DirectCompute. Why would a vendor choose to utilize them instead of other APIs, such as OpenGL or DirectX? What are these programming interfaces doing with data behind the scenes? What are their limits and how much untapped potential do they leave on the table?

Those are the questions you don’t see answered in marketing materials. Fortunately, we were able to corner two excellent authorities for this article and start gathering some answers. First up is Alex Lyashevsky, a performance application engineer at AMD and a senior member of the technical staff brought in from AMD’s acquisition of ATI in 2006. Lyashevsky is no talking head from marketing. He holds patents on parallel lossless image compression and the world’s first GPU-based H.264 decoder. Few people understand GPGPU computing as well as Lyashevsky, and fewer still can discuss it in the same breath as OpenCL acceleration.

Tom's Hardware: Photoshop CS6 is our headliner benchmarking app for this article, and Photoshop is no stranger to OpenGL. So why are we now getting OpenCL added into the mix?

Alex Lyashevsky: OpenGL is pretty widely used, and it actually has many of the same compute capabilities as OpenCL. However, OpenGL is targeted more towards graphics. When you run OpenGL, you usually assume there is some kind of an image or buffer you are trying to draw upon. OpenCL actually provides much more of a generic programming platform, more in the sense of computational domain. You can have an absolutely free way of defining your own computational domain instead of being attached to some kind of image or two-dimensional, pixel-based guestimation. Other than that, frankly, I sometimes encourage people to use OpenGL, because it has very good hardware-supported input buffer filtering, for example, and very efficient color buffer composting on output.

Tom's Hardware: For developers, is there a significant difference between the two APIs in coding?

Alex Lyashevsky: Programming the OpenGL shader language is a difficult thing to get on top of. OpenCL may be a bit easier for developers. You see, OpenGL assumes that you have to set up some graphic context, meaning you have to set up viewpoint, model matrix transformations, and so on. OpenGL is a graphical language, and this works well for some types of operations where graphics are related to the computation problem. But from a general programmer’s point of view, OpenGL is kind of nonsense. If they want to do data manipulation, why should they set up a triangle, viewpoint, or matrix? A more general way to program the GPU, which is enabled by OpenCL, is necessary for more widespread adoption. For example, it’s probably not very useful to use OpenGL to accelerate something like deflate and encryption in compression apps, but it is probably useful for image processing apps.

  • 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