Avoid stack allocation for test_requires_unified_shared_memory_heap*

[tob2]

Some (pseuo)USM implementations allocate memory in a special memory section that permits either direct memory access (DMA) from the device or on-access migration. In that case, stack and static memory may or may not be accessible.

This pull request changes the test_requires_unified_shared_memory_heap{,_map,_is_device_ptr}.{c,F90} testcases such that only heap memory is used on the device. The existing test_unified_shared_memory*.* testcases handle the other variants.

@nolanbaker31 @spophale @jrreap @krishols @mjcarr458 – please review

This is a consistency fix – permitting a partial pass with pseudo USM. For full USM, kernel + hardware support is required to access all memory. I some (but not all) post-Pascal Nvidia cards permit to access all memory and, if I understood it correctly (big “if”), AMD cards since VEGA support accessing all memory in principle, but effectively, only gfx90a (MI 200 series) permits fast access and has proper.

[tob2]

A colleague commented that having a stack memory (as before) but with an explicit map would work as well with (a certain) (pseudo)USM implementation.

I believe that this is an implementation choice, but I have now added as additional testcase that variant as well. Thus:

• original tests now only use heap memory
• new tests which are same as 4 original testcases, i.e. use a stack-allocated anArrayCopy, – except that they now use an explicit 'map(anArrayCopy)' for the checking array.

[spophale]

@tob2 I am not in favor of changing existing tests to use heap because spec 5.0 clearly states
".. memory in the device data environment of any device visible to OpenMP, including but not limited to the host, is considered part of the device data environment of all devices accessible through OpenMP ..."

But I am in favor of adding new tests or modify test to check for complete vs pseudo USM support. From the msg it should be clear that there is some degree of support for USM but not comprehensive support.

IMO adding map to target completely kills the intent of testing USM. I know the optimizing implications but nevertheless functionality should not depend on explicit maps when requires USM is specified.

[seyonglee]

IMO adding map to target completely kills the intent of testing USM. I know the optimizing implications but nevertheless functionality should not depend on explicit maps when requires USM is specified.

Using explicit map on a system with USM is still valid, and testing it has some values (even though not much, especially when tested alone).
Therefore, having multiple variants to test full USM and pseudo USM can be useful, even though not required by the standard.

[spophale]

@spophale will create new tests based on the changes suggested by Tobias and add them.

[spophale]

@tob2 , I am creating a new PR for the first five test edits. I am adding them as new tests. Can you please delete those from your commit ?

[spophale]

@tob2 , can you take a look.