This sounds great, let me know if can test anything. I also have a friendly user, ECP funded, that is interested to try out ECP solvers. This will be a good thing for us to deliver
On Wed, Nov 10, 2021 at 2:14 PM Junchao Zhang <[email protected]> wrote: > Justin, > We like to have a wrapper over CUDA/HIP since with that we only need to > maintain one code base. Scott (Cc'ed) may introduce his work/thoughts > along this line and coordinate with Jacob and your team. > > --Junchao Zhang > > > On Wed, Nov 10, 2021 at 12:50 PM Jacob Faibussowitsch <[email protected]> > wrote: > >> What’s the plan going forward with this unified cuda/hip branch? >> >> >> The end goal is to integrate PetscDevice and PetscDeviceContext — new >> objects which encapsulates physical devices and device-side sets of >> operations respectively — into PETSc. PetscDeviceContext provides a >> framework for enqueueing work on device streams, but is far more >> extensible. For example, I extend it to a very basic graph-based >> “PetscCallGraph" implementation in >> https://gitlab.com/petsc/petsc/-/merge_requests/4217. I believe Junchao >> is also currently working on integrating SYCL into the PetscDevice >> framework. >> >> Is this related to what some of us have been hearing about PETSc >> eventually going with a unified wrapper over both the CUDA and HIP API? >> >> >> The unified CUDA-HIP wrapper exists mainly because both APIs similar >> enough that it made sense to wrap them, and is the man in the middle >> between direct cuda/hip calls and higher-level >> PetscDevice/PetscDeviceContext API. >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> >> On Nov 10, 2021, at 12:28, Justin Chang <[email protected]> wrote: >> >> Jacob, >> >> What’s the plan going forward with this unified cuda/hip branch? Is this >> related to what some of us have been hearing about PETSc eventually going >> with a unified wrapper over both the CUDA and HIP API? >> >> We’re interested in making the HIP port more mature, including having >> support for the HIP part of HYPRE, but we’re unsure what direction you guys >> want to go with the GPU route. >> >> Thanks, >> Justin >> >> On Wed, Nov 10, 2021 at 12:19 PM Justin Chang <[email protected]> >> wrote: >> >>> Cc’ing Paul since I misspelled his email address initially >>> >>> On Wed, Nov 10, 2021 at 12:17 PM Jacob Faibussowitsch < >>> [email protected]> wrote: >>> >>>> I’m in the process of implementing asynchronous GPU support for petsc. >>>> A side effect of this is that I unify the cuda/hip interface such that >>>> anywhere we have cuda-like code we will automatically also get the hip >>>> variant. >>>> >>>> The scaffolding is in include/petsc/private/cupminterface.hpp, but for >>>> concrete examples see the jacobf/2021-10-21/veccupm-async branch for >>>> the WIP port of VecSeq in src/vec/vec/impls/seq/seqcupm/veccupm.hpp. >>>> >>>> Best regards, >>>> >>>> Jacob Faibussowitsch >>>> (Jacob Fai - booss - oh - vitch) >>>> >>>> On Nov 10, 2021, at 11:50, Justin Chang <[email protected]> wrote: >>>> >>>> Paul Bauman was also involved with the HIP port of HYPRE. Several of us >>>> at AMD are interested in getting HIP support for PETSc in general, and >>>> having HYPRE support would greatly help >>>> >>>> On Wed, Nov 10, 2021 at 11:47 AM Stefano Zampini < >>>> [email protected]> wrote: >>>> >>>>> I did the work last summer. It's already available in 3.16 >>>>> >>>>> Il Mer 10 Nov 2021, 20:44 Mark Adams <[email protected]> ha scritto: >>>>> >>>>>> Hypre has released HIP support and Ulrike says: >>>>>> >>>>>> I just want to let you know that hypre can now be used through PETSc >>>>>> with GPUs (both Nvidia and AMD). >>>>>> >>>>>> I am guessing we have some work to do to make this happen. >>>>>> >>>>>> What should I do? >>>>>> >>>>> >>>> >>
