Chlorine: Dead Simple GPGPU(github.com) |
Chlorine: Dead Simple GPGPU(github.com) |
Holy crap. The "kernel" code is basically the same, but the native API setup code (which that tutorial even calls "boiler plate") is insane, starting with the fact that the source code for the CL on-device program has to be passed as a string. There is no API to pass a filename--only a string containing the entire program source!
Major problem with many of those libraries, including this one, is that, while they help you with hello world, they cripple the real-world functionality. All this low-level stuff that is there in the standard usually has its use. Of course it could and should be simpler, but most of those wrapper libraries guess too much and make many optimizations inaccessible or very hard to achieve.
The library that I wrote for Clojure (and Java), ClojureCL (http://clojurecl.uncomplicate.org) even supports OpenCL 2.0 (which is usually not supported in other libraries), while still allowing you all sorts of low-level performance optimizations accessible in the native C API, and is (in my opinion) rather simple to use compared to other libraries, and requires little boilerplate.
What features would you consider to be missing?
>Major problem with many of those libraries, including this one, is that, while they help you with hello world, they cripple the real-world functionality. All this low-level stuff that is there in the standard usually has its use. Of course it could and should be simpler, but most of those wrapper libraries guess too much and make many optimizations inaccessible or very hard to achieve.
Of course, though I wouldn't say cripple. With abstraction comes an associated performance cost. Chlorine is intended to reduce the barrier to entry. It's one of those "do things that don't scale" ideas. It hides some of the boilerplate from you, and is meant to help you quickly validate your ideas. If you need more fine-grained control over memory allocation, execution order, etc., you can always turn to the C/C++ API for performance, and it shouldn't be too difficult to port.
>The library that I wrote for Clojure (and Java), ClojureCL (http://clojurecl.uncomplicate.org) even supports OpenCL 2.0 (which is usually not supported in other libraries), while still allowing you all sorts of low-level performance optimizations accessible in the native C API, and is (in my opinion) rather simple to use compared to other libraries, and requires little boilerplate.
My goal is to make GPU programming more accessible, so it's always good to see competition! Anyway, Chlorine is OpenCL 1.1/1.2 only, mainly because OSX is not OpenCL 2.0 compatible (knowing Apple, it may never be).
Compare to the CUDA alternative where a lot of this is implemented as extensions to C++ in nVidia's nvcc http://www.computer-graphics.se/hello-world-for-cuda.html
>I'd love to use this, if there were more options available.
Did you have anything specific in mind? I'd be happy to add features.
Use:
convertToString(filename, sourceStr);
and pass sourceStr.
You are right about how much boilerplate there is - though you can hide it a bit with helper fns and a few macros.