Keep in mind that Boost.Compute needs synchronization support to facilitate exception safety. I don't know if any type of futures can provide that, but its own futures don't. Ideally, you'd also want to express the data dependencies to the OpenCL C layer, to facilitate out-of-order kernel execution (whether using an out-of-order queue or multiple in-order queues). To that end... -----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser Sent: Saturday, January 03, 2015 8:16 To: boost@lists.boost.org Subject: Re: [boost] [compute] Some remarks
Thomas Heller
writes:
Another alternative is to hide futures in the containers/ranges/iterators and let the do the right thing implicitly. This is what NT2 [0] does afaik.
Joel adopted this in NT2 based on ideas from HPX [1], btw.
...this sounds like a good way to go, so long as the embedded events are accessible to the Boost.Compute core, from which it can construct wait_lists to pass into the OpenCL C interface. I believe Kyle is looking at doing something like this (maybe not the wait_lists, but at least making the device memory containers' destructors block on the corresponding events). Matt ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.