My focus, both as a developer and instructor, is HPC, so I have generally been using PGI compilers on large Linux machines. That is also the teaching environment that we provide for students. If you do not have a PGI, Cray or CAPS license available, then OpenACC is not yet implemented anywhere else and you are out of luck at the moment. PGI does have a very nice trial license program, and I'd encourage you to give it a try if it seems at all viable, but that will not answer a longer term access issue. BTW, the PGI compiler does integrate with both Visual Studio and Eclipse, although I personally have very little OpenACC dev hours on either of those.

OpenMP 4.0 (and that is what you need) is currently only implemented in the Intel compiler. 4.0 was only finally approved this past month by the standards committee, so it may take a while for all the compilers to catch up. The big issue here is that Intel is currently only supporting the MIC/Phi architecture for compiler output at the moment. And one can imagine that they are in no rush to change that. OpenMP 3.x is supported very well by MS, Gnu, PGI, Intel and by all of the associated IDEs, so eventually this will all sort out like one would hope.

So, if you want to start developing right now, you will either have to shell out for a compiler and/or limit yourself to certain architectures. Those may be complete non-issues for you. If they are not, you will have to either wait for the situation to improve, or drop back to OpenCL. If so, at least be aware that it has been "deprecated" in a practical sense by the only ones that matter (Intel, NVIDIA and AMD).

Good questions, BR:

a) As the three major accelerator vendors (NVIDIA, Intel and AMD) have diverged on their fundamental hardware approach (GPU, MIC and APU) the older, generic approach of OpenCL has devolved in relevance to only GPUs. And since even NVIDIA would prefer that you use CUDA at this level for GPUs, there are no commercial resources going into supporting it.

b) OpenACC and OpenMP are both directive based. This means they do not disrupt your current code base and they are easy to try in an incremental (one loop at a time) way. They are both related, originating form the same OpenMP standards people, and are both open standards (openmp.org and openacc-standard.org). Almost all compilers support OpenMP 3, and will eventually support OpenMP 4, which the is relevant version for accelerators.

c) OpenMP has been around since the 90s, and is well used. I wouldn't hesitate to suggest a project invest in it.

As regards the original question, OpenACC/OpenMP are much, much easier to use than OpenCL. Also, there are many more successful use cases in the HPC world to point to and learn from.

John

APUs (and Fusion is indeed AMD's marketing term for them), with their CPU/GPU shared memory, don't require the same programming model as normal GPUs. The data movement issue goes from being foremost to being non-existent. Hence OpenCL becomes moot. And AMD was really the last serious supporter of OpenCL.

I teach this stuff daily, and the huge advance over the past year has been the availability of OpenACC, and now OpenMP 4, compilers that allow you to use directives and offload much of the CUDA pain to the compiler.

There is now a substantial base of successful codes that demonstrate that this really works efficiently (both development time and FLOPS). S3D runs at 15 PFLOPS on Titan using this and may well win the Gordon Bell prize this year. Less than 1% of lines of code modified there. NVIDIA has a whole web site devoted to use cases.

I recommend you spend a day to learn it. There are regular online courses offered, and there is a morning session on it this Monday at XSEDE 13 if you are one of those HPC guys. A decent amount is available online as well.

BTW, with AMD moving to Fusion, the last real supporter of OpenCL is gone. NVIDIA prefers OpenACC or CUDA and Intel prefers OpenMP 4 for MIC/Phi. So everyone officially supports it, but no one really puts any resources into it and you need that with how fast this hardware evolves.

Based upon the unbelievable number of posters that flock to complain that they can't see 3D every time some subject concerning 3D movies, games or headsets comes up, I predict this topic will have comments all out of proportion to it's nominal interest. I don't know whether people with certain vision defects end up as coders, or if perhaps too much coding amplifies some congenital issue, but I do suspect it is much higher than the 2% cited in the article. I eagerly await the explosion of interest and hope to download the freeware Amblyopia App sometime soon. Get coding.

As your "3D fury" really seems to be stoked (no offense, but I picture you as a eye-patch wearing pirate feeling very aggreived by the possiblity of being left behind by the 3D boat), let me pose this question: Do you think that short depth of field (blury backgrounds) in 2D video or pictures is stressful to the human vision system? If I'm watching Gone with the Wind and try to stare at the out-of-focus background landscapes, doesn't the auto-focus software in my head get annoyed by this inability to bring the fixated objects into focus? I'll propose that initially it does, and then quickly gets over it - maybe back when we were infants. What makes you think the infintitely malleable human brain can't figure out that convergence and focal distance don't always correspond? John