On 22.12.2014 05:32, Kyle Lutz wrote:
Well one concern with removing the word "enqueue" from the name is that the function actually *does* enqueue a command in the queue. For instance, if you queue up a couple kernel launches (which are asynchronous) followed by a synchronous read (with enqueue_read_buffer()), the asynchronous operations in the queue will still be executed before the read operation (i.e. the normal FIFO queue behavior).
Fair enough. For me this is implied since you're operating on a command_queue, not say command_graph.
That sounds very cool. I'd definitely be interested in exploring an API like that. I've also been keeping my eye on the papers from the C++ concurrency working group (for instance, N3857). It would be good to align work in this direction for Boost.Compute with the proposed standards (where feasible).
I agree w.r.t. standards. Not a lot like that in the Delphi world so I tend to explore on my own :)
Interesting, could you provide a test-case to reproduce this? In my testing (on Intel and others) I haven't found any problems with the code I supplied (though I've heard there may be issues with precision complex operations involving transcendental functions/sqrt()/etc. on some implementations).
I'll have to verify, but I'm pretty sure it was my simple Legendre polynomial evaluation test. It simply evaluates P_10(x) for several million points x \in [-1, 1]. So just multiplications and additions/subtractions. I'll rerun the tests to make sure I'm not just imagining things :) Cheers - Asbjørn