Hi Frederik! On 2020-01-31T13:17:52+0100, "Harwath, Frederik" <frede...@codesourcery.com> wrote: > On 30.01.20 17:08, Thomas Schwinge wrote: > >> I understand correctly that the only reason for: >> >> On 2020-01-29T10:52:57+0100, "Harwath, Frederik" <frede...@codesourcery.com> >> 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. >> >> ... 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 = agent->data_region;
>>> + hsa_status_t status =
>>> + hsa_fns.hsa_region_get_info_fn (region, HSA_REGION_INFO_SIZE, &size);
>>> + if (status == HSA_STATUS_SUCCESS)
>>> + propval.val = size;
>>> + break;
>>> + }
>>> [...]
>>> }
>>
>> Here we got 'acc_property_memory' implemented, but not here:
>>
>>> --- /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 value
> 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
>>
>>> @@ -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 prop)
>>> {
>>> [...]
>>> + switch (prop)
>>> + {
>>> + case GOACC_PROPERTY_FREE_MEMORY:
>>> + /* Not supported. */
>>> + break;
>>
>> (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 plugin
> 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üße
Thomas
signature.asc
Description: PGP signature
