From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93382 invoked by alias); 31 Jan 2020 14:25:39 -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 93349 invoked by uid 89); 31 Jan 2020 14:25:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=H*f:sk:ff4d6cf, H*i:sk:ff4d6cf X-HELO: esa3.mentor.iphmx.com Received: from esa3.mentor.iphmx.com (HELO esa3.mentor.iphmx.com) (68.232.137.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Jan 2020 14:25:37 +0000 IronPort-SDR: ZdahaEf/SHYHONYwk2FmzWZ3AnE0cvp19yYrEJjeJBu/MfoZ+q9u5UMXyZFP7F5ETPpkc3QG3P VGYAaVfk/uiAOx4jpYQCbvQQgKUD8i5lH2kOz4iN7C7848l9tgfuFd3v40OLR4lWbq6eYO/jYk i4LYTm4yTpJYv9iORZ+Ux8df8lR7mBGC3grTXbCCDOZZ4NfOK/K2KWWLRKhjB82C9gbBbM/8SZ 5qARcWbd0sBSyhtd1zINIqwWEor9kR+z6mmhywnBxyLum3vVJSe7qjF3lDjRPOTgZoGFtEZCWO CQ8= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 31 Jan 2020 06:25:36 -0800 IronPort-SDR: urPIySkjz4phj9BIfhZmUF/dmeQWUy+OwFZAHsLytbTizQBIC8CfODMDXjISk5RXGYaOAPmC/z 1yc5/6TiA6LA== From: Thomas Schwinge To: Frederik Harwath CC: Jakub Jelinek , , Andrew Stubbs Subject: Re: [PATCH] Add OpenACC acc_get_property support for AMD GCN In-Reply-To: References: <0f59690f-5247-9b6e-169a-9a6ef16c41e1@codesourcery.com> <472b4749-7752-1527-c59c-1ab348854f32@codesourcery.com> <874kwdlyf7.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/26.1 (x86_64-pc-linux-gnu) Date: Fri, 31 Jan 2020 14:49:00 -0000 Message-ID: <87y2tnln3o.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: 2020-01/txt/msg02086.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 3132 Hi Frederik! On 2020-01-31T13:17:52+0100, "Harwath, Frederik" wrote: > On 30.01.20 17:08, Thomas Schwinge wrote: > >> I understand correctly that the only reason for: >>=20 >> On 2020-01-29T10:52:57+0100, "Harwath, Frederik" wrote: >>> * testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c >>> (expect_device_properties): Split function into ... >>> (expect_device_string_properties): ... this new function ... >>> (expect_device_memory): ... and this new function. >>=20 >> ... this split is that we can't test 'expect_device_memory' here: > >> [...] > >> ..., because that one doesn't (re-)implement the 'acc_property_memory' >> interface? > > Correct. OK, thanks for confirming. > But why "re-"? It has not been implemented before. Well, yes, it has already been implemented: in 'libgomp/plugin/plugin-gcn.c' ;-) -- that's why I meant it's re-implemented in the test case(s): in a similar yet slightly different way compared to the respective plugin(s). And for avoidance of doubt: I agree that's a good approach to verify that we're getting some consistent and meaningful results.) >>> --- a/libgomp/plugin/plugin-gcn.c >>> +++ b/libgomp/plugin/plugin-gcn.c >>> + case GOACC_PROPERTY_MEMORY: >>> + { >>> + size_t size; >>> + hsa_region_t region =3D agent->data_region; >>> + hsa_status_t status =3D >>> + hsa_fns.hsa_region_get_info_fn (region, HSA_REGION_INFO_SIZE, &size= ); >>> + if (status =3D=3D HSA_STATUS_SUCCESS) >>> + propval.val =3D size; >>> + break; >>> + } >>> [...] >>> } >>=20 >> Here we got 'acc_property_memory' implemented, but not here: >>=20 >>> --- /dev/null >>> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-gcn.c > > Yes, there seems to be no straightforward way to determine the expected v= alue through > the runtime API. We might of course try to replicate the logic that is > used in plugin-gcn.c. No need to do that now; I was just curious whether that's the reason. >>> --- a/libgomp/plugin/plugin-gcn.c >>> +++ b/libgomp/plugin/plugin-gcn.c >>=20 >>> @@ -4115,12 +4141,37 @@ GOMP_OFFLOAD_openacc_async_dev2host (int device= , void *dst, const void *src, >>> union goacc_property_value >>> GOMP_OFFLOAD_openacc_get_property (int device, enum goacc_property pro= p) >>> { >>> [...] >>> + switch (prop) >>> + { >>> + case GOACC_PROPERTY_FREE_MEMORY: >>> + /* Not supported. */ >>> + break; >>=20 >> (OK, can be added later when somebody feels like doing that.) > > Well, "not supported" means that there seems to be no (reasonable) way to= obtain > the necessary information from the runtime - in contrast to the nvptx plu= gin > where it can be obtained easily through the CUDA API. OK, I see, and again that's fine. (The API explicitly permits such "zero" returns.) And, I don't know what a user is actually supposed to tell from 'acc_property_free_memory' given that this can change at any point in time, arbitrarily, not under control of the executing processe, given that multiple processes may be using the GPU concurrently. Gr=C3=BC=C3=9Fe Thomas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" Content-length: 658 -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEU9WEfWKGQazCmycCAKI7+41Q4XkFAl40OMsACgkQAKI7+41Q 4XnZOQv/fN6gmXgEymd/I1elNQb7Ru6iSDpbNSXPy5wtS4O1GgIoeVx6l0vUdHdQ 7ag4dmGyWt7TvORHmg8TisyOGQcSytir8eQFJkP2V5SXDKpJmiIZgr0l73U1PGYk Z0S/Mvj+M9mRzv6ZN3nbbZsv/Vf+Ay3R6iwedKSNal3HSifwOXeb+X4bM2eNd86P td8Wd0RZ7dXD/CQH7c8xX1dkZP30HDAi7OshTBSR/lqQzpriUclGHw3KAhjh2U/Q OnR63x5fAnKA6QD7q2HsEV/3PmI9Vm+t03uO+DPeixABI1rvlocl9+WvVjgBa6c7 A/1NUUfp6ue/yimKzQaENZYiYhg3TkiJ19iBQAGlweanZkiDZdPOiO5EXCeQN0Id cf2VFUrKjzkYcczjmqENaxhCeleWl8fGaDb1WjJhbonz9TozBuxQp4gjW7aSCMWe 5Os5KaAxOg4ct+E6v73RzD9BYHoMd3kNszbNGEYaY7MKnBWBOyuZ0r2VLpfIWhJj 2TNm8XD6 =9CUb -----END PGP SIGNATURE----- --=-=-=--