[petsc-dev] Current status: GPUs for PETSc

Matthew Knepley knepley at gmail.com
Mon Nov 5 08:18:53 CST 2012


On Mon, Nov 5, 2012 at 9:17 AM, Lawrence Mitchell <
lawrence.mitchell at ed.ac.uk> wrote:

> On 05/11/2012 14:10, Matthew Knepley wrote:
> >
> >     Type safety is a bit nasty. CUDA allows to deal with plain 'void *',
> >     while OpenCL expects cl_mem. This suggests to use something like
> >       MatCreateSeqAIJWithCUDAArrays(__),
> >       MatCreateSeqAIJWithOpenCLArray__s(),
> >     but as I said above, I haven't come to a decision on that yet.
> >
> >
> > Let me be more specific. I would not support this. I think it is wrong.
> >
> > You should create the Mat in the normal way and then pull out the backend
> > storage. This way we have one simple interface for creation and
> preallocation,
> > and eventually we make a nicer FEM interface to cover up the device
> pointer
> > extraction.
>
> So something like:
>
> MatCreate(&m, ...);
> MatSetType(m, PETSC_GPU_TYPE);
> MatSetPreallocation(m, ...);
>
> // now the device data is allocated
>
> MatSetColumnIndices(m, ...);
>

This step is unnecessary.

   Matt


> // now the sparsity pattern is set up
>
> MatGetHandle(m, &handle);
>
> handle->device_data; // pointer we can pass to external assembly routine
>
> ?
>
> Cheers
>
> Lawrence
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121105/bb4cc914/attachment.html>


More information about the petsc-dev mailing list