<div dir="ltr"><div dir="ltr">On Tue, Apr 6, 2021 at 2:08 PM Scott Kruger <<a href="mailto:kruger@txcorp.com">kruger@txcorp.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I wrote sent this yesterday but am having some strange mailing issues.<br>
<br>
On 2021-04-03 22:42, Barry Smith did write:<br>
> <br>
>   It would be very nice to NOT require PETSc users to provide this flag, how the heck will they know what it should be when we cannot automate it ourselves? <br>
> <br>
>   Any ideas of how this can be determined based on the current system? NVIDIA does not help since these "advertising" names don't seem to trivially map to information you can get from a particular GPU when you logged into it. For example nvidia-smi doesn't use these names directly. Is there some mapping from nvidia-smi  to these names we could use? If we are serious about having a non-trivial number of users utilizing GPUs, which we need to be for future, we cannot have this absurd demands in our installation process. <br>
<br>
The mapping of the Nvidia card to the gencodes and cuda arch is one of<br>
those annoyances that is so ridiculous it is hard to believe.<br>
The best reference I have found is this:<br>
<a href="https://arnon.dk/matching-sm-architectures-arch-and-gencode-for-various-nvidia-cards/" rel="noreferrer" target="_blank">https://arnon.dk/matching-sm-architectures-arch-and-gencode-for-various-nvidia-cards/</a><br>
<br>
To this end, the fact that Kokkos provides a mapping from colloquial<br>
card name to gencode/arch is a real benefit and useful.  The problem is<br>
that this mapping is buried in their build system and lacks<br>
introspection.<br>
<br>
> <br>
>   Barry<br>
> <br>
> Does spack have some magic for this we could use?<br>
> <br>
<br>
spack developed the archspec repo to abstract all of these issues:<br>
<a href="https://github.com/archspec/archspec" rel="noreferrer" target="_blank">https://github.com/archspec/archspec</a></blockquote><div><br></div><div>I do not love it. Besides the actual code (you can always complain about code),</div><div>they do not really do any tests. They go look in a few places that data should be.</div><div>We can do the same thing in probably 10x less code. It would be great to actually</div><div>test the hardware to verify.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is a *great* idea and eventually BuildSystem should incorporate it as<br>
the standard way of doing things; however, it is been focused mostly on<br>
the CPU issues, and is still under active development (my understanding<br>
is that the pulling it out of spack and getting those interop issues<br>
sorted out is tangled up in how spack handles dependencies and<br>
compilers).  It'd be nice if someone would go in and port the Kokkos gpu<br>
mappings to archspec as there is some great knowledge on these mapping<br>
buried in the Kokkos build system (not volunteering); i.e., translating<br>
that webpage to some real code (even if it is in make) is valuable.<br>
<br>
TL;DR:  It's a known problem with currently no good solution AFAIK.<br>
Waiting until archspec gets further along seems like the best solution.<br>
<br>
Scott<br>
<br>
P.S. ROCm has rocminfo which also doesn't solve the problem but is at<br>
least sane.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>