Hi Andre,
thanks for reading the patch + commenting.
Andre Vehreschild wrote:
in the changelog of libgomp:
* fortran.c (omp_get_uid_from_device_,
omp_get_uid_from_device_8_): Add.
"Add." what? Can you be more specific, i.e. is it just a dummy or prototype?
Neither. It is a full implementation (that is a wrapper to the target.c
function, directly called by C/C++).
The prototype used by fortran.c is 'omp.h.in' (i.e. the C/C++ header
file, also used by user code) and for Fortran code of users, it is the
module generated from 'omp_lib.f90.in' and the (deprecated) include file
'omp_lib.h.in'.
The purpose of fortran.c in general – and also for the added code – is
to be a wrapper between the Fortran API/ABI and the C ABI. In the
current case, there are two reasons for the two functions:
(a) The result type is 'character(:), pointer' – but the C function just
returns a '\0' terminated const char*. Hence, the wrapper function
contains a '*result_len = strlen (*result);' besides the '*result =
<call to C function>'
(b) The argument is an 'integer'. As we want to be compatible with
-fdefault-integer-8, previously somewhat fashionable, we have an
'int32_t' and an 'int64_t' version of the function – which needs a
second wrapper function.
As for the other API routine, as a BIND(C) makes it call the C function,
no wrapper it needed.
* * *
[Typo: missing 'a' – noted + will fix.]
* * *
+@item The unique identifier (UID), used with OpenMP's API UID routine, consists
+ of the @samp{GPU-} prefix followed by the 16-bytes UUID as returned by
+ the CUDA runtime library. This UUID is output in grouped lower-case
+ hex digits; the grouping of those 32 digits is: 8 digits, hyphen,
+ 4 digits, hyphen, 4 digits, hyphen, 16 digits. The output matches the
+ format used by @code{nvidia-smi}.
@end itemize
Do I get this right, that for CUDA this is, e.g. GPU-0123456789abdcef ? Then
why is the "normal" UUID display format described here? This confuses me. (Just
curiosity.)
For AMD, it is the following type of string, which contains a 8 bytes/16
hex-digits UUID part: 'GPU-abcef0123456789'.
While for Nvidia it is 'GPU-abcdef12-1234-1234-01234567890abcd',
consisting of a 16 bytes/32 hex-digits UUID.
For AMD, we directly get the string, matching what "rocminfo" shows as UUID.
For Nvidia, we don't get a string but a 'char bytes[16]' array filled
with the values, which we print each as '%02x' hex digit. For the
output, additionally, a "GPU-" prefix is added + a few hyphens. That's
to mimic what 'nvidia-smi -a' outputs.
I admit it is slightly confusing – and when reading the .texi, it is
also easy to miss that one part talks about AMD ("GCN") GPUs and the
other about NVidia GPUs.
→ https://gcc.gnu.org/onlinedocs/libgomp/Offload-Target-Specifics.html
(In terms of OpenMP, it is only a unique identifier; it does not need to
be universally unique [and also isn't for the host]; AMD and Nvidia call
it UUID and it looks rather unique for the GPU; rocminfo also outputs an
"UUID" for the CPU but that's just "CPU-XX" (twice for a dual socket
system, i.e. not even unique), but we don't use this output.)
Er, and when I read further on, I find the nvptx implementation and that
contradicts the description. There a "normal" UUID is added to the GPU- id.
Now I am confused. What description contradicts which one?
Tobias
