MacResearch

Hi Paul,

In looking at the error (I can't reproduce it on my system), the error code is: CL_INVALID_VALUE and for that function call it means that an incorrect or NULL value was passed to clCreateProgramWithSource.

Can you modify this line so it looks like this and see if it prints the program string:

char *program_source = load_program_source(filename);
printf("%s\n",program_source);

Thanks,

Dave

solved : must click on "Episode 3" under the "Executables" list item, then get info (or apple-I) then set the working directory to Project Directory (not build directory)

Thanks for the comments. I too had the same situation and Paul's fix works here.

I would like to know what kind of complexity can be put into the __kernel function. For example, I have tried with this:

answer[gid] = rand()%(b[gid]-a[gid]) + a[gid]

but it doesnot work. What is not correct?

More generally, is it possible to write answer[gid] = myfunction(gid) where my function would be in another file and would define a complex simulation dealing with agents (objects), and return for example the final number of agents?

To Guillaume Chapron:

Adding this after the call to clBuildProgram(), but before the assert gives some more info:
(fullstops because the indentation gets lost)


if (err != CL_SUCCESS) {
....char log[512];
....err = clGetProgramBuildInfo(program[0], device, CL_PROGRAM_BUILD_LOG, 512, log, NULL);
....printf("** %s\n", log);
}


In this case:

** :8:23:{8:16-8:22}{8:25-8:40}: error: invalid operands to binary expression ('float' and 'float')
.........answer[gid] = rand() % (b[gid]-a[gid]) + a[gid];
.......................~~~~~~ ^ ~~~~~~~~~~~~~~~


This is because (to quote the spec): "The remainder (%) operates on built- in integer scalar and integer vector data types only"

Replacing % with a + reveals the other problem:
** kernel referenced an external function rand, that could not be found.

There is no random function in the OpenCL kernel language.

The clFinishes are left overs from a version that had timing code. In order to time the phases accurately everything needs to be blocked on the CPU side correctly or the timings are meaningless.

However, regarding performance, there is being pedantic and then there is paranoid. The notion that forcing a clFinish on a copy operation to the GPU will kill performance is paranoid. If your code is bottlenecked on the write to the GPU anyway, then OpenCL on the GPU isn't for you. Synchronization between the CPU and GPU isn't a bad thing necessarily either. Remove the clFinishes and time the block. You'll almost certainly see for any non-trivial application (meaning one where real work is being done on your enqueued kernels) no difference. The bulk of the work should always be on arithmetic not any of the other setup or teardown.

Another consideration with why using clFinish on the command queue is important is there is no guarantee that you won't flood the command queue with too many operations. This is strictly implementation dependent. And in earlier revs of the OpenCL implementation on Snow Leopard it was necessary. Whether it is necessary now or not I haven't checked for problems where the command queue contains a large number of instructions. But again, issuing the clFinish periodically has in my extensive experience with OpenCL on SL not been a performance problem.

Dave

Of course, I agree that in the case of an app that could be doing something else blocking is silly. In many cases though I'd tend to think this kind of code will be running on a thread off the main application thread anyway. But your point is taken.

Dave

Another consideration with why using clFinish on the command queue is important is there is no guarantee that you won't flood the command queue with too many operations. This is strictly implementation dependent. And in earlier revs of the OpenCL implementation on Snow Leopard it was necessary. Whether it is necessary now or not I haven't checked for problems where the command queue contains a large number of instructions. But again, issuing the clFinish periodically has in my extensive experience with OpenCL on SL not been a performance problem.

Actually David, in normal operation, you should almost never have to use clFinish. The various blocking read/write/map enqueue calls always do an implicit flush, so the work will always get launched, and will force some synchronization between main thread and device. Cases where you might want a finish:

1) You are at risk of enqueuing 100's of thousands of operations causing a backlog causing free memory to become exhausted, and/or 3 days of work to be enqueued that you have no way to cancel. Periodic finishes would prevent too much work from backing up and keep your latencies relatively interactive.

2) You want to make sure OpenCL is done and has released various temporary resources before you start something else resource intensive.

3) You are looking for reference counting leaks and want to make sure OpenCL is done churning.

If you find that OpenCL starts failing due to queue overflow with a relatively small number of commands (<10,000?) please file a bug with Apple. That isn't supposed to happen.

Hi,

In episode 3 FFTs, BLAS/LAPACK, and Monte Carlo implementations on the GPU were discussed. I know apple has an OpenCL FFT implementation, but where can you find BLAS/LAPACK implementations? The ATI SDK for OpenCL includes some operations like matrix multiplication and eigenvalues but I need a more complete package especially one that has matrix inversion and singular value decomposition.

Thanks