OpenCL Support Coming To Adobe Premiere Pro for Windows
by Ryan Smith on April 5, 2013 1:45 PM EST
Taking place next week is the National Association of Broadcasters’ annual trade show, NAB 2013. Though most of the announcements coming out of NAB are for highly specialized products – rackmount video encoders, broadcast-quality software, etc – there are usually a few announcements applicable to the wider world. And Adobe and AMD are getting the jump on one of them with an early announcement of OpenCL support for Premiere Pro.
Premiere Pro is Adobe’s popular non-linear video editor (NLE), which in version CS5 (2010) added support for a collection of GPU-accelerated effects with Adobe’s Mercury Playback Engine. However at the time support was limited to NVIDIA cards due to the use of CUDA, leaving AMD out in the cold, due in part to the fact that Adobe was not satisfied with the state of OpenCL at the time. On the Mac this changed somewhat in CS6 when Adobe added OpenCL support for some (but not quite all) effects, while the PC version of CS6 continued to be CUDA powered.
Jumping forward, with the yet-to-be named upcoming version of Premiere Pro – currently dubbed Premiere Pro CS Next – Adobe is bringing broader OpenCL support to the Windows market, and in effect finally enabling hardware processing on AMD GPUs. As is often the case, AMD has been working directly with Adobe to get OpenCL integrated into Premiere Pro, and in fact today’s announcement comes by the way of AMD rather than Adobe. Adobe for their part isn’t saying much about Premiere Pro Next at this time – traditionally Adobe saves that for their own events – but at a minimum it looks like OpenCL is coming to parity with CUDA (or close enough). Though with Adobe consistently working to expand their usage of GPU processing and having more than a year to work with AMD’s GCN architecture, it will be interesting to see if Premiere Pro CS Next will add support for new effects, on top of OpenCL support for their existing GPU accelerated effects.
Anyhow, for AMD this is of course a big deal. While some other NLEs like Sony Vegas have supported hardware accelerated effects with their cards for some time, Premiere Pro represents a sizable part of the NLE market that they were previously locked out of. Especially since this lets AMD leverage their APU advantage, including both the consumer A-series and the rarely mentioned FirePro APUs. That the A-series is being supported is actually a big deal in and of itself since Premiere Pro CS6’s CUDA path only officially supports a small number of high-end NVIDIA consumer cards, so this marks a major broadening of support on Adobe’s part.
Finally, AMD has a blog up offering a sneak peek at performance, though as with any vendor-published benchmarks it should be taken with a grain of salt. Performance aside, it’s interesting to note that it looks like Adobe will be keeping their CUDA code path, as AMD’s test configurations indicate that the NVIDIA cards are using the CUDA code path even on Premiere Pro Next. Having separate code paths is not all that unusual in the professional world, as in cases like these it means each GPU family gets an optimized code path for maximum performance, but it does mean Adobe is putting in extra work to make it happen.
Source: AMD
Facebook
Twitter
RSS
23 Comments
View All Comments
mayankleoboy1 - Friday, April 5, 2013 - link
Why not make it even more faster, and use more power ?geniusloci - Saturday, April 6, 2013 - link
mayankleoboy1: are you really this stupid?CiccioB - Wednesday, April 17, 2013 - link
Your answer is stupid, not his question.You should say why it is not possible to have faster results using more of the available GPU computational power. If it is there, why not exploiting it?
But I suppose you can't come with a sensible answer, and that's why you can just swallow all AMD's PR bla bla without understanding anything about its (not) relevance.
mayankleoboy1 - Friday, April 5, 2013 - link
Even on openCL, NV and AMD have different implementations. So a really optimized common code is not possible. Externally it may look like there is a single code for both, internally, the code does a hardware check to see which GPU is in use, and uses different codepath for different manufacturer.HighTech4US - Saturday, April 6, 2013 - link
Ryan: Can we get a Head-to-Head review with both AMD and Nvidia products?Testing AMD with OpenCL and Nvidia with both OpenCL and CUDA.
geniusloci - Sunday, April 7, 2013 - link
There's absolutely zero need for that. AMD destroys Nvidia in OpenCL.And 6xx series Nvidia cards suck at CUDA as well.
HighTech4US - Sunday, April 7, 2013 - link
And we all should bow down to you the "AMD Fanboi God" as all knowing.Not going to happen.
What you seem to be saying is please, please Mr Ryan don't do one-on-one tests against Nvidia for you may find proof that AMD's constant PR about OpenCL doesn't meet the hype.
Just like the "CrossFire is Broken" problems AMD is currently having were found out by testing AMD's CF against Nvidia's SLI.
http://www.pcper.com/reviews/Graphics-Cards/Frame-...
AMD Fanbois (like yourself) seem very afraid of direct testing of Open Standards like OpenCL. That alone should be enough of a reason to tests between AMD and Nvidia.
TheJian - Monday, April 8, 2013 - link
Yes, I'd like to see AMD tested vs NV with each running their respective fastest implementation. Of course this is OpenCL only for AMD (no cuda, but could also be OpenGL), and I'm guessing for NV Cuda will run quicker (but again, could be opengl is faster-but guessing always cuda where cuda is an option-which it is for all major rendering/content creation apps). They need to be compared. Tom's always shows OpenCL but acts like Cuda doesn't exist. Reality is, OpenCL isn't very useful so far except for free crap that means nothing. Nobody makes money folding@home...LOL. So few do bitcoin mining it's pointless to even benchmark this. The Civ5 benchmark doesn't tell us much about compute either, as it's just an example of something that COULD exist if more game makers followed this path. I'm not sure why sites like Anandtech refuse to do benchmarking of stuff like Blender, Adobe (take your pick of the apps in CS suite), Vegas, Solidworks, ProE, cadds 5, heck the list is long of apps with opengl/cuda options. OpenCL is slowly getting added to things, but ignoring all of the apps pros use daily just because they haven't caught the OpenCL bug yet is ridiculous and disingenuous to your readers. When was the last time Anandtech did a cuda test vs. anything else? Heck I wouldn't even care if they did it with the fastest app per card. Like rendering something in Vegas for AMD and Premiere for NV (whatever, insert best app for both). If you can rip or something in one app much faster than another you could test whatever you find to be the best app/api combo per gpu maker. If I had an NV card at home and wanted to do some movie making or something I'd seek the best cuda enabled app for whatever I'm trying to do. I'd do the same if I owned AMD at home (which I do currently). As long as quality/results were comparable I'd choose the fastest one I could get for my gpu.If you're going to say something like "but at a minimum it looks like OpenCL is coming to parity with CUDA (or close enough)." You should have to prove that with benchmarks of one vs. the other. I'm seeing Ryan's love affair with AMD coming through again as there is no proof AMD's implementation will be at parity (or even close enough) with Cuda. This is AMD fanboy comment based on an AMD press release at best with next to nothing backing the statements from AMD or Ryan. Let me know when you test it, or Adobe shows some benchmarks showing AMD/OpenCL blowing away their same app tested in Cuda/NV. This should already be part of your benchmarking of gpu's here anyway instead of folding@home/bitcoin crap nobody does. Only 163,000 users have folding@home installed out of what, 352mil computers sold each year? Why bother benching that? Even less can be said about users bitcoin mining. Both things run up your electric bill and get you nothing (botnets make money on mining, not single home users these days).
http://folding.stanford.edu/
No love for folding, as most of us aren't stupid enough to bloat our electric bills for the next great pill or cancer solution which company X will get rich from not US :) I get an expensive warm and fuzzy feeling NOTHING more.
Also, NV can always turn on support for all cards if they desire it to stop home card losses. Though I'd argue they probably don't care as any pro or company will cough up the money for a REAL card with ECC, backed drivers etc for professional content crap. You don't set your Pixar rendering dept for your next movie up on radeon 7970's for example. You buy Tesla's, Quadro, FireGL's etc. There's a reason pro cards exist and cost what they do. But you don't need a pro card to benchmark Adobe CS on AMD/NV and the same can be said about many apps supporting opengl & cuda already. CUDA works with all Nvidia GPUs from the G8x series onwards, including GeForce, Quadro and the Tesla line. They own 65% of the discrete market, so why act like it doesn't exist?
CiccioB - Wednesday, April 17, 2013 - link
It all depends on the type of work you are doing.If you run one of those silly single operation benchmarks, you can come up with results that are much faster on AMD than on Kepler. If you run real complex work, where all the architecture as a whole is stressed, it is most probable that nvidia solutions are going to surpass AMD's one even using less power.
GK104 is the most efficient GPU for integer and SP calculations (in fact they made a Tesla card for it as well, clearly showing that there's a market out there that is interested in integer and/or SP calculations other than the DP one), GK110 is the most efficient solution for DP calculations.
That's what the professional benchmarks on HPC state.
You may continue to believe in anything else that makes you feel better, though. Even that this limited OpenCL support a couple of year later with respect to the competition has any meaning,
B3an - Sunday, April 7, 2013 - link
I'd hope they also support After Effects with OpenCL. That can be slow as **** even on the very fastest, and overclocked, hardware.