On Wed, 2012-01-25 at 08:55 -0500, Andreas Kloeckner wrote: > On Wed, 25 Jan 2012 14:25:38 +0100, Tomasz Rybak <[email protected]> wrote: > > Hello. > > Debian has two sets of OpenCL headers: > > 1.1 available in main branch > > 1.2 available in "experimental" > > Trying to build PyOpenCL with 1.2 headers and 11-12 AMD drivers > > fails. PyOpenCL expects to have 1.2 functions in libOpenCL.so > > (e.g. for splitting devices) and library does not provide > > those functions. > > > > I have downloaded AMD drivers 851.6 (or 8-93-10 as they are called > > on the web page > > http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx > > under the "OpenCL™ 1.2 and Static C++ kernel language preview" > > and was able to install them on my 64-bit Debian. > > clinfo (utility to list OpenCL devices) lists all my devices > > (CPU and GPU) as 1.1, but I was able to build PyOpenCL with > > 1.2 headers. I guess that this testing driver exports needed > > functions, even though devices do not support them yet. > > At the same time unit tests fail on this setup. > > test_wrapper works OK. > > test_array shows 5 failed tests > > test_clmath shows 13 failed tests > > (see attachments) > > I will try to see into those problems; I am not > > sure whether this is problem with PyOpenCL or my setup, > > because at the same time I have changed my drivers > > and built new PyOpenCL with complex SIMD and Fortran > > support (previously I had PyOpenCL 402cc8340e934574de > > from 2012-01-22). > > One part is easy: Their 1.2 compiler doesn't allow > > #pragma OPENCL EXTENSION cl_khr_fp64: enable > > Smart move on their part. When you get the choice of breaking nearly > every CL program under the sun or adding a simple backward compatibility > no-op to your compiler: which do you choose? :) >
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).
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
diff --git a/pyopencl/array.py b/pyopencl/array.py
index e608d19..7138e61 100644
--- a/pyopencl/array.py
+++ b/pyopencl/array.py
@@ -386,8 +386,8 @@ class Array(object):
@elwise_kernel_runner
def _axpbz(out, a, x, b, queue=None):
"""Compute ``z = a * x + b``, where `b` is a scalar."""
- a = np.array(a)
- b = np.array(b)
+ a = np.array(a, dtype=x.dtype)
+ b = np.array(b, dtype=x.dtype)
return elementwise.get_axpbz_kernel(out.context,
a.dtype, x.dtype, b.dtype, out.dtype)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
