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.
In fact, this binding doesn’t even document the Scheme calling conventions yet. This is a beta release to get some help.
To test it out quickly, run "tests/test.ss" and watch it print out a whole lot of stuff and run some code on all your OpenCL devices.
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.
Write documentation (probably modifying my macros to make documentation would be better.)
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 is a pure transliteration of the C API. I would like to give every function a ’Scheme’ style name. Suggestions welcome.
The binding automatically computes many arguments, like lengths of vectors and size of objects.
The binding automatically turns status and error code returns into exceptions with error messages based on the explanations in the FFI.
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.
The API has many functions, like clGetPlatformInfo, that extract various `properties’ of objects. The binding has a different version of each of these specialized for each possible property type, like clGetPlatformInfo:_char*, and a dispatching version that selects the appropriate one based on an internal table, like platform-info and a version that finds the size of the property’s value, i.e. platform-info-length.
These functions should provide the properties in a Scheme style to look like fields or using the dictionary interface (by wrapping with prop:dict.)
The API has many functions, like clGetDeviceIDs, that extract a list of values. The binding has the API straight as well as a version that only finds how many there are, i.e. platform-device-count, and one that extracts them all, i.e. platform-devices.
clCreateContext’s properties arguments is hard to fathom. It is defaulted to NULL in the binding.
No functions allow callbacks. (clCreateContext and clBuildProgram should.)
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.