On 10/17/2014 06:40 PM, Jed Brown wrote:
Karl Rupp <[email protected]> writes:
If this should be provided, then the right names were
VecCUDAGetArray()
VecOpenCLGetArray()
The former returns an object of type PetscScalar* and the latter an
object of type cl_mem. Because one is stuck with two incompatible
pointer types here, I'd suggest not to provide a single interface at the
expense of giving up type safety.
Agreed.
Does cl_mem have a "null"?
Yes, cl_mem is a typedef for an opaque pointer to a struct. If you pass
a cl_mem of 'NULL' to a kernel, the kernel is launched with a 'NULL'
pointer for the respective argument.
Also, even if one gives up type safety, one would immediately have to
switch-case into a backend-specific implementation again, so there's
little value in a common interface.
It's useful to have a non-error path for calling.
Can you sketch a use case for this?
Best regards,
Karli
