OCL on Mac not working about nengo-ocl HOT 8 CLOSED

I sat down with @celiasmith and it seems like his laptop's OCL implementation requires that kernel functions have parameters, or else it doesn't recognize them as definitions (even if they are followed by curly braces). So the technique used for the "Marker" objects in plan.py is not working on his system. Easiest fix is simply to keep the empty function body, but add a parameter and allocate e.g. 1 byte of memory to pass as an argument.

from nengo-ocl.

That's a very strange error. Do you get anything else (line numbers, stack trace, etc.)?

Sorry, I just noticed you say this at the top of your post, or at least what the exception is. It's still strange.

from nengo-ocl.

sure, here's the whole thing:

RuntimeError Traceback (most recent call last)
in ()
14 # -- create an OpenCL-backed simulator using a
15 # particular device context:
---> 16 sim = m.simulator(sim_class=Simulator, context=ctx)
17
18 sim.run(1.0)

/Users/celiasmi/Documents/nengo/nengo/nengo/model.pyc in simulator(self,
dt, sim_class, seed, *_sim_args)
181 """
182 return sim_class(model=self, dt=dt, seed=seed, *_sim_args)
--> 183
184 ### Model manipulation
185

/Users/celiasmi/Documents/nengo/nengo_ocl/nengo_ocl/sim_ocl.py in
init(self, model, dt, seed, builder, context, n_prealloc_probes,
profiling, ocl_only)
54 # -- set up the DAG for executing OCL kernels
55 self._plandict = OrderedDict()
---> 56 self.step_marker = Marker(self.queue)
57 # -- marker is used to do the op_groups in order
58 deps = []

/Users/celiasmi/Documents/nengo/nengo_ocl/nengo_ocl/plan.py in
init(self, queue)
98 dummy = cl.Program(queue.context, """
99 kernel void dummy() {}
--> 100 """).build().dummy
101 Plan.__init(self, queue, dummy, (1,), None)
102

/Users/celiasmi/.virtualenvs/ip/lib/python2.7/site-packages/pyopencl/init.pyc
in build(self, options, devices, cache_dir)
164 self._context, self._source, options,
devices,
165 cache_dir=cache_dir),
--> 166 options=options, source=self._source)
167
168 del self._context

/Users/celiasmi/.virtualenvs/ip/lib/python2.7/site-packages/pyopencl/init.pyc
in _build_and_catch_errors(self, build_func, options, source)
204 # Python 3.2 outputs the whole list of currently active
exceptions
205 # This serves to remove one (redundant) level from that
nesting.
--> 206 raise err
207
208 # }}}

RuntimeError: clBuildProgram failed: build program failure -

Build on <pyopencl.Device 'Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz' on
'Apple' at 0xffffffff>:

No kernels or only kernel prototypes found when build executable.
(options: -I
/Users/celiasmi/.virtualenvs/ip/lib/python2.7/site-packages/pyopencl/cl)
(source saved as
/var/folders/91/dqhtq4ts7vd187fs23ctsg340000gn/T/tmpLJbQLJ.cl)

ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line string', (1, 8))

Eric Hunsberger wrote:

That's a very strange error. Do you get anything else (line numbers,
stack trace, etc.)?

—
Reply to this email directly or view it on GitHub
#51 (comment).

from nengo-ocl.

I also had issues running OCL on a Mac; in my case, not matter what I put for my kernel (I even did this independent of nengo_ocl, I was just using pyopencl in ipython), even an empty dummy function, it wouldn't compile. It worked fine on linux though. Perhaps this has something to do with Mac OS X keeping the OpenCL headers in a different place? If I recall, on macs, they're at OpenCL/*.h instead of CL/*.h.

from nengo-ocl.

I was thinking that maybe it is an issue with having a line break in the middle of a line of code?

from nengo-ocl.

@xchoo: not necessarily. I think the key line is "No kernels or only kernel prototypes found when build executable"

@celiasmith: try running the code below and see if it works. If not, then it's definitely something with your OpenCL install.

import numpy as np
import pyopencl as cl
ctx = cl.create_some_context()
queue = cl.CommandQueue(ctx)

M, N = 8, 8
A = np.random.normal(size=(M,N)).astype(np.float32)
X = np.random.normal(size=N).astype(np.float32)
Y = np.dot(A, X)

mf = cl.mem_flags
clA = cl.Buffer(ctx, mf.READ_ONLY | mf.COPY_HOST_PTR, hostbuf=A)
clX = cl.Buffer(ctx, mf.READ_ONLY | mf.COPY_HOST_PTR, hostbuf=X)
clY = cl.Buffer(ctx, mf.WRITE_ONLY, Y.nbytes)

source = """
__kernel void fn(
    __global const float *A,
    __global const float *X,
    __global float *Y
    )
{
    int m = get_global_id(0);

    float sum = 0;
    for(int n = 0; n < %(N)d; n++)
        sum += A[m * %(N)d + n] * X[n];

    Y[m] = sum;
}
""" % dict(M=M, N=N)

kernel = cl.Program(ctx, source).build().fn
kernel.set_args(clA, clX, clY)
gsize = (M,)
lsize = None

cl.enqueue_nd_range_kernel(queue, kernel, gsize, lsize)
queue.finish()

Yout = np.zeros_like(Y)
cl.enqueue_copy(queue, Yout, clY)

if np.allclose(Y, Yout):
    print "PASSED"
else:
    print "FAILED"

print Y
print Yout

from nengo-ocl.

To test @xchoo's theory, you could try the above code with the whole kernel on one line:

source = """__kernel void fn(__global const float *A, __global const float *X, __global float *Y){int m = get_global_id(0); float sum = 0; for(int n = 0; n < %(N)d; n++) sum += A[m * %(N)d + n] * X[n]; Y[m] = sum;}""" % dict(M=M, N=N)

Macs, Linux, and Windows do use different line break characters, so it's possible this is the problem.

from nengo-ocl.

Same problem ... @jaberg seems to be correct.

from nengo-ocl.