This package provides a binding for OpenCL based on the 1.0.48 revision.
This documentation does not describe meaning of API calls; it only describes their Scheme calling conventions. For details on API semantics, refer to the specification at the Khronos OpenCL API Registry.
If you run "tests/test.ss", it will print out a whole lot of stuff and run some code on all your OpenCL devices. This will show you that it is really doing something on your hardware.
Here’s what you can do to help:
Test on other platforms and hardware.
Write OpenCL programs and see what the API is missing. I suggest porting the programs from Apple’s examples.
Here are some implementation notes:
It is only tested on Mac OS X Snow Leopard with an Nvidia GeForce 9400M. The binding will fail to load on other systems. I need to find the path to the OpenCL binding on other systems and put it in the definition of opencl-path at the top of "ffi.ss". There are also a few C types that probably have sizes specific to version of OS X I’m using. Locating and dealing with these is essential.
The binding should wrap some objects in finalizers (using register-finalizer) that decrement their reference count.
The binding should wrap _cl_event objects in a struct with the prop:evt property to support synchronization in a Scheme style.
These functions should provide the properties in a Scheme style to look like fields or using the dictionary interface (by wrapping with prop:dict.)
clCreateContext’s properties arguments is hard to fathom. It is defaulted to NULL in the binding.
clCreateProgramWithBinary doesn’t automatically extract the status of each binary.
program-info doesn’t support the 'CL_PROGRAM_BINARIES option, because its calling convention doesn’t match my macro.
clSetKernelArg is specialized for each argument type (i.e., clSetKernelArg:_cl_mem), but I definitely haven’t created a binding for each available argument type.
clGetKernelWorkGroupInfo implements 'CL_KERNEL_COMPILE_WORK_GROUP_SIZE a bit wonky.
clEnqueueNativeKernel isn’t available.