Deregistering a user-defined datatype. Register multiple dtypes to same ctype.

[eldos-dl]

The usecase is that different devices have different alignments for a particular c struct. This raises the need for different numpy datatypes to be registered as same ctype which requires a provision where different numpy datatypes to registered as a particular ctype depending on the device that we working with at that time.

For example, the following simple struct

typedef struct {
  int f1;
  long f2;
} temp;

results in these two different datatypes when matched on two different dtype({'names':['f1','f2'], 'formats':['<i4','<i8'], 'offsets':[0,8], 'itemsize':16}), dtype({'names':['f1','f2'], 'formats':['<i4','<i8'], 'offsets':[8,0], 'itemsize':16}). Now registering these two datatypes to the same ctype temp raises an error.

[inducer]

Interesting problem. If we built a mechanism for dealing with this right into PyOpenCL, how would you handle the case of being passed an array with a dtype that doesn't match the device that you're running on?

Also, what would your plan be for maintaining backward compatibility?

[eldos-dl]

It will be responsibility of user to pass an array with a datatype that matches the device.

[inducer]

Would that be detected (at call time)? At what cost?

How would type-dependent code generation be handled? Some caches may be keyed off of the type identifier and not the numpy dtype.

[eldos-dl]

I am not expecting it to be detected or handled. It would be nice if we can just register multiple datatypes (similar dtypes but with different offsets) to same ctype. The user will be getting a Segmentation Fault if passes an improper datatype cl.enqueue_copy

[inducer]

I'm honestly still not sure what the advantage of this scheme is over one where different types (on different devices) have different names--that seems reasonably manageable from an application perspective, and you could even spin your own abstraction on top of it. Could you explain?