On Sun, 2012-02-19 at 18:47 +0100, Tomasz Rybak wrote: > > This is not fault of AMD. The problem lies in the tests IMO. > In most of the tests from test_clmath.py you have: > a = cl_array.arange(queue, s, dtype=np.float32)/10 > which calls array.__div__, which calls _axbpz with argument > other = 1/10, which type is double. It means that generated > kernel axbpz has arguments of types float *, double, float *, float. > As Loveland does not support doubles, compilation of > this kernel fails in two places; once trying to enable > extension, and for the second time trying to parse header > with unknown type "double". > > The same problem is with OpenCL 1.1, and with OpenCL on NVIDIA > OpenCL. Unfortunately I do not have access to AMD hardware > which supports doubles, so I cannot test how it behaves > with OpenCL 1.2. > > The problem lies in the method array.__div__. > Type of result array is calculated using expression other, > while method array._axpbz gets expression 1/other, which > has different type (double in this case). I am not sure > however how to fix it - attached patch breaks operations > with complex numbers (e.g. test_mix_complex). >
Andreas - any comments? I have done some experiments and it looks like problem appears in 34d812dcc6762b8c34d644ab04ee62d0fa295102 caused by _get_common_dtype(self, other) I will try to work on it in the next few days. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
