[petsc-dev] Supporting OpenCL matrix assembly

[Jed Brown]

Karl Rupp <rupp at mcs.anl.gov> writes:

>> Okay, but why do they need to provide their own "Mat" data?
>
> If the context and queue are not attached to objects, then they would 
> essentially represent global state, which is something I want to avoid. 

I was thinking that the context returned would be specific to the Mat
and the device it was about to run on.

> What if a user for example wants to split the matrix accross multiple 
> OpenCL contexts (e.g. an AMD GPU and a Xeon Phi)?

Maybe the GetSource() should take an argument specifying which device it
was obtaining code for?  I'm not convinced that this sort of hybridism
is useful, however.

>> I envision the user doing all the job launching so they have control
>> over everything.  The Mat "implements" its MatSetValuesOpenCL (called on
>> the device) so it needs to provide the device handle.
>
> It needs to provide the command queue(s) (rather than the device(s)) and 
> access to its memory handles.

My "handle", I meant the pointer to be used on the device.

>> What am I missing?
>
> I think you were referring to the 'Mat' on the device, while I was 
> referring to the plain PETSc Mat. The difficulty for a 'Mat' on the 
> device is a limitation of OpenCL in defining opaque types: It is not 
> possible to have something like
>   typedef struct OpenCLMat {
>     __global int row_indices;
>     __global int col_indices;
>     __global float entries;
>   } PetscMat;
> and pass this as a single kernel argument.
> (cf. OpenCL standard or 
> http://stackoverflow.com/questions/17635898/passing-struct-with-pointer-members-to-opencl-kernel-using-pyopencl)

Umm, can't I copy the struct to the device and give the user a pointer
that they can shuttle into their kernels?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130924/3b637fc1/attachment.sig>