<div dir="ltr">Thanks, <div>'-mat_type hypre' was failing for me. I could not find a test that used it and I was not sure it was considered functional.<div>I will look at it again and collect a bug report if needed.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 22, 2022 at 11:31 AM Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com">stefano.zampini@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Mark<div><br></div><div>the two options are only there to test the code in CI, and are not needed in general</div><div><br></div><div>   '--download-hypre-configure-arguments=--enable-unified-memory',<br>This is only here to test the unified memory code path</div><div><br></div><div>    '--with-hypre-gpuarch=gfx90a',<br></div><div>This is not needed if rocminfo is in PATH</div><div><br></div><div>Our interface code with HYPRE GPU works fine for HIP, it is tested in CI.</div><div>The -mat_type hypre assembling for ex19 does not work because ex19 uses FDColoring. Just assemble in mpiaij format (look at  runex19_hypre_hip in src/snes/tutorials/makefile); the interface code will copy the matrix to the GPU</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno ven 21 gen 2022 alle ore 19:24 Mark Adams <<a href="mailto:mfadams@lbl.gov" target="_blank">mfadams@lbl.gov</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 21, 2022 at 11:14 AM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"Paul T. Bauman" <<a href="mailto:ptbauman@gmail.com" target="_blank">ptbauman@gmail.com</a>> writes:<br>
<br>
> On Fri, Jan 21, 2022 at 8:52 AM Paul T. Bauman <<a href="mailto:ptbauman@gmail.com" target="_blank">ptbauman@gmail.com</a>> wrote:<br>
>> Yes. The way HYPRE's memory model is setup is that ALL GPU allocations are<br>
>> "native" (i.e. [cuda,hip]Malloc) or, if unified memory is enabled, then ALL<br>
>> GPU allocations are unified memory (i.e. [cuda,hip]MallocManaged).<br>
>> Regarding HIP, there is an HMM implementation of hipMallocManaged planned,<br>
>> but is it not yet delivered AFAIK (and it will *not* support gfx906, e.g.<br>
>> RVII, FYI), so, today, under the covers, hipMallocManaged is calling<br>
>> hipHostMalloc. So, today, all your unified memory allocations in HYPRE on<br>
>> HIP are doing CPU-pinned memory accesses. And performance is just truly<br>
>> terrible (as you might expect).<br>
<br>
Thanks for this important bit of information.<br>
<br>
And it sounds like when we add support to hand off Kokkos matrices and vectors (our current support for matrices on ROCm devices uses Kokkos) or add direct support for hipSparse, we'll avoid touching host memory in assembly-to-solve with hypre.<br></blockquote><div><br></div><div>It does not look like anyone has made Hypre work with HIP. Stafano added a runex19_hypre_hip target 4 months ago and hypre.py has some HIP things.</div><div><br></div><div>I have a user that would like to try this, no hurry but, can I get an idea of a plan for this?</div><div><br></div><div>Thanks,</div><div>Mark <br></div><div> </div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Stefano</div>
</blockquote></div>