[petsc-dev] Supporting OpenCL matrix assembly

Karl Rupp rupp at mcs.anl.gov
Tue Sep 24 08:59:03 CDT 2013


Hi,

>>> Perhaps that *GetSource method should also return an opaque device "Mat"
>>> pointer that the user is responsible for shepherding into the kernel
>>>   From which they call the device MatSetValues?
>>
>> This is easy of the OpenCL management is within PETSc (i.e. context,
>> buffers and command queues managed by us). I expect that a bunch of
>> users wants to provide their own context and stuff, which would require
>> us to offer something like
>>     MatAttachOpenCLEnvironment(Mat,cl_context,cl_command_queue);
>> for all the matrix and vector objects involved. Note that this needs to
>> be attached before the matrix is created. I think this is doable.
>
> 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. 
What if a user for example wants to split the matrix accross multiple 
OpenCL contexts (e.g. an AMD GPU and a Xeon Phi)?


> 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.

> 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)


> If we only had to color the interfaces between thread blocks, we should
> have fewer colors.

If colors are assigned in a red-black fashion, then yes. :-)

Best regards,
Karli




More information about the petsc-dev mailing list