Comment by exDM69 | Hacker News Reader

Comment by exDM69 | Hacker News Reader

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:

    $ cl-cli --kernel=frobnicate.cl --input0=foos.bin --input1=bars.bin --output0=bazs.bin

Does such a tool exist already?

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.

We build something like this for image processing tasks: https://github.com/ufo-kit/ufo-core

There is also a CLI interface that allows in principle what you want to do, e.g.

     $ ufo-launch read path=foos.bin ! opencl filename=frobnicate.cl kernel=frobnicate ! fft ! blur ! write filename=bars.tif

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.

> The framework allows for partial data updates

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!

Sorry to keep plugging my stuff, but you might be interested in this ... https://github.com/Polytonic/Chlorine

No raw pointers, but you can use C arrays (was that what you meant by raw pointers?).

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.

Reply on news.ycombinator.com