<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">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>