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.


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".


Attachment: signature.asc
Description: PGP signature

Reply via email to