Hi,
there seems to have been some confusion about the OpenACC development that we're
currently engaged in. I thought I'd write here to clarify some things.
As Thomas previously announced, we're working on an implementation of OpenACC
2.0 for x86-64/Linux host systems and PTX accelerator devices. OpenACC is
specified at http://www.openacc-standard.org/. There are several proprietary
implementations of OpenACC targeting a variety of accelerator devices. This is
an opportunity to make OpenACC available in a free software compiler.
For this development the accelerated code will be PTX -- one has to start
somewhere. PTX is an ISA for a virtual machine. Its specification is public
and available at
http://docs.nvidia.com/cuda/parallel-thread-execution/index.html. To get PTX
code executed on a compute device (currently) requires use of Nvidia's driver
library. That library is available for zero cost and its API is documented at
http://docs.nvidia.com/cuda/cuda-driver-api/index.html. Although all those
links contain the name 'cuda', don't be misled by that -- it's an accident of
history.
Nothing in this project is preventing others from working on OpenACC support for
different accelerator devices. Neither will anyone be forced to build OpenACC
support -- as with OpenMP, there will be a configuration option allowing one to
configure a compiler without it.
Targeting PTX, an ISA for use with a single manufacturer's devices, is not
different from targeting the other single-manufacturer ISAs that GCC already
supports. It is, of course, a steering committee decision as to whether a new
backend is acceptable once it meets technical review.
GCC supports systems with proprietary runtimes. Historically GCC had to work
with proprietary C libraries -- for instance, I started in GCC development using
a sparc-solaris system. Now that Linux has become so prevalent, and its C
library is glibc, there's the opportunity to build GCC with and for free
software libraries. However, that in itself, hasn't caused any of the non-free
host or target OS support to be removed. Nor should it, IMHO, prevent GCC from
adding support for systems that have proprietary components (IIUC some CPUs rely
on an opaque blob of microcode in order to function).
As many of you will know, CodeSourcery, which Mentor purchased a few years ago,
has been contributing to GCC and other GNU projects for over 15 years. Several
Sourcerers are maintainers of particular pieces of the GNU project (mainly
toolchain components).
nathan
--
Nathan Sidwell
