[Haskell-cafe] ANN: OpenCL 1.0.1.3 package

[Luis Cabellos]

On Thu, Oct 13, 2011 at 9:13 PM, Martin Dybdal <dybber at dybber.dk> wrote:
> Hi everyone
>
> I just found this thread today, as I don't read Haskell-cafe that
> often (too bad, I know). I have been working on a set of OpenCL
> bindings for the last months myself, which I'm using to implement an
> OpenCL backend to the Data.Array.Accelerate library. The work is done
> at the HIPERFIT research center, Uni. Copenhagen.
>
> My bindings are even further from the naming conventions of the OpenCL
> library, but I really can't see the problem with that. People which
> are used to programming OpenCL from C/C++ might have to learn how the
> naming conventions of the Haskell library are, but they only need to
> do this once. When the mapping between the old and the new naming
> conventions are learned, they will benefit from having a more clean
> interface for all future times. (No Haskell hacker should have a
> problem with a steep learning curve.)
I'll just add, haddock + hoogle has done a lot remove the learn all
names necessity.

> It is somewhat troubling that we now have five different interfaces to
> OpenCL (that I know of), and I think we should join efforts and make
> one library that is as stable as possible. The five libraries are:
>
>  * OpenCL
>  * OpenCLRaw
>  * HsOpenCL
>  * hopencl
>  * The library presented by Benedict Gaster at AMD (yet to be released)
>   ( http://developer.amd.com/zones/OpenCLZone/publications/assets/MakingOpenCLSimplewithHaskell.pdf
> )
 * OpenCLRaw for me is a dead one. The main developer make no reply.
 * OpenCL, HsOpenCL and hopencl are the packages more suitable tu fuse.

I think that the best aproach is to use the OpenCL standard API as it
is, and let more libraries that use *opencl* packages decide what
high-level API offer. I like the Accelerate approach to show a better
API to users.

I currently working in the application that need the use of OpenCL.
The package that I develop offers all I need for now, so I not
upgrading it, only bugs or requested features for users. But in the
future I plan for two options: a) change to the *opencl* package that
gets mainstream, or b) continue with own OpenCL package because it
feels ok.

> My own library is available at https://github.com/HIPERFIT/hopencl and
> will be released on hackage very soon (next week probably). Please
> take a look at it. It is currently tested on x86_64 Linux with both
> the AMD x86/x86_64 bindings and NVIDIAs CUDA bindings. They will
> probably not work on Windows in their present state, and I don't have
> access to a Windows machine to test it on.

As Jason Dagit say, I put the stdcall call convention option in OpenCL
for windows:
https://github.com/zhensydow/opencl/blob/master/OpenCL.cabal

Other issues to solve,
How to compile in hackage server to generate documentation online?
opencl.h isn't in the server so I getting errors.


>
> --
> Martin Dybdal
>