Re: [boost] [compute] Some remarks

Subject: Re: [boost] [compute] Some remarks
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2015-01-03 17:58:03

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_at_[hidden]] On Behalf Of Hartmut Kaiser
Sent: Saturday, January 03, 2015 8:16
To: boost_at_[hidden]
Subject: Re: [boost] [compute] Some remarks

>> Thomas Heller <thom.heller <at> gmail.com> 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.