You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
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.
The text was updated successfully, but these errors were encountered: