Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package

On Thu, Oct 13, 2011 at 9:13 PM, Martin Dybdalwrote: > 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 >

On 17 October 2011 11:56, Luis Cabellos
On Thu, Oct 13, 2011 at 9:13 PM, Martin Dybdal
wrote: 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.
For now I have bundled the OpenCL header files with my package. That is not the right way either, as the header files can contain some platform specific information, for instance information about the calling conventions, which would be a way to handle the problem above (and the only way possible with c2hs, as far as I know). -- Martin Dybdal

On Mon, Oct 17, 2011 at 2:56 AM, Luis Cabellos
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.
In my experience, the nicest way to work around this problem is to just generate the documentation manually and host it somewhere off of Hackage. http://community.haskell.org/admin/ is a decent place to host something like this; you end up with a URL http://projects.haskell.org/yourproject which you can link to from the .cabal file description. Best, -Judah

On 17 October 2011 22:47, Judah Jacobson
On Mon, Oct 17, 2011 at 2:56 AM, Luis Cabellos
wrote: 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.
In my experience, the nicest way to work around this problem is to just generate the documentation manually and host it somewhere off of Hackage. http://community.haskell.org/admin/ is a decent place to host something like this; you end up with a URL http://projects.haskell.org/yourproject which you can link to from the .cabal file description.
That is an acceptable solution. The documentation of hopencl is now hosted at http://projects.haskell.org/hopencl/ Thanks for the pointer. -- Martin Dybdal

On 17 October 2011 11:56, Luis Cabellos
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
Thanks. I have implemented the same thing in my library now. I would be happy if someone could test that it compiles, and the unit tests runs on a Windows installation. -- Martin Dybdal
participants (3)
-
Judah Jacobson
-
Luis Cabellos
-
Martin Dybdal