Re: Which OpenACC 'acc_device_t' to use for AMD GPU offloading
Regarding the acc_device_, I want to observe that there is no fundamental reason that one cannot have multiple names which resolve to the same constant. Thus, one could add acc_device_radeon while keeping acc_device_gcn. Whether this makes sense or causes even more confusion is another question. Searching the internet, acc_device_gcn seems to GCC specific while acc_device_radeon does pop up, but not that often the documents are from 2014/2015 – and mentionAMD Radeon 7970, AMD Radeon 7990. [On one slide of a super-computing center, they listed what PGI back then did define. For completeness, that was: acc_device_none = 0, acc_device_default = 1, acc_device_host = 2, acc_device_not_host = 3, acc_device_nvidia = 4,acc_device_radeon = 5, acc_device_xeonphi = 6, acc_device_pgi_opencl = 7, acc_device_nvidia_opencl = 8, acc_device_opencl = 9.] Tobias On 12/3/19 3:42 PM, Thomas Schwinge wrote: And, as I'd mentioned, it's in the OpenACC specification, but it's a "recommendation", so if you're not comfortable with 'acc_device_radeon', then it's not too late to change the specification. Think of it from a user's perspective, as I'd suggested. I had a look, and 'acc_device_radeon' (some kind of "brand" name, not specific to GPUs even?) has been present in the OpenACC specification for so long that from my archives, I can't tell who introduced it, and what the rationale was, given that 'acc_device_nvidia' (hardware vendor name) probably already did exist. As one additional data point: there once also existed a 'acc_device_xeonphi', which got removed two years ago "since Intel no longer produces this product".
Re: Which OpenACC 'acc_device_t' to use for AMD GPU offloading
Hi!
On 2019-12-03T14:20:13+, Julian Brown wrote:
> On Tue, 3 Dec 2019 10:32:57 +0100
> Thomas Schwinge wrote:
>> On 2019-12-02T14:50:42+, Julian Brown
>> wrote:
>> > On Mon, 2 Dec 2019 15:43:29 +0100
>> > Thomas Schwinge wrote:
>> >
>> >> > --- a/libgomp/openacc.h
>> >> > +++ b/libgomp/openacc.h
>> >> > @@ -55,6 +55,7 @@ typedef enum acc_device_t {
>> >> >/* acc_device_host_nonshm = 3 removed. */
>> >> >acc_device_not_host = 4,
>> >> >acc_device_nvidia = 5,
>> >> > + acc_device_gcn = 8,
>> >>
>> >> There is no 'acc_device_gcn' in OpenACC.
>>
>> My point is, the OpenACC specification defines 'acc_device_t', and
>> we're now adding/using a non-standard value, 'acc_device_gcn'.
>> Depending on how you read the specification, it may be allowed for an
>> implementation to provide additional/different values, but for good
>> reason, OpenACC 3.0, A. "Recommendations for Implementors", still
>> "gives recommendations for standard names [...] to use for
>> implementations for specific targets and target platforms, to promote
>> portability across such implementations".
>>
>> >> Per OpenACC 3.0, A.1.2. "AMD
>> >> GPU Targets", for example, there is 'acc_device_radeon' (and "the
>> >> case-insensitive name 'radeon' for the environment variable
>> >> 'ACC_DEVICE_TYPE'"). If that is not appropriate to use (I have not
>> >> read up how exactly AMD's "GCN" and "radeon" relate to each other),
>> >> we should get that clarified in the OpenACC specification.
>> >
>> > FWIW, I'm pretty sure there are Radeon devices that do not use the
>> > GCN ISA.
>>
>> But does an OpenACC user really care? Are users likely to state: "I
>> have a GCN card", or rather: "I have an AMD GPU card", or even just:
>> "I have a card with a big AMD logo on it"?
>>
>> Admittedly, users are probably unlikely to state: "I have a Radeon
>> card", heh? ;-) (But it's still the standard name defined in the
>> OpenACC specification.)
>>
>> > OTOH, there are also Nvidia devices that are not PTX-compatible.
>>
>> (But not any recent (as in a few years old) ones, capable for GPGPU
>> computing, are there?)
>>
>> But again: "I have a card with a big Nvidia logo on it" is probably
>> what users care about, not whether that is internally using PTX or
>> anything else, which then is the implementation's job to sort out,
>> when 'acc_device_nvidia' is requested by the user.
>>
>> > No strong opinion on the acc_device_foo name from me, though (maybe
>> > "acc_device_amdgcn"?).
>>
>> Once/if we have established that the standard 'acc_device_radeon' is
>> not suitable for us here, only then we should think of a new name, in
>> my opinion. You wouldn't just add a 'copy_mem' function to glibc
>> given that 'memcpy' already exists? ;-)
>
> Oops, I clearly didn't read that email carefully! Since this is a
> user-visible, not internal-only thing and there is a recommended name
> given in the spec, we should use that name. Still, it's a pity the
> official naming is such a jumble.
Yeah.
And, as I'd mentioned, it's in the OpenACC specification, but it's a
"recommendation", so if you're not comfortable with 'acc_device_radeon',
then it's not too late to change the specification. Think of it from a
user's perspective, as I'd suggested.
I had a look, and 'acc_device_radeon' (some kind of "brand" name, not
specific to GPUs even?) has been present in the OpenACC specification for
so long that from my archives, I can't tell who introduced it, and what
the rationale was, given that 'acc_device_nvidia' (hardware vendor name)
probably already did exist.
As one additional data point: there once also existed a
'acc_device_xeonphi', which got removed two years ago "since Intel no
longer produces this product".
Grüße
Thomas
signature.asc
Description: PGP signature
Re: Which OpenACC 'acc_device_t' to use for AMD GPU offloading (was: [PATCH 4/7 libgomp,amdgcn] GCN libgomp port)
On Tue, 3 Dec 2019 10:32:57 +0100
Thomas Schwinge wrote:
> Hi!
>
> On 2019-12-02T14:50:42+, Julian Brown
> wrote:
> > On Mon, 2 Dec 2019 15:43:29 +0100
> > Thomas Schwinge wrote:
> >
> >> > --- a/libgomp/openacc.h
> >> > +++ b/libgomp/openacc.h
> >> > @@ -55,6 +55,7 @@ typedef enum acc_device_t {
> >> >/* acc_device_host_nonshm = 3 removed. */
> >> >acc_device_not_host = 4,
> >> >acc_device_nvidia = 5,
> >> > + acc_device_gcn = 8,
> >>
> >> There is no 'acc_device_gcn' in OpenACC.
>
> My point is, the OpenACC specification defines 'acc_device_t', and
> we're now adding/using a non-standard value, 'acc_device_gcn'.
> Depending on how you read the specification, it may be allowed for an
> implementation to provide additional/different values, but for good
> reason, OpenACC 3.0, A. "Recommendations for Implementors", still
> "gives recommendations for standard names [...] to use for
> implementations for specific targets and target platforms, to promote
> portability across such implementations".
>
> >> Per OpenACC 3.0, A.1.2. "AMD
> >> GPU Targets", for example, there is 'acc_device_radeon' (and "the
> >> case-insensitive name 'radeon' for the environment variable
> >> 'ACC_DEVICE_TYPE'"). If that is not appropriate to use (I have not
> >> read up how exactly AMD's "GCN" and "radeon" relate to each other),
> >> we should get that clarified in the OpenACC specification.
> >
> > FWIW, I'm pretty sure there are Radeon devices that do not use the
> > GCN ISA.
>
> But does an OpenACC user really care? Are users likely to state: "I
> have a GCN card", or rather: "I have an AMD GPU card", or even just:
> "I have a card with a big AMD logo on it"?
>
> Admittedly, users are probably unlikely to state: "I have a Radeon
> card", heh? ;-) (But it's still the standard name defined in the
> OpenACC specification.)
>
> > OTOH, there are also Nvidia devices that are not PTX-compatible.
>
> (But not any recent (as in a few years old) ones, capable for GPGPU
> computing, are there?)
>
> But again: "I have a card with a big Nvidia logo on it" is probably
> what users care about, not whether that is internally using PTX or
> anything else, which then is the implementation's job to sort out,
> when 'acc_device_nvidia' is requested by the user.
>
> > No strong opinion on the acc_device_foo name from me, though (maybe
> > "acc_device_amdgcn"?).
>
> Once/if we have established that the standard 'acc_device_radeon' is
> not suitable for us here, only then we should think of a new name, in
> my opinion. You wouldn't just add a 'copy_mem' function to glibc
> given that 'memcpy' already exists? ;-)
Oops, I clearly didn't read that email carefully! Since this is a
user-visible, not internal-only thing and there is a recommended name
given in the spec, we should use that name. Still, it's a pity the
official naming is such a jumble.
Julian
Which OpenACC 'acc_device_t' to use for AMD GPU offloading (was: [PATCH 4/7 libgomp,amdgcn] GCN libgomp port)
Hi!
On 2019-12-02T14:50:42+, Julian Brown wrote:
> On Mon, 2 Dec 2019 15:43:29 +0100
> Thomas Schwinge wrote:
>
>> > --- a/libgomp/openacc.h
>> > +++ b/libgomp/openacc.h
>> > @@ -55,6 +55,7 @@ typedef enum acc_device_t {
>> >/* acc_device_host_nonshm = 3 removed. */
>> >acc_device_not_host = 4,
>> >acc_device_nvidia = 5,
>> > + acc_device_gcn = 8,
>>
>> There is no 'acc_device_gcn' in OpenACC.
My point is, the OpenACC specification defines 'acc_device_t', and we're
now adding/using a non-standard value, 'acc_device_gcn'. Depending on
how you read the specification, it may be allowed for an implementation
to provide additional/different values, but for good reason, OpenACC 3.0,
A. "Recommendations for Implementors", still "gives recommendations for
standard names [...] to use for implementations for specific targets and
target platforms, to promote portability across such implementations".
>> Per OpenACC 3.0, A.1.2. "AMD
>> GPU Targets", for example, there is 'acc_device_radeon' (and "the
>> case-insensitive name 'radeon' for the environment variable
>> 'ACC_DEVICE_TYPE'"). If that is not appropriate to use (I have not
>> read up how exactly AMD's "GCN" and "radeon" relate to each other),
>> we should get that clarified in the OpenACC specification.
>
> FWIW, I'm pretty sure there are Radeon devices that do not use the GCN
> ISA.
But does an OpenACC user really care? Are users likely to state: "I have
a GCN card", or rather: "I have an AMD GPU card", or even just: "I have a
card with a big AMD logo on it"?
Admittedly, users are probably unlikely to state: "I have a Radeon card",
heh? ;-) (But it's still the standard name defined in the OpenACC
specification.)
> OTOH, there are also Nvidia devices that are not PTX-compatible.
(But not any recent (as in a few years old) ones, capable for GPGPU
computing, are there?)
But again: "I have a card with a big Nvidia logo on it" is probably what
users care about, not whether that is internally using PTX or anything
else, which then is the implementation's job to sort out, when
'acc_device_nvidia' is requested by the user.
> No strong opinion on the acc_device_foo name from me, though (maybe
> "acc_device_amdgcn"?).
Once/if we have established that the standard 'acc_device_radeon' is not
suitable for us here, only then we should think of a new name, in my
opinion. You wouldn't just add a 'copy_mem' function to glibc given that
'memcpy' already exists? ;-)
Grüße
Thomas
signature.asc
Description: PGP signature
