A new addition is welcome as we still have not found the perfect API for accelerator programming. EasyOpenCL seems very simple and easy to use but I feel like it is very restricted.
For getting started with OpenCL development these days I would recommend PyOpenCL. Since everything is in Python, data can be generated easily, results can be plotted using well known Python tools which simplified debugging. Kernels developed in PyOpenCL can directly be copied to other APIs (raw OpenCL C API or some of the other C/C++ wrappers) and reused in production code.
I think the problem with (most of?) these libraries is that they don't solve the fundamental problem, which is: the OpenCL API is awful to work with. Various strategies have been attempted, mainly involving some form of "wrap the C API in less verbose C++!"
Why would you submit a PR - wouldn't you just create an issue (you don't want to select a license for their project)? In either case - my experiences with PRs have been really negative (and I'm not surprised).
Meh, they just need a push in the right direction. If they didn't care to post a license in the first place they might not care which one I pick for them. But you're right, in this case they took the PR as an opportunity to select a license but decided not to take the one I suggested.
This seems to be a library to make it really easy to invoke a single GPU kernel on some input buffers that are copied from CPU (an std::vector). Unfortunately, most practical GPGPU tasks aren't like that.
The latency of getting data from the CPU to the GPU and back is bad enough that for a small quantity of data (low megabytes), it's better just to compute it on the CPU. More practical tasks usually involve several kernel invocations, and keeping the data at the GPU is essential for any kind of decent performance.
But there are cases where executing a single kernel over some buffers would be useful (especially in early development or prototyping). In those cases, I'd like to write ZERO host-side code and use a CLI or GUI tool to run the code. So what I'd like to see is something like:
It would be even better if this would allow building proper pipelines of multi-kernel programs by defining the inputs and outputs to kernels using a directed acyclic graph.
I do not intend to dishearten you, OP, but think about this when you consider future direction to take with your project.
The framework allows for partial data updates - for instance for a 3D renderer it suffices the push the new position to the GPU whilst the vertex data remains in GPU memory. If you invoke the kernel function again it will not recompile the kernel nor reupload the vertex data.
The DAG idea sounds fun to build and very useful - I have some spare time anyway so I'll see what I can whip up. As for the command line interface - It too sounds pretty useful and it should only be a bit of parsing as all the OpenCL related code as been written already, but ufo-launch already performs pretty much the same function so it's not very high on my todo list.
Good! Additionally, it would be useful to memory map buffers and allow using raw pointers in addition to std::vectors. But more importantly, it would be necessary to use the output of one kernel as the input of another kernel invocation.
Anyway, build it to suit your use case primarily. Happy hacking!
Interesting idea. It should be only a few lines in PyOpenCL to build something like this.
But if you're already in PyOpenCL I guess would also prefer to generate the bin files there (maybe using numpy) ans evaluate the output (matplotlib possibly). For optimization you could run the kernel in a loop, time the runtime and vary the number or global and local work groups.
Seems nice! I would use this to avoid all the OpenCL bloat code. However, there's an inconvenient: why restrict the vector sizes to be all the same? I see that it is used to set the workgroup size. I think that giving the possibility to pass arrays of whatever size and allowing the client to set the workgroup size wouldn't add much complexity to the code nor to the API.
Apart from that, really nice work, the code is well written and commented, it's a joy reading things like that.
CUDA has a nice toolchain, but the point of this is to remove all of the low-level stuff. For performance (even on NVIDIA cards) it doesn't really matter whether you use CUDA or OpenCL [1] + OpenCL runs everywhere as a bonus.
Not a whole lot lower though, only in the 10-100x lower range from what I've experimented with (couple generations old card vs couple generations old i7 with a straight up "process some floats" test[0]). Certainly enough to test your kernels against.
Thrust: http://thrust.github.io/
VexCL: http://ddemidov.github.io/vexcl/
Boost.Compute: http://boostorg.github.io/compute/
The author of VexCL provided a comparison of them two years ago: http://stackoverflow.com/questions/20154179/differences-betw...