Hi Sandra,
Sandra Loosemore wrote:
-When Unified Shared Memory is enabled, whether by a @code{requires}
directive
-or by this environment variable being set to @code{AUTO} or
@code{ENABLED},
-global static variables that appear in a @code{declare target}
directive are
-not updated between device and host. That is, data copying under
this model
-for global static variables is ignored.
+When unified-shared memory is enabled by this environment variable, the
+following is currently @emph{unsupported} for only global static
variables
+that are specified in an @code{enter} clause on a @code{declare target}
+directive: specifying those variables in a @code{map} clause with
@code{always}
+modifier on a @code{target} or @code{target data} directive.
However, both
+@code{map} clauses without @code{always} modifier and using the
+@code{target update}, @code{target enter data}, or @code{target exit
data}
+directives is fully supported. When the unsupported case is
+encountered, the program aborts with an error message.
+@c FIXME: This is tracked in PR libgomp/127186
We call it "Unified Shared Memory" in the previous paragraph, why
switch to "unified-shared memory" here?
Fixed.
[To me it feels more natural to talk about 'unified shared memory" (the
hyphen was bogus) as it is not really a trade mark or similar; however,
after searching around, I see that both are about equally used and
reverted the change, but missed to updated in the newly added paragraph.]
I seriously cannot parse the rest of the paragraph at all, except for
the last sentence. :-( Among other points of confusion, the previous
paragraph says that you can enable USM in the code as well as by the
environment variable; do the limitations here apply *only* to the
environment variable use, or to the USM support in libgomp generally?
The whole section is only about the environment variable – it only
mentions the 'requires' directive you can have the 'omp requires' in the
code – and set the environment variable, i.e. you need to tell what
happens if you set both. (Answer: 'omp requires' wins.)
I moved that 'omp requires' wording below this text to reduce the confusion.
Regarding the unsupported part: The original wording applied to the env
var and the 'omp requires'. However, the runtime code was changed to fix
some of the issues for the runtime issue and add a runtime error for the
other. – This change does not affect 'omp requires'; however, for the
latter, there is a pending but approved patch that will fix this.
[For the remaining env var issue, there is a tracking bug – and I found
some more issues, mostly related to the 'omp requires' feature that
eventually need to be fixed, but of different nature.]
How does the new version look to you? (I used 'either ... or ...'
instead of just 'or' in an attempt to make clear that only those two
directives are affected and not 'target enter/exit data' [nor 'target
update'].)
Tobias
libgomp.texi: Improve the wording for GOMP_RUNTIME_USM, update impl status
The need_device_addr modified is supported for C (always an error)
since r15-6178-g2cbb2408a830a6 and in Fortran r15-7595-g8268c8256dd430.
[The C++ support exists on the devel/omp branches, but some cleanup is
required for upstreaming.]
libgomp/ChangeLog:
* libgomp.texi (OpenMP 6.0 implementation status): Mark
'need_device_addr' as supported.
(GOMP_RUNTIME_USM): Improve wording of the unsupported part.
libgomp/libgomp.texi | 33 ++++++++++++++++-----------------
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 92d82f2f66c..65b83d15724 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -544,7 +544,8 @@ to address of matching mapped list item per 5.1, Sect. 2.21.7.2 @tab N @tab
@item New @code{partitioner} value to @code{partition} allocator trait
@tab N @tab
@item Semicolon-separated list to @code{uses_allocators} @tab Y @tab
-@item New @code{need_device_addr} modifier to @code{adjust_args} clause @tab N @tab
+@item New @code{need_device_addr} modifier to @code{adjust_args} clause @tab P
+ @tab Not supported in C++
@item @code{interop} clause to @code{dispatch} @tab Y @tab
@item Scope requirement changes for @code{declare_target} @tab N @tab
@item @code{message} and @code{severity} clauses to @code{parallel} directive
@@ -5254,24 +5255,22 @@ default. Setting it to @code{AUTO} conditionally enables Unified Shared
Memory (USM) on specific integrated GPUs (APUs, in the verbiage of AMD). In most
workloads on these types of GPUs, self-mapping is expected to reduce runtime
overhead. Lastly, setting it to @code{ENABLED} unconditionally attempts
-to make use of Unified Shared Memory if the device claims to support it. Of
-additional note, specifying the @code{unified_shared_memory} or
-@code{self_maps} clauses with the @code{requires} directive causes that
-behavior to take precedence over the behavior set by this environment
-variable. For caveats around Unified Shared Memory, please consult
-the relevant sections in @ref{Offload-Target Specifics}.
-
-When unified-shared memory is enabled by this environment variable, the
-following is currently @emph{unsupported} for only global static variables
-that are specified in an @code{enter} clause on a @code{declare target}
-directive: specifying those variables in a @code{map} clause with @code{always}
-modifier on a @code{target} or @code{target data} directive. However, both
-@code{map} clauses without @code{always} modifier and using the
-@code{target update}, @code{target enter data}, or @code{target exit data}
-directives is fully supported. When the unsupported case is
-encountered, the program aborts with an error message.
+to make use of Unified Shared Memory if the device claims to support it.
+For general caveats around Unified Shared Memory, please consult the relevant
+sections in @ref{Offload-Target Specifics}.
+
+When Unified Shared Memory is enabled by this environment variable, the
+following is currently @emph{unsupported}: using a global static variable,
+specified in an @code{enter} clause on a @code{declare target}, in a
+@code{map} clause with @code{always} modifier on either a @code{target} or
+a @code{target data} directive. When the unsupported case is encountered,
+the program aborts with an error message.
@c FIXME: This is tracked in PR libgomp/127186
+When specifying the @code{unified_shared_memory} or @code{self_maps} clauses
+with the @code{requires} directive causes that behavior to take precedence
+over the behavior set by this environment variable.
+
OpenACC is unaffected by the value of this environment variable, however,
hybrid usage of OpenMP and OpenACC offloading results in the first used
framework taking precedent. As an example, if one uses OpenMP offloading and
