This is the mail archive of the
mailing list for the GCC project.
Re: trying out openacc 2.0
- From: Mark Farnell <mark dot farnell at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 17 Dec 2014 14:38:44 +1300
- Subject: Re: trying out openacc 2.0
- Authentication-results: sourceware.org; auth=none
- References: <CADD2D=4e_ijx7BxpjQ08gwkcwJ-DGqXXKuKLXsrCMc-u29KjRg at mail dot gmail dot com> <20141216082255 dot GA5998 at physik dot fu-berlin dot de> <CADD2D=5QuwRg-DFVYpekVoY-Btyatn0Om1H1kxeMfZvNPugHrw at mail dot gmail dot com> <20141216200528 dot GM1667 at tucnak dot redhat dot com>
So what parameters will I need to pass to ./configure if I want to
support PTX offloading?
So if I want to have CPU, KNL and PTX, do I end up building three compilers?
And is it true that running in both the offload mode, and the KNL
native mode, would require two set of toolchains?
Finally, is the nvptx-tools project mentioned in Tobia's page aiming
at replacing the CUDA toolchain?
On Wed, Dec 17, 2014 at 9:05 AM, Jakub Jelinek <email@example.com> wrote:
> On Wed, Dec 17, 2014 at 08:54:06AM +1300, Mark Farnell wrote:
>> That's good news. Does it mean that if I want to try out openACC with
>> KNL and PTX support, then all I need to do is to compile the
>> gomp-4_0-branch *without* any extra parameters into ./configure ?
> No. Please read the wiki page Tobias mentioned, you need to build 2
> compilers and pass some configure options to get OpenMP + KNL support.
> OpenACC has not been committed to trunk yet, but even when it will make it
> in, you'll still need similarly to build 2 compilers and configure them
> non-default way.
>> Also, are other GPUs such as the AMD ATI and the built-in GPUs such as
>> the Intel GPU and AMD fusion supported? If so, are they already
>> supported in the trunk, or only specific branch?
> Some AMD HSA support is on the hsa svn branch, but AFAIK OpenMP 4.0
> offloading nor OpenACC is supported there yet (instead just auto-offloading
> some OpenMP 3.x loops I believe).
>> Finally, when will support of Knights Corner (knc) be added to the
>> trunk and/or one of the branches?
> Unlikely. The advantage of KNL is that it uses the same vector ISA as
> the future desktop/server CPUs, not a different one; to support KNC we'd
> need to make the i?86 backend larger and more complicated for something that
> is not going to be used in any? future CPUs.