Hi!
On 2019-12-03T14:20:13+0000, Julian Brown <jul...@codesourcery.com> wrote:
> On Tue, 3 Dec 2019 10:32:57 +0100
> Thomas Schwinge <tho...@codesourcery.com> wrote:
>> On 2019-12-02T14:50:42+0000, Julian Brown <jul...@codesourcery.com>
>> wrote:
>> > On Mon, 2 Dec 2019 15:43:29 +0100
>> > Thomas Schwinge <tho...@codesourcery.com> 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
