public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Stubbs <ams@codesourcery.com>
To: Thomas Schwinge <thomas@codesourcery.com>,
	Jakub Jelinek	<jakub@redhat.com>
Cc: <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 4/7 libgomp,amdgcn] GCN libgomp port
Date: Tue, 03 Dec 2019 13:13:00 -0000	[thread overview]
Message-ID: <e3177f35-c11c-1428-3d1c-cbd26ed64e49@codesourcery.com> (raw)
In-Reply-To: <87blsqlre6.fsf@euler.schwinge.homeip.net>

On 02/12/2019 14:43, Thomas Schwinge wrote:
> Hi!
> 
> On 2019-11-12T13:29:13+0000, Andrew Stubbs <ams@codesourcery.com> wrote:
>> --- a/include/gomp-constants.h
>> +++ b/include/gomp-constants.h
>> @@ -174,6 +174,7 @@ enum gomp_map_kind
>>   #define GOMP_DEVICE_NVIDIA_PTX		5
>>   #define GOMP_DEVICE_INTEL_MIC		6
>>   #define GOMP_DEVICE_HSA			7
>> +#define GOMP_DEVICE_GCN			8
> 
> Unless we are to expect non-AMD GCN implementations (hardware), I'd favor
> if all these "GCN" things were called "AMD GCN", like done for "Nvidia
> PTX", or "Intel MIC", or why shouldn't we?

Why do we do that for libgomp, but not for GCC in general? I mean, it's 
not "Intel i386" or "Renesas SuperH" (or should that be "Hitachi"?). The 
only GCC port that has the company name is the "nv" in "nvptx" (ignoring 
those where the company and architecture are the same).

We use "amdgcn" for the target triplet, but it's just "gcn" almost 
everywhere else, including the config directories.

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

This seems more significant.

There are certainly Radeon devices that are not GCN, but I think all GCN 
devices are branded Radeon?

https://www.amd.com/en/technologies/gcn says "GCN powered Radeon GPUs 
were built ..." so I think AMD would be fine with radeon.  I'll put this 
on my todo list.

Andrew

  parent reply	other threads:[~2019-12-03 13:13 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 13:29 [PATCH 0/7 libgomp,amdgcn] AMD GCN Offloading Support Andrew Stubbs
2019-11-12 13:29 ` [PATCH 3/7 libgomp,nvptx] Add device number to GOMP_OFFLOAD_openacc_async_construct Andrew Stubbs
2019-11-12 13:46   ` Jakub Jelinek
2019-11-12 13:29 ` [PATCH 2/7 amdgcn] GCN mkoffload Andrew Stubbs
2019-11-12 13:29 ` [PATCH 1/7 libgomp,nvptx] Move generic libgomp files from nvptx to accel Andrew Stubbs
2019-11-12 13:43   ` Jakub Jelinek
2019-11-12 13:30 ` [PATCH 5/7 libgomp,amdgcn] Optimize GCN OpenMP malloc performance Andrew Stubbs
2019-11-12 14:02   ` Jakub Jelinek
2019-11-12 17:54     ` Andrew Stubbs
2019-11-12 22:51       ` Jakub Jelinek
2019-11-12 13:30 ` [PATCH 4/7 libgomp,amdgcn] GCN libgomp port Andrew Stubbs
2019-11-12 13:48   ` Jakub Jelinek
2019-11-12 14:21     ` Andrew Stubbs
2019-12-02 14:43   ` Thomas Schwinge
2019-12-02 14:50     ` Julian Brown
2019-12-03  9:33       ` Which OpenACC 'acc_device_t' to use for AMD GPU offloading (was: [PATCH 4/7 libgomp,amdgcn] GCN libgomp port) Thomas Schwinge
2019-12-03 14:20         ` Julian Brown
2019-12-03 14:42           ` Which OpenACC 'acc_device_t' to use for AMD GPU offloading Thomas Schwinge
2019-12-03 15:00             ` Tobias Burnus
2019-12-03 13:13     ` Andrew Stubbs [this message]
2019-12-03 14:07       ` "gcn" vs. "amdgcn" etc. (was: [PATCH 4/7 libgomp,amdgcn] GCN libgomp port) Thomas Schwinge
2019-12-03 15:53         ` Julian Brown
2020-01-17 19:20     ` [committed, amdgcn/openacc] Rename acc_device_gcn to acc_device_radeon Andrew Stubbs
2020-04-21 12:24       ` [AMD GCN] Use 'radeon' for the environment variable 'ACC_DEVICE_TYPE' (was: [committed, amdgcn/openacc] Rename acc_device_gcn to acc_device_radeon) Thomas Schwinge
2020-04-23 16:27         ` [AMD GCN] Use 'radeon' for the environment variable 'ACC_DEVICE_TYPE' Andrew Stubbs
2020-04-29  8:08           ` Thomas Schwinge
2019-12-16 22:28   ` [PATCH 4/7 libgomp,amdgcn] GCN libgomp port Thomas Schwinge
2019-11-12 13:30 ` [PATCH 7/7 libgomp,amdgcn] GCN Libgomp Plugin Andrew Stubbs
2019-11-12 14:11   ` Jakub Jelinek
2019-11-12 14:42     ` Andrew Stubbs
2021-01-14 19:19   ` [gcn offloading] Only supported in 64-bit configurations (was: [PATCH 7/7 libgomp,amdgcn] GCN Libgomp Plugin) Thomas Schwinge
2024-03-07 11:29   ` GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is not fatal " Thomas Schwinge
2024-03-07 11:38     ` GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is not fatal Andrew Stubbs
2024-03-07 13:37       ` Thomas Schwinge
2024-03-07 13:47         ` Andrew Stubbs
2024-03-07 11:43     ` Tobias Burnus
2024-03-07 13:37       ` Thomas Schwinge
2024-03-07 14:07         ` Tobias Burnus
2024-03-08 10:21           ` Thomas Schwinge
2024-03-08 10:16         ` GCN: The original meaning of 'GCN_SUPPRESS_HOST_FALLBACK' isn't applicable (non-shared memory system) (was: GCN: Even with 'GCN_SUPPRESS_HOST_FALLBACK' set, failure to 'init_hsa_runtime_functions' is not fatal) Thomas Schwinge
2024-03-08 12:42           ` GCN: The original meaning of 'GCN_SUPPRESS_HOST_FALLBACK' isn't applicable (non-shared memory system) Andrew Stubbs
2019-11-12 13:31 ` [PATCH 6/7 amdgcn] Use a single worker for OpenACC on AMD GCN Andrew Stubbs
2021-06-08 10:07   ` Thomas Schwinge
2019-11-13 13:05 ` [PATCH 0/7 libgomp,amdgcn] AMD GCN Offloading Support Andrew Stubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3177f35-c11c-1428-3d1c-cbd26ed64e49@codesourcery.com \
    --to=ams@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=thomas@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).