Hi Tobias,
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?
In the libgomp/libgomp.texi
+@node omp_get_uid_from_device
+@subsection @code{omp_get_uid_from_device} -- Obtain the unique id of a device
+@table @asis
+@item @emph{Description}:
+This function returns a pointer to _a_ string that represents a unique
identifier
^^^^^^^
+(UID) for the device specified by @var{device_num}. It returns a ...
<snipp>
@@ -6604,6 +6673,12 @@ The implementation remark:
@code{omp_thread_mem_alloc}, all use low-latency memory as first
preference, and fall back to main graphics memory when the low-latency
pool is exhausted.
+@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.)
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. So
you might want to make that implementation remark more clear
Sorry for the bickering. I just stumbled over that while waiting for a
regression test.
The remainder looks reasonable to me.
Regards,
Andre
On Thu, 19 Sep 2024 15:23:54 +0200
Tobias Burnus <[email protected]> wrote:
> Hi all,
>
> in order to know and potentially re-use a specific offload device
> (reproducibility, affinity wise close to a CPU (socket), …) a mapping between
> an (universal?) unique identifier and the OpenMP device number is useful.
> Thus, TR13 added support for it.
>
> This is a collateral patch caused by looking at the API routines for other
> reasons and looking at that part of the spec during the OpenMP F2F.
>
> Besides the added API routines, the UID will be used elsewhere:
> * In context selectors: 'target_device' supports 'uid(<string>)'.
> * In the OMP_AVAILABLE_DEVICES and OMP_DEFAULT_DEVICE env vars.
>
> @Sandra: Besides the usual .texi part, for the 'target_device' trait set:
> if you add a new GOMP routine for kind/arch/isa - can you also add an
> UID argument such that we don't have to update the API when needing in the
> not so far future.
>
> @Andrew + @Thomas: Any comment? Especially to the nvptx/gcn side (plugin +
> .texi)?
>
> @Jakub or anyone else — any comments, suggestions, remarks?
>
> [The patch was tested without GPUs, with one Nvidia GPU and one AMD GPU
> and seems to work fine.]
>
> Tobias
--
Andre Vehreschild * Email: vehre ad gmx dot de
