From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125378 invoked by alias); 3 Dec 2019 09:33:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 125370 invoked by uid 89); 3 Dec 2019 09:33:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy=Per, offloading, schwinge, recommendations X-HELO: esa2.mentor.iphmx.com Received: from esa2.mentor.iphmx.com (HELO esa2.mentor.iphmx.com) (68.232.141.98) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Dec 2019 09:33:07 +0000 IronPort-SDR: ZWBvzghn7Vi6FwyqnSiHuin7hgbkC5vBvm+zO+kxlvbZgPwvhPAZs7ZeMcjXLh/g/unjVq5SG8 YDJfyf8bm5PbVhxAbnpYzoazTRHrzpwMyMLfegMm9NjESkG92h5JltM+JlIhXuVS4WceaSDhhO 9QHZo7i5oHRSoI1aOK6YWgi0BIKUJnJhTAWprPMTVr06uxniF3giK7tHWdovqJDeLrCx1bqaxT wIVpvudRb63zRlfAbWfl5uVz2fWwSU/TF+I5LmqmFtuFBTT5iz471YV4mrB/HCljfYXdIAHK7D ZQ0= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 03 Dec 2019 01:33:05 -0800 IronPort-SDR: FHkqd3b6Ifmxn32LC9QvWK3RstN3bl7HX13UzV1Hn7Oq0W4x/ALho9KE9p8EbS/GMWq7OLjNln dIEYBzU2eGtB4FfZvUO7g2rgArpytDnEPBSZZcUdydQMRFAkIN5eVo8/XRhRUzDR9G/e/EOniT 876FT/Hr85BnoTEWc/5GSwmlRWEJyTXxZKC1CTZke/Sv50SrV8WTZ7vhqyUhoOYtHV+JXM1cu7 KbPx1UBNshMZzFuDVKG8/EEcH++7kL5p4FoXeXQaPs/STEC7X/9pHtjKSJeYHKLslqS9qNIVo8 8GA= From: Thomas Schwinge To: Julian Brown , Andrew Stubbs CC: Jakub Jelinek , Subject: Which OpenACC 'acc_device_t' to use for AMD GPU offloading (was: [PATCH 4/7 libgomp,amdgcn] GCN libgomp port) In-Reply-To: <20191202145042.11eca9d3@squid.athome> References: <575c86b6ffe4a02860c47d93afb480ecea22682c.1573560401.git.ams@codesourcery.com> <87blsqlre6.fsf@euler.schwinge.homeip.net> <20191202145042.11eca9d3@squid.athome> User-Agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/26.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Dec 2019 09:33:00 -0000 Message-ID: <874kyhlpo6.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-Path: tschwing@mentor.com X-SW-Source: 2019-12/txt/msg00113.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2566 Hi! On 2019-12-02T14:50:42+0000, 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 =3D 3 removed. */ >> > acc_device_not_host =3D 4, >> > acc_device_nvidia =3D 5, >> > + acc_device_gcn =3D 8,=20=20 >>=20 >> 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=C3=BC=C3=9Fe Thomas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" Content-length: 658 -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEU9WEfWKGQazCmycCAKI7+41Q4XkFAl3mK8kACgkQAKI7+41Q 4XnCRAwArdjmr2N3bn/w2vDKEPSUxM7lcWT/WBdWKj4VSEZE4CKgeY4KFOdHlffn zJldArBKEaXB2ZYTlKx3kWV1/FsOP9wPZVFPar4GN2InVU5dNzHhhKPyKVy4egv8 +kFp/n7JRNNjBdfVWUwbEvi855nZFex+msM16U7wltQmVLioZKp25gv6HCdY6art 3naWy807GVmNxPERVqxagQmaSQJdyUbIbM1T4TqxMqKbLv9eWbKxuEv1u8l37Lj4 rfwvXxuG7wYu5ZgO4U6tQgQtJYCL62IFlTjDxgXBnqtOCPJA0GfeadbOWjkl4vsQ Qvr+SAGu044+9/2FHSnmFTonlmxpfsS0E0ogS0P8JaZ9gF+UKraXqJVw7mtOI5TX fOX/1v72CYdQt4Q6XtQNAXAgEbBvD7o8QZbOOx7jOR+pTyuFUPMQEBxrgGg9StQo y+A9/i+fnRwNlaLIF1G0GITFEhyv3TuVikIsUZy/FGlZMgRbn7N0XNGubmJwmMrv 0O1bZhiW =7U81 -----END PGP SIGNATURE----- --=-=-=--