<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2019 at 9:49 AM Karl Rupp <<a href="mailto:rupp@iue.tuwien.ac.at">rupp@iue.tuwien.ac.at</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">Hi Mark,<br>
<br>
most of the CUDA-related fixes from your PR are now in master. Thank you!<br>
<br>
The pinning of GPU-matrices to CPUs is not in master because it had <br>
several issues:<br>
<br>
<a href="https://bitbucket.org/petsc/petsc/pull-requests/1954/cuda-fixes-to-pinning-onto-cpu/diff" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/petsc/pull-requests/1954/cuda-fixes-to-pinning-onto-cpu/diff</a><br>
<br></blockquote><div><br></div><div>These links are dead.</div><div><br></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">
The ViennaCL-related changes in mark/gamg-fix-viennacl-rebased can be <br>
safely discarded as the new GPU wrapper will come in place over the next <br>
days. ex56 has not been pulled over as it's not running properly on GPUs <br>
yet (the pinning in your branch effectively turned GPU matrices into <br>
normal PETSc matrices, effectively running (almost) everything on the <br>
CPU again)<br>
<br>
So at this point I recommend to start a new branch off master and <br>
manually transfer over any bits from the pinning that you want to keep.<br></blockquote><div><br></div><div>FYI, Satish worked on cleaning this branch up a week or two ago.</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">
<br>
Best regards,<br>
Karli<br>
<br>
<br>
On 8/3/19 8:47 PM, Mark Adams wrote:<br>
> Karl,<br>
> Did you want me to do anything at this point? (on vacation this week) I <br>
> will verify that master is all fixed if you get all my stuff integrated <br>
> when I get back to work in a week.<br>
> Thanks,<br>
> Mark<br>
> <br>
> On Sat, Aug 3, 2019 at 10:50 AM Karl Rupp <<a href="mailto:rupp@iue.tuwien.ac.at" target="_blank">rupp@iue.tuwien.ac.at</a> <br>
> <mailto:<a href="mailto:rupp@iue.tuwien.ac.at" target="_blank">rupp@iue.tuwien.ac.at</a>>> wrote:<br>
> <br>
> If you ignore the initial ViennaCL-related commits and check against<br>
> current master (that just received cherry-picked updates from your PR),<br>
> then there are really only a few commits left that are not yet<br>
> integrated.<br>
> <br>
> (I'll extract two more PRs on Monday, so master will soon have your<br>
> fixes in.)<br>
> <br>
> Best regards,<br>
> Karli<br>
> <br>
> <br>
> On 8/3/19 5:21 AM, Balay, Satish wrote:<br>
> > I've attempted to rebase this branch over latest master - and pushed<br>
> > my changes to branch mark/gamg-fix-viennacl-rebased-v2<br>
> ><br>
> > You might want to check each of your commits in this branch to see if<br>
> > they are ok. I had to add one extra commit - to make it match 'merge<br>
> > of mark/gamg-fix-viennacl-rebased and master'.<br>
> ><br>
> > This branch has 21 commits. I think its best if you can collapse them<br>
> > into reasonable chunks of changes. [presumably a single commit<br>
> for all<br>
> > the changes is not the correct thing here. But the current set of 21<br>
> > commits are all over the place]<br>
> ><br>
> > If you are able to migrate to this branch - its best to delete<br>
> the old<br>
> > one [i.e origin/mark/gamg-fix-viennacl-rebased]<br>
> ><br>
> > Satish<br>
> ><br>
> > On Fri, 2 Aug 2019, Mark Adams via petsc-dev wrote:<br>
> ><br>
> >> I have been cherry-picking, etc, branch<br>
> mark/gamg-fix-viennacl-rebased and<br>
> >> it is very messed up. Can someone please update this branch when<br>
> all the<br>
> >> fixes are settled down? eg, I am seeing dozens of modified files<br>
> that I<br>
> >> don't know anything about and I certainly don't want to put in a<br>
> PR for<br>
> >> them.<br>
> >><br>
> >> I also seem to lose my pinToCPU method for cuda matrices. I don't<br>
> >> understand how that conflicted with anyone else but it did.<br>
> >><br>
> >> Thanks,<br>
> >> Mark<br>
> >><br>
> ><br>
> <br>
</blockquote></div></div>