[Patch] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

[Tobias Burnus]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20240919/8e664fbc/attachment-0001.htm>