As the non-profit standards group behind the push for wider adoption via easier use of accelerators, OpenACC has quite a big job ahead. Although analysts agree that accelerators sit along a comfortable adoption curve, usability, programmability and portability are key concerns, among others.

Over the last couple of years, OpenACC has worked with user groups across academia and industry to understand what is still needed for healthier adoption of accelerators via workshops and meetings, which has produced a number of the core improvements that are available within the 2.0 spec (procedure calls, nested parallelism, more dynamic data management support and more). On top of that, the ecosystem is also rounded out by CAPS, PGI and Cray, in particular, as well as being supported by x86 and ARM vendors (and of course the accelerators from all the major players).

Of course, one of the main questions was whether the OpenACC group would be able to offer a free implementation and whether they would open source OpenACC (not the same thing, as we know). Today the group spoke to those requests by announcing that one of its new members (in addition to Louisiana State University and NOAA as of this week), Mentor Graphics, has developed OpenACC extensions that will be supported in mainstream GCC compilers.

Mentor Graphics’ Nathan Sidwell told us that this came about following their acquisition of Code Sourcery, which has a long history of producing GCC-based toolchains for Linux and embedded systems. Mentor is working on implementing OpenACC 2.0 in the GCC toolchain, which will be rolled out over the next year, making an open source implementation of OpenACC available to all users who have Linux systems. Sidwell said that they are leveraging some of the existing infrastructure in GCC for accelerated computing, but how different implementations will converge is undecided at this point as it will be up to distributors of Linux systems how they configure GCC for their offerings.

As OpenACC President, Duncan Poole, said of this development, it breaks OpenACC out of a niche where users had to make a distinct decision to go their route.  “The addition of an open source platform is critical for the broader range of heterogeneous programming that will be necessary for the next stage of growth and innovation in HPC and as a foundation to drive software development for exascale systems.”

The non-profit wants to move accelerator use for clusters beyond computer science realms and open it to a wider set of users whose background might have little to do with programming for GPUs or other accelerators. To address those users, Poole says there needs to be support for legacy applications (those that are written in Fortran, for example, or by someone who is no longer with an organization or even those that were collaboratively developed). Users with these applications usually need a way of supporting new features but don’t require custom code paths for special features, says Poole, and this is where the benefit of OpenACC can be keenly felt.

OpenACC has been in 1.0 for a couple of years with the 2.0 spec released over the summer. Since then, as mentioned, there are three commercial implementations, all of which are starting to roll out their own 2.0 implementations (Cray with their 8.2 release recently, CAPS with their announcement of full OpenACC in December and PGI in the near term with their 2014 release in January). In addition to offering key features, the most important of which are procedure calls, Michael Wolfe of PGI (recently acquired by NVIDIA) and secretary of OpenACC says they’re using feedback to address a few other issues.

The main goal is to preserve the readability of these programs and ensure cross-platform compatibility. For OpenACC to provide this, the focus is on directives—a familiar programming model that can handle a number of elements that don’t require the end user to have a deep understanding of CUDA or OpenCL. They can then do things like allocate data on the accelerator, transfer data that’s been on the host to the booster, perform a series of operations on the accelerator and then return results back to program with far more transparency than was possible before.

“All the OpenACC vendors have experienced increasing experimentation and adoption of OpenACC on a variety of applications, including weather, computational chemistry, fluid flow simulation, combustion, and many more,” said Wolfe.  “We have been getting very useful feedback from the users to drive improvements to the specification and implementations that will deliver better performance as well as overall enhanced user experience.”

As Wolfe told us, “One of the most important features for C and C++ code would be arrays in C++ classes or C structs or Fortran derived types—these are structured data types that have array members, but right now the spec has no standard way to support that and the implementations are weak in that area—so we’re working hard to make that work, in particular for C++. We undertand that C++ is a large language and has some unique features so we’re working hard with feedback to make sure we support that in a natural and satisfying manner for those many users.”

Wolfe said that without a doubt, the top feedback from their workshops and analysis is not really a surprise—“for C++ you really have to support classes and templated classes and class members that are arrays because that’s how those programs are written. That also appears in Fortran, but not as pervasive as in C++.”

In agreement with these workshops findings is one of the core contributors to OpenACC efforts, Oak Ridge National Lab. With Titan in full production and a whole new set of users porting their codes, the lab has been keen to ensure that OpenACC is stable enough to support the next class of applications being onboarded—not to mention serving as a testbed for what might be viable for exascale-class systems.

As Dr. Oscar Hernandez, Research Staff Scientist at ORNL (and OpenACC Director of Developer Adoption) told us, OpenACC is very important because it allows ORNL to program heterogeneous systems with a single programming model that lets his teams address multiple architectures with different types of memory. “It’s important for us also because it’s a way to maintain portability in our codes and at the same time take advantage of leadership-class systems at ORNL that rely on accelerators. OpenACC offers a solution that works today and is friendly to the programmer–Open source efforts also help us drive and understand more the application needs and to do research and improve and understand what we need to do to build an ecosystem aroud OpenACC in addition we like the fact that it works now and can move fast and meet more app needs as of today.”

The group will have its first booth ever at SC13, which will be manned by various members of the organization. Some schedule highlights below for those interested in this track. We shall see you there…