[petsc-dev] Unification approach for OpenMP/Threads/OpenCL/CUDA: Part 1: Memory

[Jed Brown]

On Sat, Oct 6, 2012 at 8:31 AM, Karl Rupp <rupp at mcs.anl.gov> wrote:

> The important point here, however, is the independence from the
> implementation libraries, otherwise we would have to maintain a separate
> memory management implementation for each GPU library we possibly interface
> with.


Surely you'll have to implement it differently regardless. Is the issue
just that you want one publicly visible interface for syncing memory? Or
would you like a separate interface for synchronizing to different kinds of
accelerators, but for the logic behind that interface to be reused?

I don't know if anyone wants to simultaneously use different accelerators
(GPU and MIC?), but I could imagine a Vec type that supports memory
residing in more than two spaces, choosing to perform the operation
wherever the data is most current.


For code navigation, I don't if you looked at the "gtags" part of the
user's manual. If you use Emacs or Vim, it's an excellent way to tab
complete forward and reverse lookup. Note that PETSc's naming convention is
good for tab completion of implementations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121006/13ec85ec/attachment.html>