Portability when the host and device have different endianness

[chatcannon]

I was looking in the PyOpenCL source to see if I could find some example code of how to handle this correctly. However, as far as I can tell PyOpenCL allows querying the device endianness with Device.endian_little but does not use this information anywhere else. Is this correct or have I missed something?

If I am right and PyOpenCL doesn't do anything about endianness differences, is this because:

• OpenCL says that handling endianness is the responsibility of the user, and PyOpenCL is deliberately keeping the same semantics?
• In practice, devices always have the same endianness as the host, so there is no need for endianness correction?
• Lack of time / interested people to implement this? (I could potentially contribute here)
• Some other reason?

NumPy seems to be pretty good at handling arrays with non-native endianness, so hopefully this should be less effort to implement for PyOpenCL then it would be at the C level.

[inducer]

Thanks for your report. You're right--PyOpenCL doesn't currently try to do anything about different endian-ness between host and device. I'm not sure I even understand all the concerns.

• Matching endianness of pyopencl.array.Array when converting to numpy seems like a correctness thing that would likely be pretty easy to accomplish.
• How is kernel parameter passing affected? If you pass a 32-bit integer, with which endianness is it supposed to go into clSetKernelArg?

In each case, I'd be happy to receive patch, though I'll admit I only have same-endian devices to test with.

[chatcannon]

I also noticed the possibility of setting __attribute__((endian(host))) in the kernel, so maybe this is less important than I thought. However, I also noticed that cltypes doesn't include types for the pyopencl cfloat_t so I will try adding that.