AMD today announced continued leadership in driving OpenCL adoption with availability of the AMD APP SDK 2.7, featuring the first conformant implementation of OpenCL 1.2 and comprehensive support for C++. The new SDK expands the OpenCL application ecosystem by providing developers a powerful, cross-platform solution to unlock the performance of AMD GPUs, APUs, and multi-core CPUs with the added C++ wrapper API and AMD's C++ kernel language for greater efficiency, improved productivity and application robustness.

"AMD continues leading the OpenCL movement, as demonstrated with the release of our latest SDK featuring the industry's first fully-conformant OpenCL 1.2 implementation," said Manju Hegde, corporate vice president, Heterogeneous Applications and Developer Solutions, AMD. "Our latest development tools empower developers to more easily harness the power of heterogeneous computing to help improve the user experience by making it easy to write applications that can take greater advantage of the compute capabilities of AMD's leading CPUs, GPUs and APUs."

Support for the second generation AMD A-Series APUs and AMD Radeon HD 7000 Series GPUs is now available with the AMD APP SDK 2.7. The new SDK also includes updated versions of gDEBugger, APP ML, APP profiler and kernel analyzer updates. For complete details on the AMD APP SDK 2.7 features, capabilities and support, visit the AMD Developer blog or download the AMD APP SDK 2.7 from AMD Developer Central.

Improved simplified constructors for cl::Buffer and addition of cl::copy functions

Additional support of events when using functors

C++ Kernel language

Kernel and function overloading

Inheritance

Templates

The developer ecosystem continues to optimize applications by implementing OpenCL to leverage the unmatched level of compute processing capabilities of GPU acceleration, as more than 100 applications and games are currently accelerated by AMD APUs. Developers who want to engage in the industry's move toward heterogeneous computing should attend the upcoming AMD Fusion Developer Summit (AFDS). AFDS provides a unique opportunity to hear first-hand from, and network with, developers as part of approximately 30 sessions related to implementing OpenCL, including sessions on math libraries, open source libraries, applications and tools. More information on OpenCL 1.2 will be provided in session PT4290 and on OpenCL Static C++ in session PL3660. To learn more about AFDS, visit this page.

It's good that AMD got C++ kernel language support directly with their drivers (unlike NVIDIA where you have to use CUDA because OpenCL is technically a C99 language), but their implementation is still quite hardware-specific. This means that using their implementation will work at 100% performance on a AMD GPU, but not so much when when run on NVIDIA or Intel GPUs.

I'd definitely like to see support for OpenCL in FormatFactory, Freemake Video Converter and 7-zip, apps that i use the most. My Core i7 crunches through them fast but i'd like to see it go even faster.
17MB/s compression is fast but my HDD can take it more so 50MB/s would be nice if CPU and GPU can crunch together...

This means that using their implementation will work at 100% performance on a AMD GPU, but not so much when when run on NVIDIA or Intel GPUs.

Click to expand...

Is this joke day?... as opposed to what? PhysX working great on CPU? I find this bickering like the Socket issue, Intel makes small efforts for socket compatibility, no one moans, AMD changes one socket every one is up in arms.

In truth, AMD has no obligation to make their software work great (i.e 100%) on non-AMD hardware, nor does Nvidia in PhysX nor Intel in their compilers, but then again Intel as well as others have each their own OpenCL "fork" and if need be the devs can adjust. Safe to say that AMD's OpenCL won't cripple support as Nv's PhysX does on CPU. And even if the software works lets say at 50% in OpenCL... you have a 50% increase in performance if you have some sort of video card supporting OpenCL 1.2 on top of the performance you get from your CPU natively. All that from AMD and the devs in question without you even deserving it.

Is this joke day?... as opposed to what? PhysX working great on CPU? I find this bickering like the Socket issue, Intel makes small efforts for socket compatibility, no one moans, AMD changes one socket every one is up in arms.

In truth, AMD has no obligation to make their software work great (i.e 100%) on non-AMD hardware, nor does Nvidia in PhysX nor Intel in their compilers, but then again Intel as well as others have each their own OpenCL "fork" and if need be the devs can adjust. Safe to say that AMD's OpenCL won't cripple support as Nv's PhysX does on CPU. And even if the software works lets say at 50% in OpenCL... you have a 50% increase in performance if you have some sort of video card supporting OpenCL 1.2 on top of the performance you get from your CPU natively. All that from AMD and the devs in question without you even deserving it.

Click to expand...

He's not upset about it, he's just telling a fact. Its not a matter of pissing anyone off.

If you use an intel compiler x86, most likely it will work fast on intel cpus and not so fast on non-intel cpus, but its not intentionally, its by nature. The same goes for this c++ AMD OpenCL compiler. It might not generate code optimized for nvidia or intel GPUs. They could even have a hard time making it work fast on their own AMD gpus...

So the fact is, ok, AMD released this c++ thingy, and its fine. Now nvidia should sum up his efforts and make something similar unless the AMD compiler is good enough on nvidia gpus too.

He's not upset about it, he's just telling a fact. Its not a matter of pissing anyone off.

If you use an intel compiler x86, most likely it will work fast on intel cpus and not so fast on non-intel cpus, but its not intentionally, its by nature. The same goes for this c++ AMD OpenCL compiler. It might not generate code optimized for nvidia or intel GPUs. They could even have a hard time making it work fast on their own AMD gpus...

So the fact is, ok, AMD released this c++ thingy, and its fine. Now nvidia should sum up his efforts and make something similar unless the AMD compiler is good enough on nvidia gpus too.

Click to expand...

Never said he was... just seemed funny to me in a sort of sad way, day to day complaining about how some company does something but its not enough even if it adds no cost to the consumer.

Compile optimizations are intentionally... and you've argued my point, just as intel is not responsible for how intel compiled code works on AMD in the same way AMD is not responsible for how their OpenCL compiled coded works on Nvidia GPUs. As for how hard it's for them, it could be but they are doing it.

Golubev: Things got better since last time I’ve took a look at OpenCL, after an year (of very “hard” work I guess) AMD made possible to use BFI_INT, BIT_ALIGN_INT directly from OpenCL kernels (via bitselect() and amd_bitalign()). I was amazed how easy to write GPU kernels for AMD cards now while their performance is nearly the same as hand-written IL kernels

Click to expand...

It's still not perfect, but hey, small steps.

Nvidia, yeah... they're more likely to steal the code, adapt and rebrand it.

This may not cost anything to the consumer, but this does change a lot for developers, especially ones who are aiming for the highest compatibility.

Currently, OpenCL code compiled on an Intel or NVIDIA platform run faster (up to 30%) than on AMD's implementation. This could be due to the backporting of features from CUDA to the OpenCL standard, but since it's already part of the standard, AMD needs to keep up.

NVIDIA more likely to steal code? Nope. It's AMD who's more likely to adapt to the standard, because you can't exactly "steal" an open framework.

So the fact is, ok, AMD released this c++ thingy, and its fine. Now nvidia should sum up his efforts and make something similar unless the AMD compiler is good enough on nvidia gpus too.

Click to expand...

NVIDIA already has an implementation, but it has to go through CUDA due to the language's nature. So if you're going utilize the kernel language on an NVIDIA card, it's best to go the CUDA route. If you're going to utilize it on an Intel CPU or AMD GPU, it's best to follow the standard static C++ route. At the end of the day, the compiled data (executable or whatnot) will run normally on ANY brand of stream processors.