Raw-mode buffers?

[markbravington]

Is there any prospect of allowing raw-mode buffers in future, as well as double/float/integer? I am working with large (GBytes) bit-packed datasets, stored as raws in R (length padded to a multiple of 4). To pass it to OpenCL as a clBuffer, currently I have to engage in some pretty hideous subte-R-fuge to first "typecast" it into an integer vector with the same bit pattern (NA_integer_ being a complication) --- essentially an elaborate, slow, and duplicative no-op.

The bits of code I looked at in ocl.c and clBuffer.c didn't immediately suggest impossibility to me (eg they already deal with several types) but are well beyond my C level.

This is really a feature request, not an "issue" per se, so I apologise if I've sent it to the wrong place--- not sure where else it should go. Many thanks for this super-useful package BTW--- I would probably never have gotten going with OpenCL without it.

[markbravington]

To follow up my own question/request: I've looked more at the C code in buffer.c , and I don't think the changes would be drastic--- just a few lines, actually (plus a small one at the top of ocl.h ). The R-side changes, presumably all in clBuffer.R, cannot be that major. If you are willing in principle to handle raws, but don't want to implement it yourselves (which I would certainly understand), would you consider a pull-request? The downside being that I don't know what I'm doing :) --- I think it would be my first formal pull-request, in fact---and might inadvertently cause more problems...
I also don't know if there would be any consequences outside those two C files and one R file. Anyway, the offer is there, so let me know what you think

[aaronpuchert]

You could certainly give it a try. Otherwise I can also have a look. It doesn't sound like it should take too much time. It should be a matter of adding a new case here and there. I haven't worked with raw vectors yet, but based on the documentation I agree it's a good fit for OpenCL (and this package).

[aaronpuchert]

Maybe you can try out #26. I think this is not terribly useful as output, because currently oclSimpleKernel wants to run the kernel for every output element, in this case every single byte. Maybe we need to provide a more flexible interface at some point. But for inputs it should be fine.

[markbravington]

Thanks! That seems to work so far, but I haven't yet tested with my full code (since that still has lots of bugs). I am a bit puzzled by your remark about oclSimpleKernel(), though? So far, I have been using it with a dummy 'size' argument, since I am not interested in the returned output vector per se; instead, I am using the kernel to update an existing buffer. Which... seems to do something, at least. Is that not an OK usage? Anyway, I too suspect that raw outputs will be generally less useful than raw inputs.

[aaronpuchert]

I am a bit puzzled by your remark about oclSimpleKernel(), though? So far, I have been using it with a dummy 'size' argument, since I am not interested in the returned output vector per se; instead, I am using the kernel to update an existing buffer. Which... seems to do something, at least. Is that not an OK usage?

Strictly speaking that's not using the API as intended, see ?oclRun:

The kernel is expected to have either ‘__global double *’ or ‘__global float *’ type (write-only) as the first argument which will be used for the result and ‘const unsigned int’ second argument denoting the result length. All other arguments are assumed to be read-only and will be filled according to the ‘...’ values.

The intention behind these functions was to offer a functional-style interface. However, this is probably too restrictive. I think we'll have to offer something more procedural, because functional programming requires allocating new buffers for results, which is not so good for performance. Performance of course being the main reason why one would use this package in the first place.

[markbravington]

Thanks. I can report that oclRun() is nevertheless working fine to update an existing buffer..! I use separate kernels to up/download that (and I will ask a separate question about that).

BTW the docu for ?oclRun does indeed say "global double or global float", but FYI it also works for "global int" too (my use case) and so it probably should; this might need a docu tweak?

[aaronpuchert]

BTW the docu for ?oclRun does indeed say "global double or global float", but FYI it also works for "global int" too (my use case) and so it probably should; this might need a docu tweak?

Yes, it should match the output.mode specified when building the kernel with oclSimpleKernel.

[aaronpuchert]

Thanks. I can report that oclRun() is nevertheless working fine to update an existing buffer..! I use separate kernels to up/download that (and I will ask a separate question about that).

You reminded me in #27 why this could actually be a problem, even though it doesn't seem so. We schedule kernels asynchronously and let them wait on their inputs, but we only attach the kernel event (indicating that the kernel finished) to the output. So you might get races if your GPU supports parallel execution of kernels.