On Sun, Dec 21, 2014 at 3:01 PM, Sebastian Schaetz
Asbjørn
writes: In my "just for fun" Delphi.Compute library (written in Delphi, inspired by Boost.Compute) I made Copy() and Transform() return futures of the output buffers, as well as accept futures as parameters. Note, Delphi doesn't have iterators like C++ so my routines operate directly on buffers.
So when Transform() say got a Future<Buffer> instead of a Buffer for a parameter, it would add the future's associated event to the wait list passed to clEnqueueNDRangeKernel (technically the Buffer type has an implicit conversion operator to an "immediate" Future<Buffer>).
This made it pretty seamless to queue up everything and then just wait for the final read (the default "copy device buffer to host array and return it" call is blocking). The code looks sequential but would only block on that last read.
This idea is pretty nifty and I've been pondering this exact way of implementing asynchrony as well in my library.
Another method that I also like would be to just let the buffer store the futures. This is how Joel's/Numscale's NT2 works [0], he gave an awesome talk about it at this years Meeting C++ [1]. But this might just be a higher-level interface more applicable to expression trees as opposed to STL like functions.
A third way would be to return a future<void> from all meta-functions and allow meta-functions to take a future<void> - this would directly map to the stream/command_queue but the interface is maybe not that meaningful any more.
Yeah, these are all interesting ideas. While I'm a bit hesitant to
bake this behavior into the low-level command_queue interface, I'd be
more than happy to support this type of API at a higher level.
I've also been meaning to look at Aura again more closely. Last time
was many months ago and it looks like you've done quite a lot of work
since then.
And if your either of you are interested in trying to implement any of
these ideas in Boost.Compute I'd be very happy to work together. There
is already a "